Some Cloud Best Practices from iTMethods
“Life is a journey. When we stop, things don’t go right.” -Pope Francis
My recent post “Don’t Let Traditional Managed Services Providers Hold You Back” illustrated how shifts in technology paradigms have made it hard for some traditional managed services providers to keep pace. I feel very fortunate to have had several customers and partners reach out to share their experience on the topic, and today I’m delighted to post some best practices from Wendell Ying, SVP of iTMethods, one of AWS’ Advanced Consulting Partners. If you’ve got a story to share sharing what you’ve learned —particularly as it relates to some of the topics I’ve already posted — please reach out!
As public cloud adoption starts to accelerate among enterprise customers who are seeking to take advantage of the scale and innovation of the cloud, I get many questions from executives who would like to construct an AWS cloud roadmap. Each company is different, but there are some common themes that resonate across multiple industries In this blog post, I will outline some of the best practices and advise on how to get your organization moving in the right direction.
It is also useful to place these themes into the context of Stephen’s four “Stages of Adoption”, highlighting some key strategies that should be considered at each stage of your journey:
Stage 1: “Project”
Make your project(s) meaningful: A critical success factor at this stage is ensuring that the criteria for project selection includes some form of a compelling business event and “degree of difficulty” that when combined, will make the project(s) meaningful. If a project is not challenging, then there is no true learning benefit to your organization. A compelling event ensures that project teams feel that something is at stake and that they need to drive the outcomes for the business.
I strongly suggest that you discard softball projects, play hardball in the Cloud and confront some of your toughest application challenges first. Good candidates for your initial workloads include highly scaled web applications that have spiky usage patterns which is a situation that pushes your architects to consider Autoscaling. Another good choice is to select business workloads that can benefit from specialized EC2 instance types to increase performance or vertical scalability. Some applications can benefit from a tiered cloud storage platform that is both durable and scalable, allowing the business to get off the treadmill of buying ever-increasing amounts of expensive on premise disks.
A good example of this principle is the University of Alberta’s migration of their digital workloads to AWS to unify and simplify its digital strategy while maximizing scalability, security and reliability. This customer had to navigate a number of business / technical hurdles and a tight project deadline to make good on their commitments to the business.
Stage 2: “Foundation”
Invest in Automation: I recommend that at the heart of your Center of Excellence, you should create extensive and wide-ranging capabilities in automation and in particular, Infrastructure as Code (IaC). IaC tools come in many forms including CloudFormation, Terraform, Ansible, Chef and Puppet to name a few popular choices. You will find that developing your IaC code base is dependent on the tier — AWS services, OS / host or application tier — that matches the various tools and that combining tools together is a pragmatic and long-term strategy, as IaC tools and techniques are still rapidly evolving.
There is a common misconception that IaC only benefits customers who are undergoing a DevOps transformation. To the contrary, customers who intend to simply rehost or “lift-tinker-and-shift” their workloads can immediately benefit from IaC in a number of different ways:
· Increased Operational Efficiency / Agility. As enterprises migrate hundreds or thousands of workloads to the AWS cloud, operational change management becomes a critical factor in ensuring ongoing health and availability of your application portfolio. Iac gives you a rigorous, auditable and reversible means of making AWS-related changes at scale. It also allows you to be more responsive to unexpected business events like a cyber-attack, where you quickly purge and quarantine the affected system(s) for subsequent security forensics and then rapidly resume business operations using a clean backup of the affected application stack.
For an AWS customer like UGroupMedia Inc., CloudFormation represented a way of efficiently implementing and managing a customized Autoscaling policy to handle their seasonal load and automating code deployment process using CodeDeploy.
· Security automation.
“The Gartner research firm estimates that worldwide spending on cybersecurity is approaching $70 billion per year (Giles, 2014) and is growing at roughly 10 to 15 percent annually with no deceleration in sight. Despite this, it would be an understatement to say that organizations are dissatisfied with existing cybersecurity — and there is scant confidence among defenders that their exertions will give them the upper hand against malicious hackers two to five years out. Many believe that hackers are gaining on defenders. This combination of rising expenditures and questionable success creates a sense that security efforts cannot continue on this course” — The Defender’s Dilemma: Martin C. Libicki, Lillian Ablon, Tim Webb RAND Corporation.
Security remains a prime consideration in the cloud. So what to do about those rising cybersecurity costs? Well, use automation! According to the AWS Well-Architected framework, the use of detective controls is embedded in AWS’ best practices for identifying a potential security incident. IaC combined with Security Operations — commonly called DevSecOps — can help all customers have better asset inventories with detailed attributes to establish operational baselines or promote better auditing using automated alerting mechanisms based on pre-defined conditions. DevSecOps = lower cybersecurity costs + increased capability to detect anomalies.
AWS customers using the Elasity product benefit from a common DevSecOps approach to centralize logging and security incident detection, as the product development process focused on security automation as a foundational element.
Stage 3: “Migration”
Adopt a factory approach. Assuming that you have decided to invest in Automation — a foundational building block in your cloud journey — then you are well prepared to adopt a factory approach for your workload migration. Mechanizing migration projects using a factory approach is enabled by automation. Creating the base level AWS services — VPCs, centralized services like logging / audit, backup & recovery, authentication services or thin client infrastructure — can all be created and managed using IaC.
The baseline for the Migration Factory is then combined with the migration approaches for the different categories of workloads including the various migration tools that will replicate your data and applications. In many cases, it makes sense to understand how to manually migrate a certain type of workload, and then automate the process using your specific portfolio of migration tools — CloudEndure or AWS Server Migration Service — to create a repeatable and agile process for your migration factory.
Stage 4: “Reinvention”
Exploit advanced AWS platform services. AWS platform services offer a democratic way of supercharging your application portfolio by giving you access to AWS innovation. For example, AWS cloud-native machine learning and deep learning technologies offer enterprises new opportunities to quickly create predictive applications and products. Perhaps you want to completely re-architect and re-write an application using Lambda and DevOps / Agile team culture, lowering your time to value. You can now focus on the business mandate of having technology work for you, rather than you working for the technology.