Amazon, Netflix, eBay, and many of the world’s most innovative corporations all have one thing in common: they have gone in big on microservice architectures.
In fact, it’s not just these internet leviathans who have embraced microservices: a survey by NGINX found that 63% of enterprises where using or adopting microservice architectures by the end of 2020, and the proportion of apps being built with microservices in 2020 has increased by 20% compared to 2019.
Perhaps the biggest driver for this growth, and the thing that is enhancing the value of microservice architectures, is the move towards cloud computing: private clouds, public clouds, and edge network clouds. This makes it practical to build and frequently update complex yet robust apps made up of multiple microservices running in containers.
What is a Microservice?
In general, a microservice is a self-contained application which is tightly scoped as part of a business process. A microservice could perform something like payment processing, for example, and the idea is that every microservice does one thing very well.
One of the key attributes of a microservice is that it is loosely coupled with other microservices, communicating using a language-neutral API, to reproduce the functionality of what may previously have been provided by a small part of a “traditional” monolithic application. Being loosely coupled means that each microservice has no dependencies with any other microservices; any one of them can be updated or redesigned without having a knock-on impact on any of the other microservices.
The other key attribute of a microservice is that it is self-contained and self-sustaining. In practice this generally means that it runs in a container with its own database or other components that it may require.
Benefits of a Microservice Architecture
A microservice architecture based on containers offers some powerful benefits. Here’s one example: scalability. A microservice running in a container can easily be scaled up without having to scale up the entire application.
Here’s another: thanks to containerization a microservice architecture can also bring a high degree of resilience. That’s because there is inherent fault isolation in a microservice architecture — that loosely coupled thing again. If a microservice does fail then a new instance in a new container can be launched automatically, meaning application downtime may be too small to be noticeable.
Of course, the capability to scale and automatically launch containers requires a high level of automated orchestration. The good news here is that this is becoming increasingly practical, thanks to advances in orchestration software such as Docker’s Swarm, Apache Mesos, the open source Kubernetes, as well as the many orchestration products built around the core Kubernetes code.
Microservices and Software Development
There are plenty of other reasons why enterprises may find microservices valuable. For example, it enables the acceleration of software development. In part that’s because a particular microservice’s development team only needs to understand the microservice it is working on — not the entire application logic. This has the side effect of making developers more productive, allowing them to work on the task at hand without having to worry about the rest of the application.
Microservices also allow development teams to be more efficient by having them spend less time in meetings and coordinating actions. A rule of thumb is that microservices development teams should be what Amazon termed “two pizza” teams, meaning that they should be small enough to be able to share two pies.
Software development can also be carried out more efficiently using a microservice architecture, in theory at least. That’s because each microservice can be developed in whatever language and software environment is most appropriate. That means that .Net and Java, for example, can easily coexist if that is what will produce the optimum results.
And because microservices do just one thing, they tend to be small. That means that there is a relatively small amount of code to test. And, because they are loosely coupled, new versions of microservices, once they are tested, can be dropped into a production environment without worrying about breaking the whole application, making developers’ lives a whole lot easier.
The result is that enterprises experience an average 75% drop in lead times when introducing new features after adopting a microservice architecture, according to Matt Miller, a partner at Sequoia Capital. This allows them to increase the frequency of software releases thirteen-fold. An oft-quoted statistic is that Amazon releases new code on average once every 11.7 seconds thanks to microservices.
Finding the Right Fit
It’s important to remember that a microservice architecture isn’t the answer to everything, and, more to the point, a microservice architecture isn’t without potential drawbacks of its own. In particular, there’s the potential to introduce network congestion or latency if too many microservices are communicating too much of the time, even if they interact using an inter-process communication protocol such as HTTP, AMQP, or a binary protocol like TCP.
It’s also possible to introduce too much complexity with the need to maintain multiple languages and frameworks for a single application, as well as the complexity of managing an application made up of hundreds or potentially thousands of services. This complexity means more resources may be used — think multiple databases — and more logs are generated.
Nonetheless, in a world where more and more companies are moving to cloud or edge computing environments, a microservice architecture built using containers and automated orchestration will look increasingly valuable to enterprises of almost all sizes.