Earlier we wrote that DevOps is the key to success in the public cloud and DevOps must be purpose-built for AWS, Microsoft Azure and Google Cloud.
We continue with implications for DevOps organizations and design principles DevOps systems in the public cloud.
Previously we pointed out key differences in public vs. private cloud - that the public cloud is API driven with new capabilities for DevOps tools to support and public cloud instances are fixed partitions vs. elastic slices.
How does this impact DevOps in the public cloud?
On-premises, DevOps is driven by CMDs and trouble tickets
In the diagram below, we depict a typical on-prem organizational stack on the left.
Developers write code and submit workflows using tools like Jenkins. Operations teams configure capacity with scripts of commands through tools like Chef. Infrastructure teams build out new, fixed capacity as VMs.
Trouble tickets are the unit of communication between teams. A new test farm can take days or weeks to go through the process.
Public cloud DevOps is based on code and APIs
Public cloud services are infinite, on-demand resources. Self-service dramatically increases developer productivity - all you need is a credit card.
Dev and Ops meld together because developers are now directly driving infrastructure with software (instead of trouble tickets). Operations must write code (instead of CMDs and scripts). Operators must now become developers – hence the difficulty in developing skills and hiring appropriate staff
Governance and auditability are still critical, but not at the expense of the speed and agility that comes with the public cloud. Without governance and control, ‘sticker shock’ results.
The key metric is no longer utilization, but cycle time and spending. Auto-scaling up and down is a key success factor in both cycle time and spending, but this requires software that directly drives cloud APIs.
So with all these issues, what does a DevOps system for the public cloud need?
DevOps systems in the public cloud should be Service driven (vs. command-driven)
A public cloud DevOps system directly drives the public cloud infrastructure APIs. Micro-services abstract the constantly evolving services, features, deployment and buying choices. DevOps is API and service driven instead of VM and command oriented.
This is only natural – the power of the public cloud is that it has always been ‘just an API’ – DevOps is following this progression by offering the process and the tools another layer of API abstraction.
This creates consistency, scale, and reduces maintenance as DevOps integrates workflows, resources, and cloud APIs together.
Use containers to drive high utilization in the public cloud
You must embrace containers to get high utilization out of DevOps in the public cloud. Companies like Google and Facebook have been using containers for a decade to get upwards of 80% utilization and cycle times that enable hundreds of releases per day. Why? Containers enable true auto-scale to efficiently use fixed capacity public cloud instances.
Containers and auto-scaling of resources help you avoid the ‘sticker shock’ that comes with a typical ‘lift and shift’ of on-prem VMs to the public cloud.
Enforce spending ‘guardrails”
Along with self-service comes over-consumption. At large public cloud shops, it’s not uncommon to see managers badgering developers to find and turn off unused instances.
We’ve written before that spending is an important metric in public cloud DevOps – not just for measuring overages but also for troubleshooting and security. Real-time information with policy controls is critical.
Ideally, DevOps software takes a systems approach, where the system itself provides negative feedback to bring spending in line with policy in a self-correcting manner. The system should give behavioral ‘nudges’ to developers as they consume capacity.
To summarize, a purpose built end-to-end DevOps system is a must for success in the public cloud. DevOps systems must be able to natively leverage the capabilities and consumption models of public cloud efficiently. It also must preserve self-service while providing governance, auditability, and security. Lastly, a DevOps system built for public cloud must be application and service-oriented rather than server and VM oriented.
Imagine a large-scale test simulating hundreds of thousands of users. A DevOps system should enable developers to directly drive this process with services that control public cloud APIs for underlying infrastructure, run the tests economically (say, leveraging spot instances), be smart enough to rerun only failed tests, and then tear down the capacity afterward.
Now, imagine what it takes to execute this use case, along with the economic and agility benefits of doing it well, several times a day, and you can appreciate why DevOps is the key to the public cloud and why a purpose built DevOps system that natively leverages public cloud capabilities is mandatory to success in public cloud.
