By Brandon Knitter – Technical Consultant
The software industry has seen a lot of change over the past many years. There was the mainframe. At some point, we moved to the client-server. The web gave birth to the three-tier architecture. Eventually, there was SOA, and CORBA reared its head like a dyslexic snake. There have been many software design patterns proclaimed to be The Best™ over the years, each one has evolved or been supplanted by the next. And now we have the so-called fad that is Microservice Architecture.
The New Era
The promised benefits of efficiency and interoperability from SOA/CORBA are still very much desired. The desire is one with more openness, flexibility and the ability to pick and choose. Microservice Architecture was imagined as an alternative to, or and implementation of, SOA.
But Microservice Architecture is not something that requires you to go all-in on. There are parts of Microservice Architecture that are bread-and-butter, while others are esoteric or unique to a specific application genre. No matter the level of adoption, Microservice Architecture has some really good ideas and concepts that are decades in the making. Even if not implemented fully, the concepts of Microservice Architecture are more than a passing fad and worth taking the time to gain an understanding.
Like SOA, Microservice Architecture offers the benefit of small teams that could be formed to focus on one piece of logic and the consistency of access. An only strict requirement is a contract for accessing this functionality, and so we have the API definition. The API not only allows access to a service’s functionality but also gives a consistent and expected mechanism to do so.
Besides the small team approach and the consistency of access, there are additional benefits. Let’s explore these.
The Benefits
Microservice Architecture follows the Single Responsibility Principle (SRP). This principle is applied broadly in the software engineering world whereby a single function performs a single duty. If the logic becomes complex and requires more functionality, then the logic is split between multiple functions. This allows for ease of change and understanding and ultimately code readability improves. As a function, the enforcement of SRP is within the service’s API. Applied to Microservice Architecture, each microservice itself performs a single function (the implementation is of course abstracted).
Microservice Architecture also allows for an independent release schedule. So long as the API does not change, the underlying microservice logic can be modified many times without affecting consumers. Functionality can be added to the existing API as the API remains backward compatible and extended to include new features. Compare this to the monolithic architecture approach of deploying all logic as a single release and the coordination complexity becomes maddening as we try to synchronize client and service compatibility.
Even with a library approach where each piece of functionality is compiled into separate libraries and then assembled into a single release, the revision and compatibility of each library version come into question. In a world where a defect in one small component of the software is expected to be fixed and released in near real-time, coordinating between hundreds of software engineers, thousands of logic components, and millions of lines of code; expedient defect resolution becomes an unimaginable task. Splitting the logic and code between microservices makes a large problem become small again.
And while software continues to drive our world, I hate to be the bearer of bad news but software breaks. Shit happens. Get over it! Microservice Architecture doesn’t protect against a software defect, but it does contain the impact. By containing the logic of individual components, in even the worst-case failures or a system crash, this will only affect a single service or possibly only a single API method. Developed properly (using other techniques such as canary and blue/green deployments is outside the scope of this article), isolation provides the ability for degradation of services. We’ve all experienced a product or website that mostly works except for one feature or module. This is isolation in action and is sometimes referred to as “degradation of service” since the failure does not render the entire set of functionality useless.
Now, you know that your marketing team always promises big numbers…ALWAYS! And every now and then the marketing team comes through. In those clutch situations where one feature or component of your application scales quickly (or differently), separating your application into different microservices can achieve independent scaling of individual features. This includes assigning greater or fewer compute and storage infrastructure resources and customized configuration of said resources. One microservice may need a high CPU, another high memory, and still, another may utilize storage in an unimaginable way. No matter the characterization of your microservices, independent scaling offers tremendous flexibility and response to user adoption.
We’ve all said it: use the right tool for the job! But there is a balance. If every component of your application is running something wildly different you suddenly have a skills requirement that is nearly impossible to fill. Conversely, choosing a single technology starts to make every bolt, screw, and rivet look like a nail. Microservices can be deployed distinctly and therefore can enjoy the benefits of choosing the right tool for the job. Caution should be used to evaluate your standards across the landscape and ensure technology sprawl doesn’t occur.
The Cost
So far we’ve sung the praises of Microservice Architecture, but as with any deployment scheme or chosen technology, there is no such thing as free beer (or lunch). There are supporting cast members in this production that must be choreographed properly in order to achieve the eventual outcome. Solutions such as service discovery and monitoring are key to any system and implemented in a standardized way to accomplish consistency. These supporting functions begin to look like microservices themselves in many cases.
Depending on interoperability and the performance requirements, the right intercommunications protocols (REST, protobuf, Avro, grpc, XML-RPC, etc.) must be chosen to ensure successful adoption. While REST may be the most popular protocol and access method due to ease of use and compatibility, protocols such as Avro reduce overhead as messages are binary encoded (serialized) and lack much of the verbosity of REST. Selecting the right communications protocol is as important as it is unique to the application.
Perhaps the most difficult challenge, and independent of the technologies and implementations, all teams building and interfacing with microservices must accept and agree that Microservice Architecture is the correct methodology. Doubters cast doubt. Refusers will refuse. Naysayers say nay. Socializing the benefits of Microservice Architecture is only the first step, albeit an important one. Providing the support infrastructure is equally as important. And a demonstration of success is the ultimate forcing function. Educate and convince your team before embarking on your mission (should you choose to accept it).
Thoughtfulness when implementing Microservice Architecture is still a requirement. No matter the benefits and regardless of the technologies are chosen for a Microservice Architecture implementation, a design methodology is no excuse for a lack of planning. Should a wild west attempt be made by a cowboy team shooting from the hip, the outcome will be no less a bag of nails than expected. Call the sheriff and get things under control. Be mindful of the outcome and decide the adoption sequencing ahead of time. Take the time to design your APIs and functionality.
Monoliths looking to migrate to Microservice Architecture must have the right plan. APIs must be well-defined and consistent across services. Protocols must be efficient. Services must be responsive. Security and access controls must be implemented, managed and monitored. All of this matters, but remember to gain momentum and broad adoption lest you have pockets of innovation, mired and lost in a monolith that doesn’t change the overall outcome.
The Summary
Clearly Microservice Architecture is not the end of the line, but it is the end result of years of software and system design evolution. Will there be something better than Microservice Architecture? Of course, there will be! Microservice Architecture doesn’t come without complexities and deficiencies of its own. This is the best we’ve got right now, so dive in and take the time to learn about the technique.
With enough understanding and experience, you can apply Microservice Architecture design to your environment. And who knows, maybe you can be an influencer on the next great thing that comes after Microservice Architecture.
As the great Charles Darwin said, “Man is descended from a hairy, tailed quadruped, probably arboreal in its habits.” Shave your back, cut off your tail and step down from the trees…it’s time to accept evolution!