(c)iStock.com/baluzek

IaaS adoption usually begins in isolated pockets — one project here, one there. Then a few months (or years) later, IT decides to expand AWS usage and realises that they don’t know the status of current AWS projects; they don’t know if they ‘did it right’ when they built the first couple of projects; and they don’t know what it looks like to ‘do it right’ in AWS in general.

This last point is the crux of the issue, and the #1 reason we see AWS migration projects stall is not because of a lack of talent or even lack of planning, it is simply that there is no clear vision for what a “good” AWS environment looks like for their specific complex workloads. There is no common yardstick for assessing current environments and no template for building new ones — and this uncertainty is the true root cause of downstream security or performance concerns.

What is a good AWS environment?

Several security organisations have developed a set of common standards for the cloud. AWS themselves have developed extensive documentation and even a service, AWS Trusted Advisor, to help you implement best practices.

But what IT teams really need is a single, simple set of guidelines that mees both internal and external standards — and they need those guidelines to cover everything from server configurations to monitoring and management.

This is where IT meets its first obstacle: they must develop a common baseline for security, availability, and auditability that everyone agrees to. They need to develop “minimum viable cloud configurations”. For instance: MFA on root, everything in a VPC, CloudTrail enabled everywhere.

Example of Logicworks 89-Point Assessment, part of our Cloud Migration Service

The effort to create a single set of standards may seem like a direct push-back against the self-service IT approach, where product teams use whichever technologies they need to get the job done. However, as we will discuss below, developing these common standards is actually the bedrock of a safe self-service IT approach.

Moving from standards to live systems

It is one thing to develop standards, and another to implement those standards on new and existing AWS projects. And then another effort entirely to enforce those standards on an ongoing basis.

In the old world, enforcing configuration was largely manual. IT could afford to manually update and maintain systems that changed very rarely. In the cloud, when your resources change every day and many developers and engineers can touch the environment, a manual approach is not an option.

The key is that these standards need to be built into templates and enforced with configuration management. In other words, build a standard “template” for what your security configurations should look like, and then maintain that template rather than creating a hundred custom configurations for each new cloud project. The template gets changed, not individual virtual instances or networks.

Logicworks build process

For central IT teams, this is revolutionary. Rather than spending months testing and reviewing each new cloud environment, the security team spends time upfront collaborating with systems teams to build a common standard, and then only needs to be involved when that standard changes and at other key points. You know exactly how every system is configured for security at any point in time, and you reduce the time and cost of deploying future systems; you do not have to rebuild security configurations or get them approved by security teams.

What to do now

If you are planning for an AWS migration, the #1 thing you should do right now is implement configuration management (CM) in your current systems. As outlined above, implementing CM means you have to a) come up with the right standards and b) “code” them into a centralised place. This is the hard part. Once you do this, migrating to AWS is much easier because you know what “good” looks like.

The main question is whether or not enterprises will have the time to set up these processes as they migrate to the public cloud. CM requires training, a team of advanced DevOps engineers and Puppet/Chef experts, and months of work. By far the easiest way to do this is to hire a consulting company that already has a common set of standards and a well-developed CM framework, who can assess your current AWS deployments and/or build a solid foundation for future deployments based on those standards.

IT leaders struggle with cloud migration when they do not have expertise in defining and maintaining ideal state. When you migrate to the cloud, any weakness in this area quickly becomes a major handicap. Configuration management can set you on a faster and more stable road to success.

The post The #1 Reason IT Struggles with Cloud Migration appeared first on Logicworks Gathering Clouds.