Subscribe to our 0800-DEVOPS Newsletter

Get in touch

Contact us for all inquiries regarding services and general information






Get in touch

Contact us for all inquiries regarding services and general information






Use the form below to apply for course





Get in touch

Contact us for all inquiries regarding services and general information






Blog

How big or small should a (micro)service be?

A question as controversial as to whether eggs are good for you. And just as we have seen tides turn when it comes to eggs, the same thing is happening these days with services.

People got bitten by tangled, tightly-coupled monoliths that caused slow releases of buggy software followed by long stabilization periods. This became unacceptable in a new customer-oriented, innovation-driven world. If tightly-coupled, monolithic architectures are bad then something opposite should be good. Thus, modular and loosely-coupled architectures came along. This kind of architecture made things better indeed – modularization made systems more maintainable and teams could prototype faster so the innovation cycle shortened.

Modularization made things better. And thinking in true Extreme Programming fashion(*) if moving from monolith to 5 services is good than moving from 5 services to 15 should be even better, right? Let’s try that!

Extreme Programming (XP) is a popular agile software development methodology that focuses on technical practices. Because some technical practices are considered “best practices” and “common sense”, it is clearly beneficial to use them. XP takes this argument to extremes: if using these practices is good, let’s use them all the time! For example, if code review is useful, let’s do it more (i.e. continuously)…and voila we just got Pair Programming – one of the XP technical practices. If writing tests is good, let’s do it more (i.e. continuously)…and there it is – Test-Driven Development as an XP practice.

So we as an industry have started competing in slicing our systems as thin as we can. Very soon organizations ended up with hundreds and thousands of services. This, in turn, generated a host of other problems associated with distributed systems like monitoring, logging, tracing, observability in general in a distributed environment, security, standardization, governance, etc.

It seems that too thin doesn’t work either.

Gergely Orosz from Uber commented recently that too thin services are overkill even for such a distributed organization. His team is now moving to something called “macroservices”.


The term itself is irrelevant here. What matters is that too thin is as bad as too monolithic. Gergely gave a more detailed explanation here.

After hitting both extremes (and better understanding their business and their systems along the way) organizations are now converging to optimal service sizes. What is happening now can be nicely described with a slightly modified Gartner’s Hype cycle diagram.

How big should your services be? Nobody can give you a better answer than yourself. But there are some guidelines:

  • Align your services with the business domain and not technical capabilities (use Domain-Driven Design and think in terms of Bounded Contexts)
  • Gain more insights into your business domain with techniques such as Event Storming
  • Make peace with the fact that you won’t get it right on the first try
  • Therefore, embrace Evolutionary Architecture principles to make your systems more flexible (keep your options open, use the Last Responsible Moment strategy)
  • And a practical advice borrowed from woodworking: when in doubt to slice or not, leave it in one piece. You will have a chance later to slice it if necessary

 

Ivan is Director of Engineering at CROZ, curator of 0800-DEVOPS newsletter and O'Reilly author contributing to "97 Things Every Cloud Engineer Should Know". His special areas of interest cover DevOps culture, sociotechnical nature of software delivery and cloud native architectures. Particularly interested in leadership and organizational change, he is helping organizations align business and tech, focus their efforts, and essentially work smarter, not harder. You can follow him on Twitter as @ikrnic.

0800DEVOPS
SUBSCRIBE TO 0800-DEVOPS NEWSLETTER

Interviews, articles, book recommendations and all things DevOps! Once a month, straight to your inbox!

CONTACT

Get in touch

Contact us