So, you still have on-premise servers, and you want to move to the cloud. Or perhaps, you have moved to the cloud, but you have kept your server-centric mindset, and used Infrastructure-as-a-Service (IaaS) to build your servers in the cloud, directly mimicking what you had on premises.
You are doing in incorrectly, and you are not helping your organization as much as you think. Sure, there might be a modicum of cost-savings related to moving to the cloud. However, maintaining a server-centric mindset, while consuming cloud resources is an anti-pattern.
Server Centricity
How do you know if you are still trapped in server-centricity? Let's take a short quiz:
Question #1: Do you name your servers?
Question #2: When clients must integrate to your applications, do they need to know the name of your servers, or worse yet, their IP addresses?
Question #3: Do you even have cloud resources that you label as "servers"?
Question #4: When the servers fail, how do you respond? Do you manually build a new server and manually reconnect clients? Even if you have a hot/warm/cold standby server, was it built with at least some manual intervention?
Question #5: When you need additional capacity, do you manually scale horizontally, or vertically?
If you answered yes to any of these questions, your cloud usage is still immature. How immature is relative, and a matter of opinion, but most would agree that manual intervention should be minimal, and a last resort.
Abandon Your Servers
To use the cloud effectively and move towards maturity, your organization must lessen, and eventually remove, the importance of individual servers. Servers are fleeting; applications are more important. In the realm of IaaS, instances and/or containers replace servers. Instances, and even more so, containers, are designed to be volatile. In fact, with proper automation in place, instances and containers come and go with little or no impact to applications. Applications stick around, underpinned by instances, containers, and automation. Availability and partition tolerance are easily achieved with proper automation and design.
Platform-as-a-Service (PaaS), underpinned by IaaS, is even more application centric, and relies on automation even more so than IaaS. In a properly designed PaaS implementation, automation allows the end users, the application owners, to place their applications into the cloud without having to build the instances and/or containers. PaaS users either supply the deployment artifacts, or use PaaS Ci/CD services to build and deploy the artifacts. In fact, for PaaS subscribers, the term "environment" takes on new meaning; it is the intersection of code and logical application definition, controlled by CI/CD processes and automation. They don't care where their applications run, just as long as they run and their users can successfully use them to complete their respective tasks.
Automation and Indirection
Automation is in place to abstract the need for PaaS users to build and maintain IaaS resources. There is also a layer of indirection that exists between the applications and the underlying infrastructure. With PaaS, application owners never need to worry about that underlying infrastructure; instead, they focus on code and application definitions. Overtime, this places them in the same category with application users, or even SaaS subscribers.
This PaaS-like abstraction and layer of indirection should also be the goal of cloud-enablement teams that are using IaaS resources to deliver services to application teams. With automation, and well-defined practices, and well-designed stacks, cloud-enablement teams are now able to deliver more self-service resources with IaaS. This self-service allows development and deployment teams to consume IaaS similarly to PaaS users. With proper automation, there is little to no manual configuration or intervention needed by the application teams.
Where are the Servers?
And, where are the servers? They are forgotten, replaced by instances, containers, and stacks, whose count shrinks and grows with the needs of the individual teams consuming them. Configuration-as-code and automation, for resource formation and autoscaling have reduced the need for manual intervention.
So, if you really want to enter the cloud and be successful, be prepared to abandon your servers.
