As a friend frustrated with the current dearth of new enterprise tech trends recently lamented, “everything is about the cloud.” I’d add that even some big tech companies that have little to do with cloud computing seem desperate to associate themselves with it, because the cloud has become all-encompassing.
In a broad sense, the cloud is about running and/or building applications on someone else’s servers. But it has become much more than that: a vast ecosystem of cloud services that businesses are using to accelerate time to market for advanced applications across nearly every domain imaginable. No wonder IDC predicts that public cloud spending will hit a whopping $210 billion this year, up 24 percent over 2018.
But success had muddied the waters. A side effect is persistent confusion over what really qualifies as cloud computing and what doesn’t – and where the benefits of cloud computing really lie.
Cloud or not cloud?
At this point, most people understand the core benefits of the cloud, beginning with the capability to scale applications dynamically. That applies to the three basic cloud flavors offered by public cloud providers – IaaS, SaaS, and PaaS – all of which give you self-service UIs to set up accounts, upload data or code and configure whatever services you’ve subscribed to.
But the noise around cloud is deafening. Before we get to the most exciting of today’s benefits, let’s filter out some of that noise:
The private cloud. This refers to IaaS in your own data center. Yes, any enterprise can make local infrastructure cloud-like, with well-managed virtualization and the capability for users to self-provision (typically using VMware’s full SDDC stack). But that’s not the same as the cloud. Why? Because the cloud is a service. You don’t have to worry about capacity planning, power management, physical floorspace, and all the other details of running your own data center. Your provider handles that. All you need to do is fire up your account and go.
The hybrid cloud. Sorry, this is not “a cloud” either. The standard definition is that it’s two integrated clouds, one private and one public – but integration can’t unite two into one. Problem No. 2 is noted above: There’s no such thing as the private cloud … with one exception that applies to the hybrid paradigm alone. The three public IaaS clouds that currently matter most – AWS, Microsoft Azure, and Google Cloud Platform – all offer fully managed instances of their clouds that you can deploy on premises. They are basically extensions of the big three’s public clouds.
Why would you pay for both cloud infrastructure and a managed public cloud stack on premises? Typically, because you want all that public cloud goodness for your application, but regulations stipulate that you can’t upload certain sensitive data to the public cloud. If the private instance of your hybrid cloud is virtually identical to the public cloud environment, then that’s as close to “true hybrid“ as you’re going to get, where one cloud is an extension of the other.
The bottom line is that when we talk about the cloud, we’re really talking about the public cloud: Either SaaS applications (from the likes of Salesforce, Microsoft, Oracle, Slack, etc.) or IaaS/PaaS offerings from the big three and a handful of other players. SaaS is just a way of delivering applications. IaaS and PaaS, however, support a whole new application architecture for enterprise software development.
The cloud native edge
Quite a bit of public cloud spending goes to migration – a “lift and shift” of existing applications to AWS, Azure, or GCP, along with second-tier IaaS providers such as IBM or Oracle. In many cases, though, the benefits are minimal. Unless those applications and their business logic are in perfect shape, you’re merely duplicating the mistakes of the past on a public cloud platform.
Where things get interesting is when you build cloud native applications on public IaaS platforms (which today include PaaS, both native and third party). Cloud native applications are built from the ground up in modern style using services built into the IaaS platform. At a minimum this means the following:
Microservices architecture. Microservices – which are discrete, single-purpose mini-apps meant to be assembled together as applications – have become the de facto approach to building cloud-native applications. Typically, small, discrete dev teams maintain each microservice, built from the start with APIs to integrate with other microservices. As long as the APIs remain consistent, you can update (or scale) microservices one by one, as opposed to convening the entire dev team to refactor one big, monolithic application. And you can share or copy microservices to be reassembled into other applications.
Containers and Kubernetes. The whole Docker container revolution provided the ideal platform for microservices. Typically, it’s a one-to-one relationship: You deploy a microservice in a Docker container, which consumes a fraction of the resources of a virtual machine. But how do you orchestrate those microservices into an application? That’s where Kubernetes, now available on all major IaaS platforms, comes in. It automates the deployment, management, scaling, networking, and availability of container-based applications.
Microservices architecture also lends itself to CI/CD (continuous integration and continuous delivery), which provides a consistent way to package, test and deliver applications, and agile methodology, which encourages incremental code commits and rolling changes, plus continuous interaction with business stakeholders. Then there’s devops, which provides a model for automated software deployment and infrastructure configuration as well as testing and monitoring. All this cloud native stuff together provides a new paradigm for the way we build and maintain software.
Kubernetes, incidentally, also holds promise in creating a new class of hybrid cloud. Before, true hybrid clouds demanded parallel environments at the virtual machine level. It’s potentially much easier to enforce that consistency at the container level using Kubernetes, which enables you to move microservices-based applications between public and private clouds more or less seamlessly.
When you build cloud native applications on one of the big public cloud IaaS platforms, you get the added benefit of hundreds of API-accessible services to tap into, which may be the most exciting part of all. You have the option of tapping into machine learning libraries, IoT platforms, application monitoring solutions, big data analytics, blockchain services, and data integration solutions, to name just a few service flavors.
Perhaps most disruptive of all are the new distributed relational databases offered by AWS, Azure and GCP. These SQL-based cloud offerings not only allowing effortless relational database scale-up (a chore on prem) but also consistency among geographically distributed databases in public cloud datacenters around the world. It’s a key reason enterprises increasingly look to the cloud for building large scale applications (not to mention a threat to incumbent on-prem database solutions).
Finally, we have serverless computing (also known as functions as a service or FaaS) which takes PaaS to the next level. Every major cloud offers it, with AWS Lambda the acknowledged leader. Just as developers use microservices to assemble applications, devs can grab functions from a library to assemble microservices – and stitch together applications without having to consider virtual server infrastructure or even containers. Serverless applications offer potential cost savings as well, because they sit dormant until a request arrives, conserving cycles for which the public cloud provider would otherwise charge.
When you behold the breadth and depth of cloud services available, an obvious question arises: Why create and deploy applications anywhere else? There are still reasons having to do with data residency, operational costs, and so on. But today the latest and most exciting tech tends to appear in the cloud first, so the allure will only intensify.