Welcome to the VMware OCTO Application Platforms Team Blog
Today we are releasing an Application Platforms OCTO Position Paper
Brief Overview of the paper…
We often meet customers that have migrated to the public cloud only to later determine that some of their critical legacy application patterns have transitioned to a public cloud implementation, and they are now paying higher costs due to this design flaw. Regardless of cloud location, what really matters is how well you have abstracted the application platform nature of your enterprise workloads. If you don’t understand your application workloads in terms of scalability, performance, reliability, security, and overall management, then you are simply shifting the problem from one cloud to another.
From our perspective as we interact with customers, we continue to see customers struggle with building good application platforms. Often various challenges exist with stability, deployment, and scalability—certainly more than fifty percent of customers we interact with have some sort of application platform challenge. More so, we continue to see that, whether in a private or public cloud, customers are provisioning more hardware than what is required—in some cases twice what is needed. So why is this happening? Movement after movement has attempted to solve this phenomenon of excessive hardware provisioning in the last two decades, but we still find ourselves in the same old situation where an application fails to perform and the old response of throwing hardware at the problem.
IT practitioners are bringing their old habits to new problems. The key to this problem is deeply rooted in the knowledge gap that exists between development and operations organizations. In this paper, we talk about the notion of the application platform and its teachings to close the gap that exists between developers and infrastructure architects. At the most fundamental level you can think of application platforms as an abstraction of three major parts: 1) application code logic; 2) application runtime where the code runs; and 3) infrastructure abstractions such as CaaS, K8s, and fundamental IaaS.
The current cloud-native movement can be viewed as an example of application platform thinking. For example, cloud-native practices are about developers marching into infrastructure practices, using infrastructure-as-code techniques to fully automate current manual steps of provisioning the Infrastructure-as-a-Service (IaaS), and Container-as-a-Service (CaaS). No doubt, CaaS is a big part of this as a key abstraction.
