Subscribe to our 0800-DEVOPS Newsletter

    Get in touch

    Not sure where to start? Let our experts guide you. Send us your query through this contact form.

      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


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

          clock4 minute read


          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, 🎙0800-DEVOPS podcast host 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.


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


          Get in touch

          Contact us