Digital transformation expert Dion Hinchcliffe places microservices architectures in the strategic and incremental quadrant of emerging technologies. This means that microservices will drive significant improvement in existing infrastructure and processes – which is why an increasing number of developers are adopting the technology to build their applications. They are taking advantage of the opportunity to move away from traditional monolithic approaches to development with this newapproach.
It’s not that microservices have sprung fully formed from the forehead of Zeus. Rather than being an entirely new idea, they are a new incarnation of previous concepts. 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 Lincoln Logs of childhood provide an apt metaphor for the idea behind microservices, which 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, the Lincoln Log approach makes the process easier for several reasons.
A faster workflow is possible with microservices architecture. Maintenance is easier and faster. This saves developers’ time, thereby increasing efficiency and ultimately saving organizations money. What’s not to like about that? In addition, microservices allow for faster evolution and upgrades – no need for massive codebase refactoring when adding new features.
In microservices architecture, you only need to scale the app components impacted. In the legacy approach, the entire application had to 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.
Because the test surface is smaller, testing is far easier with microservices 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 easier to monitor.
Developers deal with complex issues on a daily basis, and microservices provide a way to simplify much of the work, leaving you more time to focus on more important matters.
Fixing What’s Broken
One of the great benefits of microservices is how they enable developers to address how applications evolve over time. With microservices, developers can fix just the broken component, without having to repair the entire system as a whole. 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.
Let’s think of this in terms of car repair. If a headlight goes out, do you really need to take the car to a repair shop for a thorough overhaul? Not only would this be inconvenient, but it would also be time-consuming and costly. Fortunately, cars essentially use a microservices approach. You can keep driving even with the burnt-out headlight, 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 a good analogy for how a microservices approach works in practice.
Another technology that has gained popularity recently is containers. This new way to package, distribute and run software greatly compliments microservices. With the right tools, you can now create systems using microservice 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
A Strong Partnership
A key point to keep in mind is that, oftentimes, it isn’t worth the effort to refactor existing systems as long as they work adequately and provide the service you need reliably and with good enough performance. Transforming existing legacy system to microservice 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.
The great thing about microservices is that you can decide how they will best serve your organization. You don’t have to choose one design approach over the other. Instead, microservices and legacy systems can be used simultaneously. It’s now possible to package software in a way that better serves today’s business needs while tending to the legacy systems that have served you well in the past. Microservices let you chart a course that defines what success looks like for your organization.
This post is part of our contributor series. It is written and published independently of TNW.