Why Microservices Are Popular and How They Can Transform Your Development

As application development has become more complex, developers are turning to microservices in increasing numbers. Traditional approaches to development cannot accommodate changes produced by the growth of cloud and mobile technologies, which has led to the birth and popularity of microservices. They act as strategic tools that forward-thinking organizations are using to meet dynamic business needs by modifying, scaling and updating their apps continuously.

As IDC (News - Alert) 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.” So then, microservices aren’t a completely new concept, but rather a new incarnation of previous ones.

For some kinds of applications, it’s easier to build and maintain some kinds of applications by breaking them down into smaller pieces that work together. This is the idea behind microservices. 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.

Particularly with respect to large applications, this model makes the development process easier for myriad reasons:

Time is Money

Maintenance is easier and faster when using microservices architecture because it enables a faster workflow. This saves developers’ time, thereby increasing efficiency and ultimately saving organizations 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 Scales

The traditional development model required that the entire application be addressed as one large entity. 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.

Lightening the Burden

Monolithic applications require a significant test surface. One of the benefits of microservices is that testing is far easier for the simple reason that the test surface is smaller. Since each component of microservices 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 easier to monitor.

Microservices provide a way to simplify much of the work so that developers have fewer complex challenges to deal with each day, freeing up time to focus on more important matters.

Minimizing Disruption

By using microservices, developers can repair just the broken component of an application without having to repair the entire system as a whole. 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 useful real-world analogy: imagine that when a car’s tail light goes out, it means the entire car needs to be taken 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. This is how a microservices approach works in practice.

Containers: The Perfect Match

If you haven’t been living in a cave for several years without Wi-Fi access, you’ve probably noticed the rise of container technologies. This new way to package, distribute and run software 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.

Do What’s Best for Your Situation

As long as existing systems work within an acceptable range and provide the service you need, it often does not make sense to refactor them. Transforming existing legacy systems 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.

Most of the time, legacy systems won’t be completely replaced by microservices. There is no easy, paint-by-number approach to designing with microservices. Rather, as with any solution, a cost-benefit analysis is required. But that doesn’t suggest an all-or-nothing approach; legacy systems and microservices can exist in the same environment, relieving burden for developers and delivering application changes as needed quickly and efficiently.

About the author:

Miska Kaipiainen is the CEO and founder of Kontena, the creator of the Kontena open source, developer-friendly container platform that was recognized by Black Duck as one of the Top 10 Open Source (News - Alert) Rookies of the Year 2015. A serial entrepreneur and business developer, he has extensive experience in managing high-tech businesses in both the hardware and software sectors. Twitter (News - Alert): @miskakai