By Tom Hite, Sr. Director, PS Emerging Technology; Emad Benjamin, Sr. Director, Chief Technologist for Cloud Application Platforms; Cameron Haight, VP & CTO, Americas; Roman Tarnavski, Principal Architect
Leaders in information technology get barraged daily by assertions they must modernize applications or face a likely business downfall. Indeed Gartner notes that “to compete with top performers, application leaders must transform their development and platform strategies”. Consider also that Forrester suggests, “in 2019, cloud computing will firmly establish itself as the foundation of tomorrow’s enterprise application platforms.”
VMware fully supports these views. Moreover, based on our experience with customers, we find every reason to believe the application platform is a critical part of modern applications. For example, a recent VMware Office of the CTO paper (“OCTO paper”) suggests “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.”
What is an Application Platform?
The term “Application Platform” has quite an array of definitions with varying histories. For example, The Open Group suggests application platforms sit between applications and the underlying communications infrastructures. For a deeper understanding of their perspective, visit their architecture documentation. To be sure, there are other views as well, such as those gleaned from Amazon Web Services and IBM.
We provide a perspective that takes a bit more of the future in mind and reference again the OCTO paper, which suggests: “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.”
By this, we don’t intend to say that that an application, or more specifically application code logic, is part of an application platform when in the development stage. However, when deployed to and executed in the context of an application runtime, application code logic binds to and becomes part of that context. Therefore, timing matters from our perspective.
In an attempt to provide more specific guidance for our customers, VMware describes an application platform as a set of services that provide for the efficient development, deployment and sustainability of software. It consists of:
- Development Tools and Frameworks
- Runtime Platforms
- Application Runtime
- Data Platforms
- Sustainability Services
Development Tools and Frameworks
Development tools and frameworks provide support for what might be called the ‘code | build | release’ cycle. This often involves agile planning and tracking tools, continuous integration and deployment (CI/CD) engines, testing tools, release packaging tools, artifact registries and more. All in all, development tools and frameworks are comprised of the tooling that fills each stack in the 10 Foundations of DevOps (see Figure 1: Delivery Pipeline Tool Chain, page 8 therein).
Note: Take care to consider that ‘code’ and ‘build’ are not limited to application business logic source and compile tools. For example managing a Kubernetes manifest generally involves editing (coding) a YAML manifest file and applying it (the ‘build’) to achieve the intended state the manifest describes. When deploying and managing packaged applications, coding includes editing Cloud Assembly blueprints, Terraform templates or the like.
Runtime Platforms
Software obviously has to run, connect to networks and often store data (minimally store virtual machines, containers or raw executable code). Among others, these are services provided and abstracted by the application runtime.
Historically, we have viewed application runtimes as abstractions generally meant for a single executable program. For example a Linux distribution for statically compiled Go applications or a Java virtual machine for Java programs. The basic nature of such runtimes, however, did not take into account distributed software operations.
Modern applications often are comprised of microservices orchestrated by Kubernetes and manage data across multiple clouds often via REST calls. We therefore take the view that an application platform provides both an application runtime and data management platform.
Application Runtimes
Application runtimes are components “where the code runs.” By code, we mean application logic of any sort. Such runtimes include: infrastructure as a service facilities (see page 3 of NIST) such as those offered by VMware, Amazon and others; platform as a service (see page 2 of NIST) such as Kubernetes, CF Runtime and the like.
By way of example, VMware’s SDDC represents a software runtime for virtual machines and is very much an application runtime as well. Indeed, we note in the OCTO paper that “when we coined SDDC, what we really meant was a Software Defined Application Platform (SDAP), because almost all generic hardware designs are taken by our customers and customized for a set of application platforms.”
Further examples of application runtimes include Apache Tomcat, Kubernetes (including service meshes) and many others. Most often, modern runtimes are deployed into virtual machines and containers.
Data Platforms
A robust application platform provides for data services that provide end-to-end, multi-cloud capable data orchestration. By data orchestration, we mean the ability of the platform to codify and enforce policy and control over the movement of data within and across clouds. This includes services for data classification, governance, security, observability, storage, networking and application runtimes.
As noted in our Six Sevens paper, the point of software applications is to “carry out operations necessary to create added value from the information data flowing between” software components.
What this means is the vast majority of applications require backing services for orchestrating data movement and persistence. Backing services include such facilities as encryption capable block storage, databases, shared file systems, live or cold virtual machine migrations, container image sharing, and much more. As we note in the Six Sevens pattern, data movement problems in modern applications are exacerbated by the fact that the vast majority of organizations modernizing their software have already acquiesced to (yet will ultimately benefit from) the utilization of multiple cloud providers in the deployment of their software.
NOTE: we classify data platforms here as a special sub-category of application runtimes, because backing data services themselves are encapsulated inside similar runtimes as those that run the application code. This is important to know as one can apply similar methodologies across the two, but obviously with the added need to know how to manage data persistence and state.
Sustainability Services
The intent to meet service level objectives is the topic of sustainability. To sustain desired operational states of software, focus has to be on the ability to provide observability and anomaly remediation services. More robust application platforms will support auto-remediation of problems identified by the observability features of the application platform.
Put briefly, observability consists of monitoring, logging, distributed tracing and related visualization and alerting facilities. Alerts are becoming much more software oriented than manual (a human receiver). That is what supports auto-remediation, which is a hot topic in the industry.
Auto-remediation, in brief, is the capability of an application platform to sense (observe) the entirety of running software and detect when its operational state falls out of expected parameters. For example, where response time between software service-to-service calls take too long.
The OCTO paper mentions the notion of several remediation controllers, but particularly the Predictable Response Time Controller (PRTC). This controller allows Site Reliability Engineers to define a service level objective (SLO) across a set of application services, whether microservices or other application service types independent of application runtime. The controller will then intelligently auto-scale based on complex metric thresholds to deliver the SLO defined response time.
Where such automated remediation cannot resolve an issue detrimental to SLOs, it is likely the remediation facilities would feed the issue to the planning tooling of the development tools (i.e., the feedback stack in the 10 Foundations of DevOps), thereby completing the iterative cycle of build, release, and run.
Conclusion
Modernizing applications is an effort which requires a broad focus including software (re)architecture as well as the consideration of new places and models on which the new architecture will execute. The application platform has become an industry standard offering but has lacked a definition which is expansive enough to incorporate the lifecycle perspective which we at VMware think is required. At VMware we are here to help you through your modernization journey and welcome the opportunity to serve your needs.
