Searching for flights is a famously hard problem in computer science, and it is only getting harder. Five years ago, there were about 5 billion possible combinations for a flight from New York to London. That has grown more than 10 times to 63 billion today, and the trend shows no sign of slowing down.
Sabre’s systems power flight search for mobile apps, third-party travel websites, airline websites, and even brick and mortar travel agencies. We generate almost a million itineraries per second at peak, each one of them using large amounts of compute and requiring multiple large, in-memory datasets for selection, seat availability, ticket pricing, and validation.
To make flight searches possible and cost-effective at that scale, while still allowing rapid development and experimentation, we’ve been using a microservice-based architecture for more than 10 years. (In fact, that’s longer than the term “microservice” has been around!) And now we’re extending that use in Sabre Labs to include new capabilities like calendar shopping, personalization, and merchandising. Let’s take a look at three important lessons we’ve learned along the way.
The first one is that simplicity wins. The idea is to simplify by doing things like standardizing the ways services communicate and are controlled and monitored, or even limiting the variations in the technology stacks used. Because while each choice may be optimal locally, as a whole, complexity makes it harder to scale, debug, and understand the system. It also hurts the ability to rapidly innovate, since it’s difficult to reorganize services and it’s challenging for developers to move from one component to another.
The second lesson is to focus on the “service,” not just the “micro.” Each one of Sabre’s shopping and retailing microservices has a clear reason for its existence. Some of these services are compute intensive and stateless, some of them need fast access to large amounts of RAM, and a few read from databases. Because they have different runtime profiles or use different sets of resources, they exist as different services.
Lastly, get comfortable with in-between states. This means supporting frequent, rolling upgrades to individual services by making them backward and forward compatible in their communication and data updates. Most importantly, it means automatically testing those combinations in a CI/CD pipeline. We’ve been piloting the SRE style of DevOps pioneered at Google to manage our shopping and retailing services. These engineers write code not only to monitor and deploy our services, but also to make them more resilient and easier to manage over time.
Now let’s explore two bets Sabre Labs is making for the future of microservices.
First, shared services will be used to enable innovation. As a company with development teams working on hundreds of products for airlines, travel agencies, and hotels, we’re scaling our ability to innovate by investing in shared services that can be used throughout the company. These shared services will support rapid prototyping, hackathons, 20% projects, and even accelerating feature development work by allowing a developer to mix and match reusable services with a small amount of new orchestration code.
Second, we can allow developers to spend more time creating value by standardizing on batteries-included frameworks like gRPC and a service mesh like Istio. Across the tech industry, companies like Airbnb, Google, Lyft and Netflix are using these tools to rapidly increase their adoption of microservices and while expanding the scale at which they’re able to manage them.
Stay tuned for more about our use of microservices at scale, including how we deploy them in our cloud environments. If you have a passion for large-scale engineering projects like this, we’re hiring!