WeWork

As the WeWork footprint continued to expand, in mid-2018 the team began to explore the next generation of identity management to handle the global scale of the business.

The team decided to vet three languages for building microservices: Go, Kotlin, and Ruby. They compared the three by building a component of an identity system in each, and assessing the performance apples-to-apples.

After building out the systems and load testing each one, the team decided to implement the new system in Go for a few reasons. In addition to better performance under heavy loads, Go, according to the team, is a simpler language that will constrain developers to simpler code. Additionally, the development lifecycle is simpler with Go, since “there is little difference between running a service directly on a dev machine, to running it in a container, to running clustered instances of the service.”

In the implementation, they the Go grpc framework to handle various common infrastructure patterns, resulting in “in a clean common server pattern that we can reuse across our microservices.”

Following an EC2 outage in June of 2017, the WeWork team began exploring ways to scale their infrastructure while keeping things engineer-friendly.

The began dockerizing their services, using docker-compose to connect dependencies to the docker network and backend services. Jenkinsfile were added to each git repo, and Jenkins created docker [binary] images that were stored in JFrog Artifactory.

CloudFormation configuration files were created to deploy the docker images, with shell scripts handling basic tasks. In this configuration, it became possible to spin-up ECS services and tasks by definition.

The team created Environment Templates for ECS clusters, allowing services to live within environments (ECS Clusters) such as development, qa and production, and for docker images to be promoted between them.

By mid-2015, around the time of the Series E, the Digital department at WeWork had grown to more than 40 people to support the company’s growing product needs.

By then, they’d migrated the main website off of WordPress to Ruby on Rails, and a combination React, Angular, and jQuery, though there were efforts to move entirely to React for the front-end.

The backend was structured around a microservices architecture built partially in Node.js, along with a combination of Ruby, Python, Bash, and Go. Swift/Objective-C and Java powered the mobile apps.

These technologies power the listings on the website, as well as various internal tools, like community manager dashboards as well as RFID hardware for access management.

Late in 2014, around the time of the Series D, the WeWork engineering team had grown to 14, and while the backend was modernized with Rails and Active Admin CMS, the main website was lacking. The new headcount provided enough capacity to address the aging WordPress website.

As the team experimented with front-end technologies, they implemented a new signup flow with Angular, and other flows, including the Market Page, in React and Redux. The team says of that time: “If you’re following closely, yes, this means that in one rails app we had pages that included one or many of the following: jQuery, Angular, and React.”

For many years, the marketing website was a customized WordPress instance, leaving the three-person engineering team—WeWork didn’t make its first full-time engineering hires until after its series A—to focus on building internal tooling. WordPress powered the main site until late 2014.