• Team
  • Team

We need base services and not just microservices

Are the services you provide good base services?
By Yves Junqueira

January 02, 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.

By Yves Junqueira
Yves worked for a decade as a Site Reliability Engineer at Google, where he created software development tools and infrastructure. He left Google in 2017 to found YourBase, where he is using his passion and experience to help development teams move faster. Follow @cetico on Twitter.

Recent Posts

YourBase Early Access - software development without distraction

October 30, 2019

Four years ago, my family and I moved from Zurich to Seattle. I grew up in Brazil and had the…

Benefits and downsides of microservices

March 15, 2019

The main benefit of microservices is to allow a large team of engineers to development software more…

YourBase - let’s fundamentally simplify how we deploy software

January 23, 2019

YourBase is a community of SREs and developers from different companies that are starting a new…

GitHub & the memcached DDoS amplification attack of 1.35 Tb/s

March 23, 2018

If you leave your memcached servers listening on UDP and open to the Internet, they will certainly…

When should you create new microservices?

January 12, 2018

Microservices are somewhat like camping: the first time you do it, there is a lot of uncertainty and…

We need base services and not just microservices

January 02, 2018

I wrote recently about how the monolith slows down teams with more than 20 or so developers and why…

LoginDocumentationHow It Works