The Shift to Microservices
The shift in application development strategies is moving from monolithic design to isolated and resilient components known as microservices. As a result, applications that were designed with platform entanglements such as database and messaging layers have become more complex and costly to operate and maintain. This provides new challenges to CTOs, who must stay aware of the most dynamic, cost-efficient, and secure methods of managing their company’s data, while navigating the inexorable slide toward a microservices economy.
Mike D. Kail, CTO of Security-as-a-Service firm Cybric.io, points out that “with the rise in popularity of Docker Containers, there is an associated belief amongst many that by simply moving an application to leverage containers instead of virtual machines or bare metal, that you then get microservices by default.” But, he says, “that is certainly not true.” Microservices is an architectural pattern, and containers can be part of the technology using that pattern, but containers remain a “thing” while “microservices” is still a “notion.” This pattern can be used to either re-factor an existing application, or more easily leveraged for greenfield initiatives.
Central to the popularity of microservices is the ability to overwrite or replace an individual component without taking down the entire application, leading to less downtime and faster deployment or redeployment of software into an operating environment. Immutable infrastructure also helps with overall security as an APT can be rapidly mitigated by “refreshing the deployment”. This is also a concept shared by microservices – a modular and agile codebase, each part maintained by individual teams.
Microservices is an approach that is still evolving. It is a process being spearheaded by some of the biggest players in the business, like Walmart, Amazon, and Netflix. It is a technological ideal intended to ensure an organization’s ongoing agility and flexibility. This in turn allows faster and more intelligent response to immediate market demands like volume spikes in online shopping or movie watching.
Microservices need not be small, as the term “micro” might imply, but each service is dedicated to a single task or process. This allows for the components to be taken offline and edited, rebuilt, or replaced, without having to take an entire application down with it. This in turn allows for improvement on the fly, with less scheduled downtime, which leads to better business continuity.
The switch away from monolithic applications to collections of compartmentalized or containerized components seems to offer a much more practical approach to managing application development. They can be scaled separately and deployed as needed. They can be designed and programmed separately using different platforms or languages. And testing becomes more affordable, targeted, and frequent.
So What Problems Do Microservices Pose?
According to JP Morgenthal, Managing Editor of Microservices Journal, as applications get decomposed into microservices there arises a range of challenges around managing the sprawl. “In short,” he says, “no one knows the whole picture. They only know what’s wrong with their part.”
He points out that the previous generation of monolithic applications were expensive to maintain because of the high degree of entanglement of the components. Changes required more complex releases and longer testing cycles, yet at the same time, their design fostered simpler operation using fewer components.
“But as we move to polyglot microservices that leverage existing cloud services and are much more elemental, we still see an increase in the number and types of things that impact applications. This in turn increases complexity on the operations of these applications.”
What’s the Diagnosis?
Morgenthal highlights a need for greater involvement of developers in the cycle, specifically, full stack engineers and site reliability engineers. “The factors and attributes associated with design of microservices further increases complexity due to the way data management changes and the nature of discrete transactions.”
Wanted: A New Approach for CTOs in Managing Microservices
The very thing that makes microservices a more practical application development practice – compartmentalization – leads to an incomplete management perspective. “There is now a more urgent need for end-to-end management – something that has never truly existed. We need to break down the silos between organizations and departments, and we need to move from reactive to proactive. This would be the nirvana of modern applications management,” says Morgenthal.
This puts the role of the CTO in a new, indispensable light, as someone who must take complete end-to-end ownership of an application’s life cycle, encourage communication, and understanding across all teams and timelines involved, and be capable of knowing the entire process.
Mike D. Kail of Cybric.io, himself a CTO, adds more. He states, “I believe that the role of the CTO is more relevant today than ever. As with Digital Transformation, every company is becoming a technology company. The modern-day CTO needs to have the technical chops to drive the overall product/platform vision internally and the soft skills and business acumen to drive outward facing initiatives as well as communicate effectively and clearly with the other C-suite peers.”
Overall, the challenge of establishing full end-to-end management of microservices resembles the typical left-brain/right-brain dynamic of a living corporate entity. The logical processes of developing and refining a highly versatile and compartmentalized application need to be balanced with a refined approach to human communication within IT-Ops, upwards to senior management, and outwards to those who will ultimately benefit from it. This requires a blend of political acumen and technological know-how, something that will make CTOs more visible and indispensable as the microservices trend continues to expand.
Sponsored series by Sumo logic
By Steve Prentice