If you’re managing an IT infrastructure automation project, are you considering the scope of the project and aspirational business results?
This question may seem obvious, but I’ve seen sufficient projects diverted to make it a legitimate one.
It’s been my experience that the label of Private Cloud has set an unreliable expectation for both clients and IT. There’s a thought that a private cloud should relate a public cloud in form and features.
But IT companies automatically risk scope creep when comparing their project goals to that of public cloud characteristics.
Ten Years for Ten Years of Experience
I once had a manager give me some excellent early-career tips. It went like: it needs ten years to get ten years of experience.
The tip may seem simple, but it applies well to IT infrastructure automation efforts. Before even getting to the example of AWS it’s helpful to look at a massive AWS customer, Netflix.
IT Infrastructure Automation Case Study – Netflix
As a customer of AWS Cloud, it took Netflix seven years to migrate the majority of its streaming services to AWS. And this is because cloud migration isn’t as simple as taking existing workloads and performing a physical-to-virtual (P2V) migration.
Netflix recognized processes and applications need refactoring to run in Cloud infrastructure. The main lesson for companies is that introducing automation-as-a-service to customers isn’t enough.
IT infrastructure requires working with the application team to understand how IT infrastructure automation integrates into being workflows.
One of the basic use cases for IT infrastructure automation is the increase in application development workflows. Managed IT service teams want to ask the fundamental question of what’s the existing workflow and do the automation solution to change that workflow.
The Flipside of IT Infrastructure Automation
The other half of that comparison is the infrastructure automation scope. It’s tempting to look at all the integration of an AWS EC2 and want to follow the service. I’m going to go ahead and say, if the goal is to build AWS internally, you should look to migrating to AWS.
You’ll have a larger likelihood of resolution removing the roadblocks to public cloud vs. recreating AWS. It used the AWS team ten years of center on delivering Infrastructure-as-a-Service. AWS created its infrastructure and methods with implementing IaaS in memory. Most companies still require dealing with installing and supporting packaged and legacy software.
IT infrastructure automation isn’t a clown’s errand. It’s the inverse. It means that infrastructure teams require concentrating on areas of value.
If the challenge is getting products or applications to market as quickly as possible, the solution may lay in automating the development and test method. Infrastructure teams can focus on the difficulties related to provisioning resources and regression testing of code as it flows through the development cycle. Provisioning development resources is a pattern of something that offers a meaningful return vs. automating the provisioning of an email server.
Focus on Results
A point of automation is to remove productivity bottlenecks. The aim isn’t to replicate the public cloud which concentrates on solving a broader range of difficulties over a broad consumer base.
When beginning an automation project ensure you are targeting and approaching the appropriate company aim.