Red Hat announced new capabilities and enhancements across its portfolio of open hybrid cloud solutions aimed at accelerating enterprise adoption of edge compute architectures through the Red Hat Edge initiative.
More and more, developers are embracing microservices when it comes to building applications. The growth of cloud and mobile technologies has seeded the need for developers to move away from traditional monolithic approaches to development. 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.
Microservices aren't a completely new concept, but rather a new incarnation of previous concepts. As IDC analyst Al Hilwa 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 idea behind microservices 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.
When it comes to large applications in particular, this approach makes the process easier for myriad reasons.
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. In microservices architecture, you only need to scale the app components impacted.
Ease of Use
When it comes to microservices, testing is far easier than with monolithic applications 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.
With the complex challenges the developer faces each day, microservices provide a way to simplify much of the work, leaving more time to focus on more important matters.
Microservices architecture enables a faster workflow. Maintenance is easier and faster. 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.
Developing for Failure
Applications evolve over time. With microservices, developers can fix just the broken component, 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.
Think about when a tail light on a car stops working. 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 tail light, 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.
Why Microservices Now?
Unless you have been disconnected from Internet for the past few years, you have most likely 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.
What About Existing Legacy "Monolith" Systems
It's important to remember that often it does not make sense to refactor existing systems as long as they work just ok 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.
In most cases, microservices aren't meant to be a complete replacement of legacy systems. Designing with microservices isn't a one size-fits-all approach. Like any solution, there are tradeoffs along with the benefits. However, there is no reason that microservices and legacy systems cannot be used together in the same environment, and there's no reason that we have to package software the way we used to.
Miska Kaipiainen is CEO and Co-Founder of Kontena.