When you think of why customers move to the cloud, there are a few key things that they’re trying to achieve.
Agility
How do I do more with less. How do I innovate faster? How do I deliver new products and new capabilities to market quicker? How do I disrupt the industry that I’m operating without letting anyone disrupt me?
Elasticity
How do I move away from the mentality of all the resources I would ever need at my disposal, to capitalizing on the fact that in the cloud I can truly only pay for what I use? How do you move that from a statement to reality?
As part of these two initiatives, customers’ mentality shifts towards microservices and managed PaaS. The reality is that future application architectures are going to end up being a combination of multiple types of services and multiple types of application components. Microservices are key to innovation because they allow you to separate concerns. They allow you to make sure that any kind of new functionality or improvement that you want to add to your business driving applications is contained.
Let’s say you manage a building. Every time you want to do anything to your building, you’d have to retest the entire structural integrity of the building. If you don’t, every time you changed something the entire building would be in danger of collapsing. It’s very inefficient, and that is the problem microservices come to solve.
On top of that, Managed Services eliminate the need to update or patch instances. For example, when Meltdown and Spectre happened, the entire industry was in flux because every organization had to divert massive amounts of people to update their environment and remove that risk. Another example is SQL End of Support, organizations and CIOs once again have to divert people to figure out how to handle it. What is going to be affected? Do they pay for extended support? Do they upgrade? What is the engineering effort? And so on…
If you move to managed PaaS services, both the updating and the patching get managed by someone else. You don’t care about SQL End of Support if you’re running on AWS RDS or SQL DB on Azure. Those are all managed for you.
If vulnerability and the underlying application component is identified, the cloud provider handles this for you when you are leveraging these new services.
Now, the organization is able to focus on the core, not the chore.
Focus on that. Patching and updating isn’t one of them. So, when we think about future application architecture, it’s all about “How do I innovate faster and how do I focus my people on what matters most to the business,” and that’s why microservices and managed PaaS services are really shining as the components of the application of the future.
Turbonomic’s 2019 State of Multicloud, the industry’s first survey of over 800 IT professionals, reveals that 83 percent of respondents expect workloads to move freely across clouds. The report’s data also shows that IT organizations are beginning to place a higher degree of trust in Containers, with respondents categorizing nearly one third of containerized applications as mission-critical.
That application of the future isn’t built on one managed service, it’s built on a combination of multiple services and multiple technologies. Some of them are containerized, some are going to run on a specific managed service, different data layers will be involved. Applications will combine all of that together. Each of those services or technologies has their own cloud catalog, complexities, cost structure, and optimization levers that are exposed.
Now when you think about the application of the future, each of those services is highly dynamic and elastic, but the complexity increases significantly as well.
It’s hard to understand and optimize just the IaaS layer. AWS EC2 has millions of configuration options. That’s complex enough and that’s why most organizations leverage only a small portion of it. One of the things that the cloud providers have done amazingly well is to make sure that each application component, each type of service, will have an ideal configuration for it. Identifying what configuration is the right one for each application is hard enough when you have one monolith application and one service.
Understanding this across 100s of microservices and 10s of services and how they work together, is exponentially more complex.
If you have an application spread across hundreds of components, tons of different services, all working together to deliver one response time, what happens if that response time is not what you want? Where do you start? What do you change? Each component, if changed, is going to affect all of the other ones. Where would you get the biggest bang for your buck? Where do you start optimizing?
In conclusion, to truly leverage the agility and elasticity of the cloud, architects and devops personnel of future applications will choose a combination of services, and as a result will also have to deal with the complexity that comes with it. Before choosing an application architecture, you have to evaluate the challenges of operating at scale. You have to understand all implications on cost and performance.
By Mor Cohen-Tal
