I frequently speak with architects, CTOs, and CIOs about the challenges of determining where, how, and when to leverage public cloud resources. Having a framework in place that steers cloud-based solutions can be a daunting task, particularly one in line with an organization’s overall cloud strategy. Core choices such as “Infrastructure as a Service” (IaaS), “Platform as a Service” (PaaS), “Containers as a Service” (CaaS) or “Software as a Service” (SaaS) are all nuanced, with variability determined by both architectural and provider choices.
At a high level, you can break down cloud architectural choices into three fundamental options:
Provider-Native Platform Services
Provider-native platform services offer a high degree of speed and agility, but are often extremely sticky, making exit costs extremely high. Many organizations that I work with use a variety of cloud services in this category, and they go into the provider relationship with the understanding that a particular service will live and die with a cloud provider. It’s not to say that you can’t pack up and move, it’s just that it can be extremely costly because those services use many APIs that are unique to the service provider. The stickiness analogy is similar to experiences most have with some enterprise database platforms. A technology argument can be made to migrate to a new database platform, but from a business perspective, migration may not be worth the expense and effort.
That doesn’t mean that you avoid provider-native solutions. For example, Office 365 is strategic to many enterprises and offers considerable value. You could say the same for AWS Mobile Hub, which is a great service when, for example, you’re under pressure to hit a six-week deadline for a new marketing-related mobile app and are unsure of the global scale requirements. You could get the app built quickly and have the capability to scale as needed.
While many enterprises will use a variety of platform services from AWS, Azure, and GCP, they still value centralizing some key operational services. That may include managing and enforcing network and security architecture, policy, and operations. This is also true for cost management and service-level assurance. We see the VMware Cross-Cloud Architecture™ adding considerable value in each of those areas.
Public or Private PaaS/CaaS/FaaS
PaaS, CaaS, and “Functions as a Service” (FaaS) can seamlessly manage application packaging, deployment, and lifecycle across multiple clouds, data centers, and branch/edge sites. For example, Pivotal Cloud Foundry provides an enterprise with a common PaaS that spans data centers and multiple cloud providers, such as AWS, Azure, and GCP. Container or CaaS solutions, like Docker or Kubernetes, can also provide a singular approach to cross-cloud application packaging, distribution, and maintenance. PaaS, CaaS, and eventually FaaS (e.g., Spring Cloud Functions) are not just about flexibility for the app lifecycle; they’re also about control.
These solutions allow an enterprise to maintain full control of its intellectual property (IP), leverage the strategic open and closed source platforms it chooses (including software versions), and allow its engineering teams—not a service provider—to dictate a service’s maintenance schedule. IT decision makers that I speak with see these solutions as strategic for the majority of their core differentiating applications, whereas they envision provider-native services for applications where they willingly cede some control of IP and maintenance to the provider. Offloading maintenance to the provider may sound like a good thing, except when software engineers are pulled off of a new R&D initiative to certify a platform upgrade mandated by a provider. When deciding between a PaaS/CaaS offering, or a provider-native service, just ask yourself how much control you want or need. If the answer is “none” or “not much,” then the provider-native service is likely the best choice. For all other new applications, look to go the native, PaaS, or CaaS route.
PaaS and CaaS offer many benefits, but one challenge that often arises is operational drift. Operational drift occurs when a PaaS or container service runs on multiple clouds and requires different tools, processes, and integrations with different APIs for operational management in each environment. For example, drift may occur with network configuration and management, security policy and enforcement, audit, application remediation and telemetry, performance management, backup, and so on. You can have all the application agility in the world, but a lack of operational agility can degrade the PaaS or CaaS value proposition, which brings us to IaaS.
Public or Private IaaS
Regardless of whether it’s called IaaS or simply “abstracted,” a universal truth in IT is that all applications and services require programmatic computation, storage, networking, and security. Infrastructure as code must exist, whether it’s offered as a native service (i.e., IaaS) or abstracted below a PaaS or CaaS solution.
IaaS has long been popular because it can run just about anything, like a traditional application, PaaS or container. IaaS can support any x86 application environment while providing operational consistency across them, eliminating the PaaS and CaaS shortcomings mentioned earlier. Of course, the IaaS itself can become a point of friction if it also uses vendor or provider-centric APIs. Operational agility will depend on the infrastructure-as-code’s ability to run anywhere (e.g., cloud, data center, or branch/edge location). This can leave you with a couple of options:
Committing to a single solution—one I like to refer to as “globally consistent infrastructure-as-code”—can be possible without fear of lock-in so long as the infrastructure integration points predominantly use open source APIs at either the PaaS/CaaS layer (e.g., Cloud Foundry, Docker, or Kubernetes) or the IaaS layer (e.g., OpenStack or Photon). Multiple IaaS or infrastructure-as-code solutions are the reality for many today, but they come with the added cost and complexity associated with maintaining multiple operational silos.
Best of All Worlds
When you can layer a globally consistent PaaS on top of a globally consistent infrastructure-as-code platform (e.g., VMware Cloud Foundation), you can achieve the best of all worlds: speed, agility, security, scalability, and efficiency for both developers and operations. Developers can get the PaaS or CaaS they prefer, using native APIs, and get consistent telemetry regardless of where an application resides. Operations can have consistent visibility, policy, and management as well. This approach, once referred to as “Developer Ready Infrastructure” by Pivotal SVP James Watters, can create a DevOps nirvana where both developers and operations get everything they want to do their jobs most effectively.
There will never be a silver bullet or one-size-fits-all solution for every business need. Strategic use of both provider services and a combination of PaaS/CaaS and IaaS/infrastructure-as-code will allow you to get the most out of innovations that make a service provider environment special, while also giving you full control of critical business IP where required.
For more information on globally consistent infrastructure as code, take a look at my blog post on VMware’s Office of the CTO blog site.
