On January 9, 2018
Hi there, I’m Yves. I left Google recently after almost 10 years there as a site reliability engineer. This is part of a series of articles about base services and how they can speed up the development of software.
I wrote recently about how the monolith slows down teams with more than 20 or so developers and why many companies are stuck with the monolith. We often talk about microservices but we should be talking more about base services.
Base services are components of a fast-changing network that are used as a base for other services and should be highly dependable for both development and production stages. The emphasis is on their reliability and not on their micro-ness.
Your company might, for example, have a microservice for storing and querying customer metadata. Such a service is highly connected to your business, but it sits at a lower level in the stack. That changes its reliability requirements: it should also be dependable during development stages, otherwise, services built on top of it will have very flaky development environment themselves.
What are good base services?
Base services have a few requirements:
- Clear ownership, support channels, and maturity status.
- They must be stable, not just in production but also in shared development environments. They may provide test fakes to make tests reliable.
- They should publish transparent reliability metrics. Clients need to know what they are getting into.
In a healthy modern services architecture, teams and companies collaborate through services APIs to quickly build and iterate products. APIs are great, but using other people’s services can be a nightmare.
If you are using another service, whether it is internal or external, you should be asking these questions:
- Is the service even supposed to be highly-available?
- How can I use this service during development without wasting time?
- How do I deal with the flakiness of other people’s development or staging instances?
- During testing, is it OK to use an external service and issue requests to the public Internet?
- How do I tell when my service is down or the other service is at fault?
- Who owns the service?
- Which support channels are available in case of problems?
- Am I building a critical service on top of a service that has been abandoned?
- Can I complain if the service goes down every day?
If you can’t answer these questions, how do you know if what you are building is going to work tomorrow? How do you know if a broken development instance in the service you use might prevent you from using your test application for a whole day? It also works the other way: are the services you provide good base services?
Microservices are overrated
In microservices, the emphasis is on small release units. Small release units make it easy for the service to be changed. But that is a very narrow aspect. The more general problem is: are we building a service that other teams (or companies) can rely upon for their fast-paced development processes?
Individual pieces are important, but what truly matters is the strength of the network of services.
We need to use and provide well-supported, dependable base services. That allows fast development without sacrificing reliability.
Building base services
Expect more posts about this topic. In the following days, I will expand the arguments above about why base services matter. But I want to take action and not just talk about it: can we build an open-source infrastructure that aims to improve reliability and productivity for everyone? I think we can.
If this interests you, subscribe below to get notified of new posts.