• Team
  • Team

When should you create new microservices?

To move fast, software development teams should use small independently-released microservices. But how small should they be?
By Yves Junqueira

January 12, 2018

To move fast, software development teams should use small independently-released microservices. But how small should they be?

Microservices are somewhat like camping: the first time you do it, there is a lot of uncertainty and stress. What should you bring in your backpack? You end up overthinking it and bringing many things you don’t need.

With microservices, we need to choose the right service boundaries: what goes into which service. Sometimes we create too many services that become a maintenance nightmare. And it is tough to course-correct and rearrange the architecture once services are in production. Recently someone asked:

"hi. i have a microservice that handles users(entities). should i set up a custom microservice for authentication or should i just stick the logic into this user service instead and keep it simple?"

So when should we create a new microservice? There are many articles from reputable sources talking about this:

Back to ivanjaros’ question about whether he should split the users and authentication handlers into two services or not, the short answer is: if you have a concrete product roadmap showing that the authentication code will have a lot more logic within, say, six months, then splitting it now can be OK. Otherwise, it’s best to leave both in the same service – but making sure they are still kept modular and decoupled.

The reason for keeping them in the same service by default is that more likely than not, your infrastructure is not 100% automated. Unless you have 100% of your platform automated and spinning up, and maintaining a new service doesn’t increase ops work, new microservices come with a cost. So you should not do it prematurely.

Creating new microservices is similar to adding an abstraction in the code: consider what are your real use cases and break down your domains of concern accordingly. Don’t overdo it. Don’t build overly complex interfaces because of hypothetical use cases such as “let me add a database middleware here just in case we move from Oracle to MySQL 10 years from now”.

Similarly, if you use, say, Amazon S3 to store data files, you probably shouldn’t create a CloudStorage microservice to sit in the middle between your other services and S3, unless you have a clear plan for moving soon to a different cloud. Otherwise, if you create new microservices to support imaginary future requirements, you end up with a large chunk of wasted code that requires some non-zero maintenance time.

Deciding When to Create a New Service: Factors to Consider

How Many People Are Working on This Code Base, Now or Soon?

The more people working on the same code base, the more likely it is for an engineer to waste time because somebody else “broke the build”, crashed the development environment, caused a flaky test, or introduced a bug that will delay the production rollout. If problems like this are routine, it is time to split the services (and probably fix your tools).

Are There People Working in the Same Service from Distant Time Zones?

It is much easier to tap your colleague on the next desk to help debug the broken build than to wait for someone in Europe to wake up and figure out what’s going on.

Distributed teams should ideally work on distinct microservices.

How Painful Is It to Release These Services?

We all know what services are more likely to cause headaches during production rollouts. You probably want to avoid adding a new functionality to problematic services. New features usually need fast follow-up iterations, but that will not happen if you co-host with your headache-inducing service.

How Much Maintenance Overhead Results from Creating New Services?

Despite years of improvement, as of September 2017 when I left, even our SRE team at Google had not yet managed to fully automate the setup and maintenance of new services. There is always some extra ops overhead for new services, and often a lot more than we assume at first.

As you may have read before, I am working on an upcoming open-source project to help with challenges in this space. If any of this resonates with you, let’s connect and chat!

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