By Catharina Nordlien Johnsen
In January 2014, Uber opened its first remote engineering office in Aarhus, Denmark. Located in the Clemensbourg district of the city, Uber Aarhus Engineering has grown from 5 to 50 engineers, all focused on scaling our core infrastructure for 24/7/365 availability worldwide.
The office serves two major areas core to Uber’s tech stack—storage and compute:
- The Storage Platform Team: Ensuring that petabytes of data are available and elastically scalable is the main challenge tackled by the Storage Platform Team. Our Aarhus office is responsible for building and running Schemaless, Uber’s homegrown, horizontally scalable NoSQL storage engine, maintaining our company-wide storage management platform, and supporting our infrastructure more broadly.
- The Compute Team: Uber’s microservice architecture runs on uDeploy, a massively scalable virtualized platform with automated tooling for lifecycle management. The Compute Team develops and drives the infrastructure needed for deploying, managing, and running thousands of microservices across multiple geographical locations.
Below, several members of the Aarhus engineering team discuss their experiences building Uber’s infrastructure and what it is like to work in Uber’s first European engineering office.
Steffen Grarup, Director of Engineering, Core Infrastructure
You worked at several other companies before coming to Uber. How does your Uber experience compare?
I think Uber is by far the fastest moving company I’ve ever been at, and it’s also the most fun. I like that I get to focus on scaling and deploying high quality code quickly. I also really enjoy that my team gets to both own their own services and witness the impact of these services on a global scale. So, in a nutshell, the entire focus of our work is on getting software to execute seamlessly, worldwide.
What is the primary objective of your site’s engineering work?
Uber Engineering Aarhus’ main focus is making Uber’s core infrastructure scalable and highly available. Just keeping our platform scaling—doubling every 5-6 months—is a big challenge. We have to be resilient to any form of hardware, network, or data center failover, and in many cases, resilient to humans as well! In terms of executing high quality services, it boils down to writing software that is easy-to-diagnose, easy-to-upgrade, easy-to-expand iteratively, and easy-to-onboard for new engineers.
What have you learned the most from your experience at Uber so far?
I think the biggest learning experience has been realizing just how big of a productivity gain you can have by owning your service. From conceptualization to operation, engineering teams at Uber own their service’s entire workflow. Uber Engineering has SRE and Observability teams, but at the end of the day, you are responsible for your work.
How would you describe engineering opportunities at Uber to job candidates?
You get to collaborate with very smart, motivated people, both locally and globally. As of May 2017, we have engineering offices in 11 cities spanning five countries. Operating in well over 70 countries now, Uber is truly an international company. From San Francisco to Sofia and Bangalore to Boston, Uber gives its employees the opportunity to work with people in offices around the globe. When I started my career, information was much more local. These young software engineers don’t realize how lucky they are!
Mary Fesenko, Software Engineer, Compute Platform
What’s your role at Uber?
I am software engineering on the Compute Platform Team. I work on our deployment system, uDeploy.
Why did you decide to join Uber Engineering?
I have been using Uber for years as a rider, but never thought about applying for a job here—I didn’t even know that Uber had offices in Europe. A year ago, I received an email from a recruiter with information about open positions in the Aarhus office and decided to give it a try.
You moved from Ukraine to join our team. What convinced you to make the move to Aarhus?
At that time I was actually looking for job opportunities abroad because I wanted to try living and working in another country. I mostly focused on opportunities in Europe and already applied for different engineering roles in Germany and Holland. I didn’t know much about Denmark and job opportunities there, so I hadn’t really considered working there.
After full day of on-site interviews, I realized that the opportunity was the perfect fit for me. The Uber interview process was quite different from those I’d had in my home country—I didn’t know that someone could feel so excited and full of energy after a whole day of talking.
Moving to Aarhus and working at Uber were the two best decisions of my life (thus far). We have an amazing team here, people are always ready to help, and I learn a lot from them. On top of that, I’ve made a lot of great connections with fellow expats at Uber who have taught me the ins and outs of living in my new city.
How would you describe the engineering opportunities at Uber?
At Uber, I get to collaborate with intelligent and experienced engineers across the company to solve challenging problems, and you get to meet interesting people from different countries on a near-daily basis.
I’ve been here for eight months, and I still learn something new every day. Before Uber, I worked at companies that outsource their software, and I think it’s a nice change to have full ownership over your product. Additionally, I really like that you’re not tied to one technology or language here. You’re not just a Java engineer or Python engineer, you’re a software engineer, and no matter your preferences or background, you need to use the appropriate tool set for the task at hand.
Jeppe Bronsted, Software Engineer, Schemaless
What’s your role at Uber?
I’m a back-end infrastructure engineer. I help build out the basic infrastructure for the Uber platform.
How did you get into software engineering?
When I was younger I wanted to be a musician; I played the trumpet. When I was 22, I started studying computer science, and eventually pursued a Ph.D. I conducted research on how you can use sensor data from multiple cars to increase safety, for example, to detect potholes on the road before vehicles reach them. In many ways, software engineering combines the creativity of music with the precision and problem solving of science. As an engineer, I find it much easier to figure out what I need to do to improve, and that’s very rewarding.
What made you go into industry versus continuing on in academia?
What I really like about being in industry is that the time period from when you develop ideas to when they affect real people is so much shorter in comparison to research. Research can take years to actually make a positive impact.
Before I worked at Uber, I was at a healthcare company where I built infrastructure. In that environment, the timeline of writing a line of code to seeing it in production was a year-long process. At Uber, I deploy new software three to four times per day; that’s really a huge benefit of our model. Another thing that’s unique about Uber is the sheer scale of the company. We facilitate more than 10 million rides daily, so every day my piece of code gets used by at least a million people. And every time I think about it, it motivates me to continue executing at the highest level.
Lasse Damgaard, Software Engineer, Service Infrastructure
How did you get into engineering?
I took an alternative career path compared to a lot of engineers. I don’t have a formal computer science background, but during my studies I worked on various projects related to human-computer interaction.
What’s your role at Uber?
I design the UI for uDeploy, our code deployment solution, but I also do some back-end work on the platform. By building a UI that is effective and easy-to-use, my team ensures that uDeploy can ship new code quickly and seamlessly across our services without engineers having to think about it.
How would you define Uber Engineering’s culture?
Our culture boils down to the fact that we move quickly and at scale. There is a certain mentality that comes from knowing that things move as efficiently as they do—you have to have a strong design, but you can’t lock yourself in a box for two months to develop a prototype. We need to release software into production and then iterate.
What else should Infrastructure candidates know about what it’s like to work in our office?
We’re always moving forward, and that’s also the fun part. We strike a balance between having an environment where we can grow the infrastructure at the rate we need to; we can’t have barriers or rigid processes. Just like our networks, our attitude towards development has to be agile and malleable.
Anders Madsen, Software Engineer, Compute Platform
What’s your role at Uber?
I am a senior software engineer on the Compute Platform team. Like other engineers in my office, I primarily work on uDeploy and many of its supporting services. Over the years, I have been involved in growing the uDeploy system, onboarding services to this platform, building and distributing services, and most recently, scaling the system to accommodate even higher rates of user demand.
You’ve been at Uber Engineering Aarhus since its inception. How has the role of the office changed over time?
I was one of the office’s first five engineers. In the beginning, we conducted a lot of infrastructure improvement tasks and bug fixes while building uDeploy. Our goal was to create a system which would allow engineers to deploy with confidence at Uber’s ever-expanding scale.
My first year at Uber was all about keeping up with the growth of the company by onboarding services to our uDeploy and creating useful new features. At that point in time, we never planned more than a month in advance because we were iterating so rapidly.
Over the years, however, we have matured the system and expanded the portfolio of applications we maintain to keep the uDeploy system operational. Development has shifted from quick solutions and firefighting to carefully planned features which are delivered without risking the stability of the system. While engineers out of Aarhus built uDeploy, we are now part of a larger group running the compute platform with team members in San Francisco and Palo Alto.
What other engineering challenges are you working on?
While it might look like uDeploy is done being built, there is much more to do. Generally when you design a component of a larger distributed system, you only imagine it scaling to a certain load or size. But when you are approaching these parameters, you must stretch or redesign that component. Consequently, we are constantly working on improving uDeploy to deliver a better experience for our customers: the rest of Uber Engineering.
What makes being a software engineer at Uber different from working at other companies?
A couple of things come to my mind, one of which is being an owner. At other companies, I built software products which we sold to customers. The normal cycle from inception to production was two months of planning, six months of development, and six months of testing before a new product was shipped. I was only really involved in the six months of development and after that moved on to building a new product. At the end of the day, there is only really one version of each service: the version running in production.
Another differentiator is the scale and scope of the engineering problems we tackle. Many companies use the same open source software as we do, but the amount of traffic we have surfaces unforeseen limitations that companies operating at a smaller scale never reach. This demand forces us to think creatively about how we tackle these types of challenges.
Catharina Nordlien Johnsen is the site program manager for Uber Engineering Aarhus office.