Private Clouds Demand a Different Mindset

The cloud changes nothing. The cloud changes everything. The private cloud does neither and both.

OK, enough with the Zen. The truth is, your applications running in a private cloud, of whatever flavor, still need the critical application delivery services that the network has traditionally provided: security, load balancing, high availability, and optimization. Even newer architectures such as microservices and container platforms use familiar methods to keep applications up and running. The latest languages or development techniques should still be backed up with security tools like access control and web application firewalls. In this way, nothing changes.

So, what does?

For most organizations, the private cloud changes not what we deploy, but how, and, more importantly, how fast we can deploy it. Successful private cloud implementations will deliver self-service IT and allow internal customers to use automation and infrastructure-as-code to create highly dynamic, operationally efficient application environments. The frequency of changes to the code and the infrastructure will accelerate as new services or applications are developed and delivered more efficiently. While many of the factors driving faster ‘time-to-value’ are cultural and organizational, the infrastructure must not be a road block. From request to implementation, there is no time for human latency. Automation tools will have control the bulk of IT service delivery if the infrastructure is not going to be a bottleneck.  

If you are moving from a ticket-based, traditional organization where changes are requested, reviewed and implemented manually, then this transition will change a lot of your day to day activities. IT will have move from being implementation-focused, to designing frameworks and end-to-end service automation. Thinking about how to allow application developers or application operations (dare I say ‘DevOps’?) to provision network and application delivery services in the same manner as the rest of the stack needs to central to deploying a private cloud platform. Stealing a phrase from a colleague: IT operations must move from being button pushers to button creators.

At a philosophical level (and, after all, that’s where this article started) what fundamentally changes is how IT operations controls the infrastructure. Think about it: the reason there was a ticket system and an operations team to make changes to the infrastructure was partially to prevent errors or misconfigurations by only having domain-experts make changes. IT operations had access to all the buttons and knew which ones to press to effect the requested change, and hopefully not break anything else in the process. Now everyone wants to press their own buttons, or have software do it for them. The logical buttons that operations create had better be safe to press. This is now where operations exert control. By creating templated, automated systems that only require the requesters to know what they want, not how to do it, and limiting their choices to secure and supportable configurations, IT grants freedom to their customers but keeps control of the infrastructure.

While these changes might be challenging technically and culturally, the resulting productivity and agility gains are significant enough to warrant the challenges in getting there.