Microservices: Yet Another Hype?

By Thomas Lee, CEO, Throput. This is a re-posting of a Throput blog article.

Many experienced application architects understand no one architecture pattern suits all application scenarios. Every architecture pattern has its purposes and costs. Under the bandwagon effect, many people tend to overrate the power of a new technology and downplay its costs, giving an impression that this shiny thing would be like a silver bullet to all existing pain points. Do you remember how many people had told you that the Service-Oriented-Architecture (SOA) would be the future (like this)? You might have spent a good sum of money on training and middleware for SOA. Today, I bet most of your applications could still be monolithic, client-server, or n-tier. Is microservices just another hype? (The diagram below shows the evolution of popular application architectures.)

Advantages of microservices architecture

The advantages of the microservices architecture are primarily two-fold. In the development time, different microservices can be built with any technologies (e.g., Node.js, Python Flask, Go Gorilla, Java Spring Boot) most suitable for the their cases, with regard to productivity, robustness, compatibility, and maintainability. Since a large application is broken down into very small components, their development and testing can be more extensively paralleled by multiple teams. If the service components are designed to be also reusable, further productivity can be gained.

In the runtime, microservices can independently scale in and out on-the-fly based on the actual resource utilisation and service level targets. Since each microservice may spawn multiple instances across different server nodes, the fault tolerance can also be improved. The feasibility of packing microservice instances more densely in server nodes can achieve a higher efficiency of compute resource consumption. This can be translated into a substantial cost reduction, for instance, when it’s large-scale cloud deployment.

Everything sounds too fabulous, doesn’t it? What’s the catch? The complexity potentially adds costs and risks that you may not expect.

Complexity of microservices architecture

The microservices architecture could be much more complex than you might expected. Imagine your application comprises ten microservices. (In reality, it isn’t uncommon to use tens of microservices to compose a large application.) You might get a sense that it could be a challenge to keep these tens of microservice instances cooperate to correctly deliver the intended functions. The following lists some of the areas where the complexity comes from.

• Interoperability. Unlike making static library calls in an application, where the compiler guarantees the syntactic compatibility between the caller and the callee, we need to make sure all microservices’ tens of the RESTful APIs are perfectly compatible. This might not be a big problem in the beginning when the application is first released and each microservice is only used by a single application. However, when many microservices (perhaps being reused by multiple applications) are separately maintained for on-going releases, keeping track of multiple versions of all microservices and ensuring their compatibility could easily become the classical N×N spaghetti nightmare. (Interoperability is a hard problem. I studied the interoperability of web services in my PhD research and proposed a formal model to verify data interoperability. If you’re interested, you may read my academic paper here.)
• Transaction management. It would be very hard to maintain the ACID of an transaction executed across distributed microservices. Often we either relax the transaction requirement from ACID to BASE or enlarge the bounded context of a microservice to let the transaction take place solely within it. It isn’t easy to make these architecture decisions especially when microservices are reused across applications.
• Access control. You should expect additional efforts and risks to implement secure authentication and authorisation (A&A) among tens of microservice instances distributed in different places. Although some standards and patterns (e.g., JWT) emerge to enable more systematic access control of microservices, there isn’t yet a mature total solution that can save you from coding the A&A logic by yourself.
• Troubleshooting. When each microservice might have multiple instances, there could be tens of microservice instances running across multiple server nodes. Troubleshooting any behavioural or performance issuse in so many instances could be a challenging. Profiling the microservices and monitoring their instances would require considerable extra efforts too.
• Infrastructure. Despite not an absolute requirement, microservices are commonly implemented using the container technologies. The container technologies are still under rapid development and yet to be standardised. There are many war zones in the container market landscape. Competitions and marriages among technologies are going on at all layers. For example, there are more container engines than you might have heard of: Docker/Moby vs LXD vs rkt vs Cloud Foundry Garden. At the orchestration level, there are Kubernetes, Docker Swarm, Amazon ECS, Cloud Foundry Diego, Mesos+Marathon, and more. Everyday, many of these technologies are very actively evolving and some new ones are coming out. Selecting a suitable container stack could require hands-on trials. In addition, you might set up many other API infrastructures (e.g., gateway, security, logging, monitoring). Unless you have a sizable and competent IT team, these infrastructure hassles could distract you from focusing on coding the application logic that actually delivers the intended business values. Having said that, many cloud platforms have packaged popular container and API technologies as PaaS, which has made development, deployment, and operation a lot easier.
• DevOps. I see continuous testing and integration is a prerequisite in the microservices development. Otherwise, it would be different to prevent an application from being broken by daily changes to the microservices or the infrastructure. You should be prepared to incorporate DevOps into the software process when developing microservices.

Should I use microservices?

Should I use microservices? I would answer this question from the following three perspectives.

• Do you need microservices? As mentioned above, the main purpose of the microservices architecture is for developing web-scale and cloud-native applications, that require high availability and robustness. Are you developing such an application, as mobile app or IoT app with thousands of conconcurrent accesses?
• Are you ready to use microservices? You should expect there would be non-trivial investments in skills and infrastructures. Instilling new practices and culture (e.g., DevOps, Twelve-Factor-App) are necessary too. You should be prepared for extra resources and unexpected chaos, especially in the beginning of adopting the microservices paradigm.
• Is microservices just a hype or actually useful in the real world? In my opinion, microservices isn’t just a hype. There are many real-world success cases of microservices adoption. Especially tech giants have been popularly using this architecture pattern to develop large-scale cloud, mobile, and IoT systems because they have the real business needs. Although the term microservices might become out-of-fashion in a few years (just like SOA), some key architectural concepts behind, such as the Share-Nothing Architecture, will continue to influence application development.

Personally, I think microservices is gaining the traction to reach mainstream in a couple of years. It will become much more mature, in terms of standards, product support, and skills. However, you should expect some breaking changes of the existing technologies from time to time before they are standardised in the industry. After the most important elements of microservices are the software engineering and architectural concepts not the technologies (or products). The technologies will evolve but the concepts will remain applicable for solving the right problems. The decision for you to make is: when is a good timing for your organisation to adopt those concepts and technologies to materialise some real business benefits.