Microservices: How and why now?

In a recent analysis, Gartner Inc. noted that microservices empower development teams to become delivery teams, deliver cloud-ready applications and support incremental adoption and evolution. No wonder an increasing number of developers are jumping on the microservices bandwagon. Traditional development methods are no longer practical in light of the growth of cloud and mobile technologies.

That’s where microservices provide the strategic tool needed to harness these new and evolving technologies. Today’s truly innovative companies are harnessing microservices to succeed, to modify, scale and update their apps continuously in order to meet changing business needs.

The idea behind microservices isn’t new; instead, it represents a coalescing of several earlier ideas. As IDC analyst Al Hilwa has explained, “microservices is an architectural approach that draws on the long, evolving experience in software engineering and system design, including the SOA (Services-oriented Architecture) efforts of the last two decades.” The premise is that it’s easier to build and maintain some kinds of applications by breaking them down into smaller pieces that work together.

In this way, each component is developed separately – the application is the sum of its parts. You have independent processes communicating with each other using language-agnostic protocols. This is a sharp contrast to the more traditional approach of building one, huge system all in one piece. Especially for large applications, there are several reasons why the microservices model makes the process easier.

Cost Efficiency

A faster workflow is possible with a microservices architecture; Maintenance is easier and faster. This saves developers’ time, thereby increasing efficiency and ultimately saving organisations money. What’s not to like about that? What’s more, microservices allow for faster evolution and upgrades – no need for massive codebase refactoring when adding new features.

Changing the Scale

The application had to be treated as one large entity with the traditional approach. If demand increased, the whole application would need to be multiplied to handle the load. That would mean multiplying the servers or virtual server instances that the application ran on. In microservices architecture, you only need to scale the app components impacted.


Because the test surface is smaller, testing with microservices is far easier than with monolithic applications. Since each component of microservice architecture is more or less autonomous, developers can easily test those small components locally – no need to deploy them to a complex test environment. The smaller size also makes applications easier to deploy and to monitor. In short, microservices provide a way to simplify much of the work, leaving you more time to focus on more important matters.

Small-scale Repair

Since microservices break applications into components, developers can fix just the broken component without having to repair the entire system. Instead, you can just replace the faulty component, without any interruption to the end user. Of course, that may not always fix the root cause, but the priority should be placed on designing a system so that an end user doesn’t even notice the problem.

Here is a good analogy for how a microservices approach works in practice. Think about when a tail light on a car burns out. Imagine if that also meant the entire car would need to be hauled in for repair. Not only would this be inconvenient, but it would also be time consuming and costly. Fortunately, cars essentially use a microservices type of approach. You can keep driving even with the broken taillight, and it’s simple to replace the non-working part. More importantly though, the core service was not interrupted and there was likely little friction for the driver.

A Marriage Made in Technology

Container technology is a new way to package, distribute and run software that greatly compliments microservices. With the right tools, you can now create systems using microservices architecture, while keeping the operations and maintenance burden of your infrastructure minimal. Microservices and containers may not be synonymous, but they are a perfect match.

However, not everything needs to be transformed. Often, it is not necessary to refactor existing systems as long as they work at an acceptable level and provide the service you need reliably and with “good enough” performance. Transforming existing legacy system to microservices architecture might become a huge project. If you want to follow that road, it’s often smart to do it in parts; start by chopping off some functionality from your monolith and make them work as microservices serving your monolith.

Similar to the concept of bimodal IT, microservices aren’t intended to entirely replace legacy systems but to offer help where necessary. So then, the microservices model is an individualised approach to development.

Any model has its pros and cons, which is why using microservices and legacy systems in the same environment can create a “best of both worlds” scenario.

Miska Kaipiainen, CEO and cofounder, Kontena

Image source: Shutterstock/Kalakruthi