As a product manager, I’m a true believer that you can solve any problem with the right product and process, even one as gnarly as the multiheaded hydra that is microservice overhead.
Working for Vertex Ventures US this summer was my chance to put this to the test. After interviewing 30+ industry experts from a diverse set of companies — Facebook, Fannie Mae, Confluent, Salesforce and more — and hosting a webinar with the co-founders of PagerDuty, LaunchDarkly and OpsLevel, we were able to answer three main questions:
- How do teams adopt microservices?
- What are the main challenges organizations face?
- Which strategies, processes and tools do companies use to overcome these challenges?
How do teams adopt microservices?
Out of dozens of companies we spoke with, only two had not yet started their journey to microservices, but both were actively considering it. Industry trends mirror this as well. In an O’Reilly survey of 1500+ respondents, more than 75% had started to adopt microservices.
It’s rare for companies to start building with microservices from the ground up. Of the companies we spoke with, only one had done so. Some startups, such as LaunchDarkly, plan to build their infrastructure using microservices, but turned to a monolith once they realized the high cost of overhead.
“We were spending more time effectively building and operating a system for distributed systems versus actually building our own services so we pulled back hard,” said John Kodumal, CTO and co-founder of LaunchDarkly.
“As an example, the things we were trying to do in mesosphere, they were impossible,” he said. “We couldn’t do any logging. Zero downtime deploys were impossible. There were so many bugs in the infrastructure and we were spending so much time debugging the basic things that we weren’t building our own service.”
As a result, it’s more common for companies to start with a monolith and move to microservices to scale their infrastructure with their organization. Once a company reaches ~30 developers, most begin decentralizing control by moving to a microservice architecture.
Teams may take different routes to arrive at a microservice architecture, but they tend to face a common set of challenges once they get there.
Large companies with established monoliths are keen to move to microservices, but costs are high and the transition can take years. Atlassian’s platform infrastructure is in microservices, but legacy monoliths in Jira and Confluence persist despite ongoing decomposition efforts. Large companies often get stuck in this transition. However, a combination of strong, top-down strategy combined with bottoms-up dev team support can help companies, such as Freddie Mac, make substantial progress.
Some startups, like Instacart, first shifted to a modular monolith that allows the code to reside in a single repository while beginning the process of distributing ownership of discrete code functions to relevant teams. This enables them to mitigate the overhead associated with a microservice architecture by balancing the visibility of having a centralized repository and release pipeline with the flexibility of discrete ownership over portions of the codebase.
What challenges do teams face?
Teams may take different routes to arrive at a microservice architecture, but they tend to face a common set of challenges once they get there. John Laban, CEO and co-founder of OpsLevel, which helps teams build and manage microservices told us that “with a distributed or microservices based architecture your teams benefit from being able to move independently from each other, but there are some gotchas to look out for.”
Indeed, the linked O’Reilly chart shows how the top 10 challenges organizations face when adopting microservices are shared by 25%+ of respondents. While we discussed some of the adoption blockers above, feedback from our interviews highlighted issues around managing complexity.
The lack of a coherent definition for a service can cause teams to generate unnecessary overhead by creating too many similar services or spreading related services across different groups. One company we spoke with went down the path of decomposing their monolith and took it too far. Their service definitions were too narrow, and by the time decomposition was complete, they were left with 4,000+ microservices to manage. They then had to backtrack and consolidate down to a more manageable number.
Defining too many services creates unnecessary organizational and technical silos while increasing complexity and overhead. Logging and monitoring must be present on each service, but with ownership spread across different teams, a lack of standardized tooling can create observability headaches. It’s challenging for teams to get a single-pane-of-glass view with too many different interacting systems and services that span the entire architecture.
For example, years ago, one company had 10 different monitoring systems, three different logging systems and additional third-party vendors throwing their own data into the mix. The sprawl of observability tooling creates issues that flow downstream, making critical operations like incident response far more difficult.
“It’s important to get the number of services right,” said Andrew Miklas, co-founder of PagerDuty. “There’s a basic sanity check for the number of services in your organization. If each dev supports three services, you’re probably creating too many. On the other hand, if a full team of 10 devs supports one service, it may be time to break it apart.”
Managing a microservice architecture also implies managing multiple codebases, each with its own set of dependencies. Each codebase also needs to be hooked up to its own release pipeline. As the practice of CI/CD matures and companies can deploy multiple times per day, if something breaks, it becomes increasingly difficult to determine which change from which codebase caused the issue.
Problems are plentiful, but our interviewees also found creative solutions to overcome challenges with microservices.
Which strategies and tools help companies overcome these challenges?
Speaking with developers and engineering managers helped us identify essential strategies and tools to help companies manage their microservice pain points:
1. Embracing the silos that form in your organization. The key is to make it easy for teams to break out of their silo when needed. Establishing best practices and standardized formats for cross-team contracts helps break down silos when teams need to work together. For example, Laban said he has “seen a lot of companies lay out high level guidelines and say ‘if you follow these best practices then you get a license to operate autonomously.’”
On the tooling side, Kodumal says using new technologies like feature flagging can help teams embrace siloed teams and services, “once you can decouple deploying a change from exposing it to end users you have a greater flexibility in how you roll things out.”
2. Balancing your team with generalists and specialists can also help overcome the organizational drawbacks of distributed architecture. Every team has specialists that know their codebase inside and out. But adding in generalists can help facilitate connections between teams for features that span multiple codebases, share best practices across the company and help educate the team on how all the codebases work together. Sourcing internal generalist candidates from platform teams and setting up rotational programs between groups can set up teams for long-term success.
3. Standardization helps simplify microservices. Independent service ownership gives teams the flexibility to choose the best technologies that fit their requirements, but too much autonomy breeds too much complexity.
Laban recommended that “you should only introduce new technologies if they have a large impact. Don’t look for a 10% improvement, look for a 2x improvement.” Before switching to microservices, specify a preferred set of technologies that engineering teams can standardize on.
“When making technical decisions, try to keep the needs of the broader company in mind and don’t just focus on what works best for the piece of software you’re writing today,” said Miklas. This makes it easier to hire devs, share knowledge and focus development on the most useful tech stacks.
4. The most exciting solution I’ve seen that helps increase visibility across the microservice architecture is the service catalog. The service catalog’s goal is to reduce the pain of managing the associated overhead of microservices by having one place for developers to get all the information they require about their infrastructure. From costing, to observability, to team ownership, a successful service catalog helps developers understand how infrastructure maps to their company’s organizational structure.
Companies like OpsLevel, Cortex and Effx help dev teams build better software by painting a picture of how their services fit together and how they map to their organizational structure. John Laban laid out his vision for how teams should manage their microservice architectures and the challenges that follow: “The ideal end state is where the development teams have full ownership of their software end to end both in design and operation. This works well with a distributed architecture where people get autonomy and independence and they can move a lot faster. But this independence comes with responsibility in reliability, security and compliance, which takes a lot of added effort.”
The best products do far more than just track service SLOs; they help teams collaborate to build better services. Products like OpsLevel help teams understand what language a given service is written in, who to contact, how to contact them if something goes wrong and what changes are coming down the pipeline.
These tools can also solve practical headaches such as finding and eliminating orphaned services, cataloging services for comprehensive legal and security audits, resolving incidents and driving standardization of technologies across infrastructure.
For example, let’s say your organization needs to adopt a new technology like Kubernetes or move to a newer version of a language like Java or Python. This process might sound simple when you’ve only got a few services to keep track of. But once your organization scales beyond ~30 services, it’s nearly impossible to ensure standardization across the entire stack.
With organizational silos keeping teams focused on only their specific slice of infrastructure, cross-team engineering efforts require a microservice catalog to ensure all teams are on the same page when it comes to understanding who has yet to adopt. Companies like OpsLevel keep an up-to-date list of all your services and their owners with metadata on languages and frameworks to help you reach 100% adoption.
Another instance where microservice catalogs are a must is in incident response. Our interviews highlighted the magnitude of pain teams face when trying to resolve incidents in a microservice architecture. With services spread across so many teams and monitoring data spread across so many siloed products, it’s difficult to get context on the timeline of events leading up to an incident.
Tools like Effx embrace the service catalog to aggregate data across services and data sources to give the complete picture of an incident. For example, let’s say I’m a developer on support rotation. I can use Effx to pull in monitoring data from tools like Datadog to scan my services and identify any incidents quickly. If one pops up, I can build a timeline of events using monitoring data, past deployments, active feature flags and provisioning changes to diagnose the problem.
Tying everything together
Microservices are now widely accepted as a way to help companies scale their infrastructure with their org structure.
Most teams start with a monolith to lower overhead. As the company scales to naturally develop distinct areas of focus and ownership, microservices help link the right services to the right teams.
Increasing complexity creates challenges in managing this infrastructure. Service sprawl, technical and organizational silos, and dependency management slow development and take the fun out of building software.
But development teams are problem solvers by nature, and they’ve devised strategies to overcome these issues. Standardized cross-team contracts, balancing dev teams, standardization of practices/tooling and service cataloging help teams manage the complexity.
These strategies have helped our interviewees scale their architectures to support some of today’s most popular products. We’re excited to see what new products startups come up with to help teams fully realize the power of microservices. If your company is looking for feedback on how to uplevel microservice infrastructure or if you’re working on a new product to tame microservices, leave a comment below or get in touch.
Vertex Ventures US has a financial interest in LaunchDarkly and OpsLevel.