In our last two posts, we discussed how the public cloud differs from the private cloud in ways that will impact your approach to managing infrastructure and implementing DevOps.
First, we discussed how the public cloud is API-driven vs. server driven. Then we discussed the impact of how you prioritize workloads based on how public cloud instances behave differently from on-prem VMs.
This time, we bring up another big difference between the public and private cloud – in the on-prem world you manage infrastructure and organizational structure in silos, but in the public cloud, you drive infrastructure with code.
That is, in the on-prem or private cloud world, there are usually three different teams, each which drive different processes in three different ‘layers.’ Specifically:
- Development teams write code and test the apps
- Operational teams deploy and monitor the apps
- Infrastructure teams provision servers, networking, and storage to host the apps
Fundamentally, in the on-prem world, you are are dealing with a fixed set of resources, and the teams are coordinating the provisioning and allocation of these fixed resources via trouble tickets.
If you need a resource, you ask the next layer, and they may or may not have the needed sources on hand. If they don’t have it, they have to reprioritize other projects or procure and provision new resources.
This means that if development needs 100 VMs to do a large-scale test, it could be a month or more before they get what they need.
Now, this structure does provide a lot of value. For example, this makes it possible to impose certain governance policies very reliably. Each group becomes an expert in enforcing its own part of the overall policy.
On the downside, however, it does promote bureaucracy and has a big negative effect on agility.
In contrast, you drive the public cloud with code
The public cloud is completely driven by APIs. Using these, you can quickly scale up to effectively infinite on-demand resources.
So the focus is how can I get my job done as quickly as possible, rather than how do I do get the resources to do my job.
Instead of driving your infrastructure with trouble tickets, you are now driving the public cloud with code.
Driving your public cloud with code and software makes you much more agile!
Driving your public cloud with code also gives you much better utilization with capabilities like self-service and auto-scaling. Throw in the ability to buy the right kind of resources for your job, such as spot instances (80% discount) and that is the icing on the cake!
Whereas in the private cloud you spend a lot of your time managing resource constraints, in the public cloud you are focussed on optimizing time constraints. How do I get this work done as fast as possible, given essentially unlimited computing resources?
Now that you are time-constrained, you ask if the job is worth the time and the cost of running it.
This gets to the core of the change in thinking from private to public cloud.
So much in private cloud is about the allocation of resources, managing queues, who gets access, identifying bottlenecks, etc.
But once you go to the public cloud, you have as many resources as you need on demand, so if you are operating properly, you don’t have to wait for resources. No more queues!
And with self-service, you don’t have to wait for other people either.
All the thinking becomes focused on how do I ship my product the fastest.
But it's not entirely that simple. If you are going to operate in the public cloud, the key to success is embracing DevOps to enable self-service and the optimization of time constraints.
More on that next time, or see our recorded webinar “AWS is different! How can containers help?” below or on our cloud best practices YouTube channel.
