By Tom Hite, Sr. Director, PS Research Labs; Emad Benjamin, Sr. Director, Chief Technologist for Cloud Application Platforms; and Grant Shipley, Sr. Director, Kubernetes Field Engineering
Last year we published a definition of a robust Modern Application Platform (“MAP”) as comprising three important components: development tools and frameworks; runtime platforms; and sustainability services. Not too long after penning MAP some VMworld announcements announced a tighter message around Tanzu leaning toward a portfolio of products and services for application modernization using three other terms: build; run; and manage.
For Tanzu, VMware rightly received accolades, but also some questions arose on whether and how Tanzu’s build, run and manage supports building a robust MAP. Let’s close the loop around the two different three-term sets!
Quick Aside: we shamelessly title this article as a play on the awesome What3Words. It has no real connection to the discussion; it’s just a cool app and the words were right
While closing the loop, we expand things a bit with a couple more terms related to app modernization – connect and protect. The market has moved from the early days of modern applications strictly meaning something that complies with stateless 12 Factor principles to a more current, enterprise applicable understanding where stateful meets stateless somewhere in the middle. With this understanding, the current notion of modern applications is more aligned with enterprise and cloud reality: a myriad of traditional, cloud native, refactored enterprise applications and public cloud services are all in constant connectivity and interaction to fulfill the modern business needs.
Such connectivity needs a common connecting fabric to provide a holistic view. Regardless of how one understands modern applications and platforms, we believe fundamentally there are ultimately five governing vectors of concern when it comes to application modernization, centered around how to build, run, manage, connect, and protect.
In his blog about Tanzu, Paul Fazzone lays out pretty clearly with Tanzu “VMware helps customers BUILD modern applications.” That doesn’t mean Tanzu itself tries to provide every last MAP development tooling and framework component needed to provide “efficient development, deployment and sustainability of software.” For example, the Tanzu portfolio doesn’t purport to provide an editor, such as VSCode. However, MAP included build as part of development tools and frameworks: “code | build | release.” It turns out Tanzu still helps out a lot in terms of building and releasing apps.
Through Project Galleon and our recent Pivotal acquisition, Tanzu implicitly supports more than one might immediately think regarding modern app development tools and frameworks. As Paul notes, Project Galleon lets developers “grab [curated, continuously maintained] applications and components to quickly assemble and deliver their own applications.” Assemble == build in developer parlance.
Consider also that, though not explicitly mentioned alongside Tanzu, Pivotal comes to VMware with a wealth of tooling such as Pivotal Concourse CI/CD tooling, Pivotal Tracker agile planning and many other components in the 10 Foundations of DevOps we noted in MAP. Pivotal also brings many core frameworks needed for a MAP such as: Pivotal Build Service, which allows developers to automatically create containers based on their source code; Spring; and many more.
For the remainder, our Professional Services and Field Engineering teams are here to fill any minor gaps.
Longer story short: Tanzu provides quite a bit of support for the development tools and frameworks outlined in MAP.
MAP laid out the need for well-formed runtime platforms onto which apps bind and execute. We raised two needs: application runtimes and data platforms.
What about Application Runtimes?
As we noted in MAP, “VMware’s SDDC represents a software runtime for virtual machines and is very much an application runtime as well.” Further, runtime needs more often than not also include Kubernetes. From these perspectives, Project Pacific and Tanzu Kubernetes Grid unquestionably fill this need – little is left to be said about that!
That leaves only application runtimes like Java VMs or similar. Those are not directly Tanzu issues. Runtimes are part of what gets built as discussed above. Thereafter, as described in MAP, they become part of the platform once bound to and executing thereon.
What about the Data Platforms?
Covering off on data platforms, for now Tanzu rests on Project Galleon. Bitnami application catalogs provide quite a number of readily available data platforms that provide relatively easy binding into and execution within the app platform. These then become the specialized application runtimes we noted in MAP that stateless apps can use to persist their state.
Managing software execution is part of what MAP refers as sustainability services. That topic covers a very broad array of needs, including observability and anomaly remediation to maintain service level objectives.
Achieving sustained operations with Tanzu involves both Project Pacific and observability capabilities. In Project Pacific it was noted that the product enables developers to “manage cloud resources like virtual machines, disks and networks” in familiar Kubernetes API form. Further, the article notes that same standardized Kubernetes form enables IT administrators to “manage a whole application instead of always dealing with the individual VMs that make it up.”
Looking to Tanzu Mission Control, Tanzu provides a very complete set of capabilities for unifying the management of Kubernetes within and across multiple clouds. That includes, among many others, developer self-service, cluster lifecycle management, data protection, policy-driven security, identity and access management and observability.
Incorporating observability also goes back to adding data runtimes like vRealize Operations, vRealize Log Insight, Wavefront, Prometheus and OpenTracing solutions, among others. These are introduced into Tanzu by building them in to the applications or binding their endpoints as part of the assembly of applications and data runtimes making up the overall modern application.
Finally, Tanzu can never replace site reliability engineers, but to the extent we can reasonably unburden them, MAP proposed that observability properly bound in the app platform enables several auto-remediation controllers. These were introduced in our OCTO paper. The Tanzu portfolio implicitly supports such auto-remediation. Indeed, Kubernetes, a foundational component of Tanzu, is inherently based on auto-remediating control system concepts.
We have spent much time building cloud architectures in past decade, to only realize that now we have fostered an era of widely distributed application services across multiple clouds. With this paradigm shift, one needs to introduce new runtime connectivity layers with an understanding of the service call graphs. The rise of the Service Mesh in the industry plays a critical role in establishing holistic, multi-cloud connectivity. With NSX Service Mesh (“NSX-SM”) the MAP provides easy access to observability, federation, unified operations, and an enhanced security model.
VMware in recent years has made significant strides to continue to push the edge of our intrinsic security solutions. Fundamentally, with such wide flexibility offered by highly distributed modern applications, a singular, siloed security solution is not feasible. We have to venture into more prescriptive and holistic solutions that encapsulate security posture end-to-end across the entire MAP. Here, NSX-SM, with its holistic graphical view of the service world, such security models are finally possible.
Between Tanzu’s “build, run and manage (and now connect and protect)” and our earlier “developer tooling and frameworks, runtime platforms and sustainability services,” which terms are best? Both work, but the former seems to many easier to remember and fits current industry needs: a well-formed portfolio of products and services that strongly supports building a robust MAP.