There are so many different tools and processes to think about when dealing with microservices. Organizations that operate microservices/service-oriented architecture face a variety of technical and people related problems. Over the past few years, companies have been migrating massive monolithic applications into smaller microservices (think services that do one thing, like archive a pdf) or even service oriented architectures (e.g. service-per-domain, payments, billing, auth).
There are undoubtedly many issues that come from monolithic architectures: easy to tightly couple domains and data, slower deployment process, and long test runs to name a few. Breaking the monolith can seem like a panacea for these issues. An SOA can provide team level ownership of domains and their systems, data is decoupled, and features/fixes can be deployed separately. Unfortunately, a SOA comes with its own set of issues.
Monoliths have been around for a while. There's a lot that's been written about "taming the monolith". As we get to work building Cortex, we've been talking to engineers about their experiences dealing with microservice architectures. Here's some things we've learned about taming your microservices.
A monolith, for all its warts, is simple to reason about. There are no network calls. There's no overhead to calling a function elsewhere in the codebase. If you're using a typed language, you can catch API changes at compile time. All the code is in one place – if you're so inclined, you can easily peek under the hood.
An SOA brings with it a suite of technical challenges, including operational complexity and performance hits. You now have to think about:
Yet, these technical challenges are the least of your worries.
While it may sound strange to think that cultural and people problems are a significant challenge stemming from architectural choices, keep in mind that most organizations move to an SOA to scale their team, not their software.
Distributing ownership of domains, data, and release cadence across services and teams can increase the velocity of your engineering org.
Unfortunately, distributing ownership does just that - teams start diverging in their operational procedures, documentation practices, and more. As an organization scales, this can wreak havoc on productivity, and ultimately bring your velocity back to square one.
People, process, and cultural issues around service oriented architectures have far reaching consequences:
Looking to scale your team? It's time to start thinking these challenges and how you can counter them.
There's no silver bullet to solve these problems. No combination of tools or processes can protect you. However, prevention really is better than the cure.
Think of it like a flu shot - you know its flu season, getting the flu sucks, and even though you may still get the flu, you'll never regret setting yourself up for success.
An excellent habit to promote is thinking about APIs and data models before jumping into the implementation.
It's important to ensure your SOA doesn't turn into a distributed monolith.
Signs of a distributed monolith:
One way to prevent this is following the Amazon model - APIs are the only way teams communicate. This means that a service owner should:
This workflow provides additional benefits when used in conjunction with tooling, such as OpenAPI or gRPC. If schemas and APIs are designed ahead of time, you can use:
Atlassian is an example of successfully using spec-first API design to improve their development lifecycle. I found https://www.atlassian.com/blog/technology/spec-first-api-development to be an excellent overview of using OpenAPI as the tooling to enable spec-first development.
The breaking point for a monolith is when multiple teams start depending on the same data models across domains. This slows down the development cadence across the org and the resulting spaghetti data models make it exponentially more difficult to reason about the code base.
It's easy to go down the same route in an SOA as well. There are some habits that help prevent this nightmare:
There's one obvious solution to "each team doing things their own way" - make it easy for teams to do things in a standardized way.
Atlassian, for example, has built out an internal PaaS that is essentially a thin wrapper around AWS. By doing so, developers are provisioned their desired resources but the platform automatically augments it with standard monitoring, logging, and more.
Well designed tooling that provides a standard way of doing things speeds up developer velocity and makes sure teams are working in consistent ways.
This even extends to documentation. Spotify and Atlassian have built internal tooling that standardizes information discovery around their microservices. System-Z at Spotify and Microscope at Atlassian provide a source of truth for details about each service, such as system ownership, links to documentation/runbooks, and recent deploys. What makes them even more powerful is that they are the entrypoint into further information about services – on-call rotations, links to monitoring dashboards, logging, etc.
This kind of standardization of information improves engineering ramp up time and operational efficiency - all services are operated in the same way and developers have a single source to look for critical information about their services.
Many organizations end up building an internal service registry for humans after the problem has gotten out of hand – too many services, growing teams and turnover, remote developers, etc.
Cortex provides a standard, opinionated way to organize information about all of your services and enables functionality such as:
Reach out to us to request a demo, we'd love to show you what we've built and help prevent some of the headaches that come with a service oriented architecture. Onboard to a modern microservice catalog today!