(c)iStock.com/4774344sean

Everyone knows that migrating workloads to the cloud is challenging. But many assume that after you get to the cloud, all you have to worry about is maintaining your applications.

After all, you have outsourced infrastructure management to AWS, right? No more racking and stacking servers, no more switches and hypervisors.

While AWS will maintain the physical infrastructure that supports your virtual environment, it is not initially set-up to help you configure those virtual instances and get them ready to run your code. And it remains your responsibility to maintain that architecture so that it evolves when your applications change.

This is a potentially dangerous misconception – and one that we run into often.

If you only do the bare minimum in cloud management, or leave it to your (new) DevOps teams or your systems engineers (who are already busy helping with future projects and migrations) to figure out, it often results in chaotic cloud environments. Every instance has a “custom” configuration, a developer launched an environment and forgot to spin it down, changes are made but not documented, and wasted resources accumulate. Suddenly you are not sure which resources belong to which project, and when your site goes down, your team is left combing through dozens of resources in the AWS console.

AWS is a world-class engine equipped with a robust set of tools, but it is not a car you can just drive off the lot. Even the best cloud systems require ongoing maintenance. And while moving to the cloud means you have “outsourced” racking and stacking servers, your IT team still needs to do things like configure networks, maintain permissions, lock down critical data, set up backups, create and maintain machine images, and dozens of other tasks AWS does not perform.

You may have heard of enterprises that now use a team of engineers to run their clouds. These enterprises realise that beyond the initial cloud migration, significant time and effort needs to be invested in automating configuration, auto scaling, and deployment. Automation allows these teams to spin up environments in seconds and repair failures without human effort. AWS provides the tools that make automation possible, but it is not configured on day one. That team of engineers may never touch the AWS console; they are maintaining automation scripts and modules, not the AWS resources themselves.

Over the last few years, the word “automation” has been used to describe many things. That is likely because every enterprise cloud environment will use different tools for different goals, and the end result will likely be partial automation – not every organisation needs to deploy 200 times a day or wants to become the next Netflix, after all. But the great thing about automation is that it is not an all-or-nothing proposition. Even a little effort yields immediate results.

The cloud does not work out of the box, nor does it maintain itself. But with the right team and the right skill set – in tools like Puppet, Jenkins, AWS CloudFormation – it can change your IT department forever.

The post The Cloud Does Not Just “Work” appeared first on Gathering Clouds.