Nowadays it’s not so rare when marketing representation obscures and blurs the original term (idea, technology) it is built around. Such blurring of outlines creates a specific situation: eventually the term becomes so hyped in the media space, that people stop perceiving the concept behind the term critically. They get used to it, assuming that the modern software product should be created with this technology, which automatically guarantees it will be “done right”. But these conclusions for the most part are based on the popular opinion rather than on results of personal experience and analysis of pros/cons for the concrete case. 

Most often description of the Microservices architecture is based  on its comparison with a so called Monolithic style. Such comparison, of course, has the right to exist, but it’s at least not interesting – it’s clear who is a “bad guy” in this movie from the very beginning. It would be much more valuable and representative to compare it with SOA (Service Oriented Architecture) or EDA (Events Driven Architecture). If this happens, then it is stated, for example, that SOA is a too general term. Hmm.. wait a moment.. But whether there exists a common method of measuring how “micro” should the service be? Why not “medium” or at least “mini”? And principles of splitting the functionality into services – are they common for a software product of any scale, purpose and complexity? And the main question: whether using of the Microservices architecture guarantees having an efficient, flexible, easily scalable, reliable software product?

Doug Mcllroy used to say: 

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

It’s a classic Unix philosophy. Now let’s refresh our knowledge of the SOA principles: SOA. It turns out that there is nothing new in the Microservices concept. In fact, Microservices architecture is an Enterprise design pattern, once again formulating the principles from the previous experience and making some explicit clarifications. Here I would highlight 3 of them:

  • Services are smart, protocols are simple

  • Decentralised data storage

  • Services should be tiny pieces of logic.

I would absolutely vote for the 1st one, agree with the 2nd with reservations and join the demonstration against the 3rd as it is really debatable. In my opinion denomination “Microservices” is itself misleading. Consequence is that degenerate architectures are created, where application is split into enormous number of really MICRO services. Not so long ago I was at the lecture of the stickler for this approach. That guy has implemented logic related to each domain entity in a separate micro-micro service in production software and was really proud of this. Imagine you need to get a list of Classes, Teachers, Students – you’ll make 3 HTTP REST API calls.

It is written enough about the advantages of Microservices, so I will not repeat this here. If still interesting, you can read: Martin Fowler. Instead let me comment on the most promoted ones.

  • Services used as components give you the loose coupling of parts of your application together with strictly defined interfaces. Yes and no actually. This depends on how you design your micro services. It is possible to have a Microservices architecture in place, but still have tightly coupled components with messy interfaces.

  • With micro services your application becomes easily scalable. This also depends on the way you’re designing your services – in case they’re stateful with poorly designed intercommunications, you’ll get your headache.

  • Your system becomes naturally distributed. Yeeeah, but this also leads to a fact that with Microservices you dive into the world of distributed systems, taking all risks and development overheads, which is maybe totally not needed for your case. Don’t forget that you’ll also need to consider service failures and design/implement correspondingly.

  • Microservices allow you to perform independent deployment of services, leading to an easier upgrade path. Yes, but this also leads to a much more complicated environment and procedures for monitoring your system.

  • Services are totally independent, so they can be implemented with different program languages and toolsets. Yes, but don’t get addicted to this: tracing a failure across the set of distributed services written in different languages is a hell.

  • You don’t need a large database, apply decentralised approach to data storage. You can, if needed, but if you’re going to have a fault tolerant system, you’ll be applying replication and automatic failover mechanisms to all of your databases thus complicating your infrastructure.

The resume of this post is that hype around Microservices is compromising the original idea. Meanwhile separating your system into a set of loosely coupled services is really a good approach for building enterprise applications, when used with caution and understanding of consequences. Microservices is just one of the tools, which does not guarantee you by default the desired result – everything will depend (as usual) on concrete implementation, on concrete decisions and concrete persons. It’s like building a house – you can give perfect instruments to your men, but if they’re not proficient you’ll never get Palazzo Ducale di Mantova at the end. Architecture should be pragmatic: apply technique only if you really need it and to the extent that allows you on one side to benefit from it’s use and on another side to avoid negative effects which are always present. So, when taking or approving an architectural decision turn a deaf ear to phrases like “paradigm shift”, “culture change”, “technology of the future”, instead make sure that responsible people really understand why it is needed in your concrete case.