Sep 14, 2020 New Rules for Cloud First World
With the balance of enterprise IT shifted to cloud now (remember, the majority of enterprise IT workloads now run in an external cloud environment) IT teams need to really embrace cloud-first thinking. They won’t be able to build a real blueprint for the next few years if they fail in this.
Most IT operations and security teams entered professional life in an environment of dedicated physical machines or virtual machines as the basic unit of work in a data center. One system, one workload, generally, even though there were some applications that ran in clusters. Such systems were persistent and relatively stationary: once installed or instantiated, they stayed put for a long time, usually years. (Yes, VMs could and sometimes did move, but most didn’t and those that did usually did not go far or for very long.) Systems were provisioned individually by system admins. When more power was required for an application, it was put on a beefier box–that is, systems most often scaled vertically.
Shifting to a cloud first world means shifting to a cloud-first design approach, and that approach that undercuts the kind of unconscious assumptions and biases that can follow from such a start. And so, new rules have to be internalized.
Basically, all of that is changing, and rapidly. You can and do find folks trying to carry the old ways into cloud–the good ole lift and shift lives!–but it’s not a long term strategy, just a stop gap. They have to adapt as new waves of applications, services, and development approaches leave this all in the dust.
Services, Not Systems
First, enterprise systems will be delivered by swarms of cooperating entities, not by a single virtual or physical system. Whether they are fleets of stripped down VMs running components, or flocks of containers, or a mix of these plus dedicated physical systems and/or code nodules running in someone else’s serverless offering, the point is, the service delivered will be decisively different from the infrastructural underpinnings — no one-to-one correspondence.
Ephemeral, Not Persistent
Just as there won’t be a single system behind the service, there also won’t be any one part that persists over long periods. Components will be spun up at need and shut down when the need passes, or if they linger, shut down and replaced rather than updated or upgraded. Patching a running system gives way to replacement of the unpatched instance with a patched instance, for example. This has implications not just for how admins think about the service but for the systems they use to log, monitor, and secure those services behind the scenes.
Not Stationary (But Not Moving)
That ephemerality brings with it a transience of place as well as in time. Services can be moved from environment to environment more easily and rapidly than ever before through a sort of pseudo-motion in the systems supplying the service. But rather than being a case of a container literally moving from one place to another (say, from your DC to AWS or GCP) as you shift service delivery from one place to another, you see that, again, old systems are spun down in the old location and replaced by new systems spun up in the same roles and relationships in the new one. The service moves, but none of the systems underlying it do.
Deployed By Code
Of necessity, when IT deals in services comprising tens or hundreds of component systems, each with a life measured in seconds or minutes, not months or years, humans can’t be doing the provisioning. So, the vast majority of systems in the cloud-first infrastructure are deployed by code. It may be pushed at the end of a CI/CD pipeline, or may be spun up by orchestration software in a cloud service broker or cloud management platform, but it will be infrastructure as code, deployed by code.
Scale Out not Up
Microservices feature large (ha!) in most cloud-native approaches: factoring an application into large numbers of small functional units. Key to the approach is scaling out to meet demand, not up: by adding instances of the service rather than by assigning more resources to one instance. About 40% of organizations have begun to design around microservices and more than 55% of organizations use containers (the natural vehicle for most microservices).
Really harnessing cloud requires changing not just design and technology, of course, but also teams, jobs, and processes — but first, it requires changing how IT thinks about everything it does.