Your organization has decided: It’s time to migrate to the cloud. You believe you’re ready – with the right combination of staff, partners, vendors, and technology to move. The various teams have identified what is moving, when, and what should be sunsetted. Your budgets are approved, and you have obtained volume discounting from your cloud provider. Now…what’s the first step?
Making the move
Good news. Since 2006, AWS (and now the other cloud providers) have been conducting this exact scenario. Not every company is born-in-the-cloud, and many organizations before you have had to adopt the cloud. Even better news, they’ve developed a few free frameworks (“how to manuals”) on what to do! Enter The Shared Responsibility Model and The AWS Well-Architected Framework.
The Shared Responsibility Model: A guide to understanding what you need to do and what they provide you. In essence, when you built your data center, you were responsible for everything – all layers of the OSI model. Now you are using someone else’s data center, so you aren’t responsible for the layers 1-4 anymore. You are still responsible for 4-7 though, so get a good understanding of what needs done here. This is where the next framework comes into play…
The AWS Well-Architected Framework: Five pillars for which you are to build your architecture upon. The guidelines, explained in detail, of what you need to do and how to do it. Today I’ll highlight them and explain the best plan for adoption, services wise, via the AWS Well-Architected Framework (Microsoft also has a framework using the exact same name – effectively creating common terminology among cloud providers).
Below I’ll break down each pillar and provide you with a few key points to take away. This is by no means exhaustive, and includes directions straight from AWS at times, peppered with some of my own best practices.
How do your developers communicate?
Is there a method you prefer them to use?
Here’s where you build in the process standard, so everyone is on the same page and you’ve got no shadow IT operations happening, this is also where your culture and processes fit. Having set metrics, how to achieve those metrics, and fostering the environment for that to happen contributes greatly to achieving excellence.
Part of ensuring that everyone is on the same page is making sure to organize your environment and watching how it runs, evolving it to tweak for performance and cost, and preparing for expansion or modifications based on the upcoming business needs. All of this should sound familiar because these are things you used to during your datacenter days. At the end of the day, the focus of the Operational Excellence pillar is to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value.
Every organization wants to save cost and increase profit. Moving to the cloud is meant, in part, to be less expensive. Without a clear understanding though, things can rack up quickly. Time and time again enterprises fail to properly understand the cloud. I’ve seen projects which were spun up and abandoned, completely forgotten about for months, until our teams have asked “what’s this instance and why is it idle?”
With the adoption of cloud, technology teams innovate faster due to shortened approval, procurement, and infrastructure deployment cycles. To realize business value and financial success, a new approach to financial management in the cloud is required. This approach is Cloud Financial Management and builds capability across your organization by implementing organizational wide knowledge building, programs, resources, and processes. This is all about running your business systems at your most cost-effective price point.
- Are you using the right instances of your workloads?
- Could you be saving money by reducing your infrastructure?
I’ve seen instances of people halving their presence during non-peak hours and simply spinning them back up during high demand. Imagine being able to shut off and stop paying for your licenses and servers every night – day after day, year after year… it adds up to big cost savings! Optimizing this over time will be crucial to your long-term savings as well.
How much up time does your business require? If you’re aiming for five-nine’s (99.999%), you’re going to need to do some architecting. Another question to ask yourself: how much will the need for such reliability impact the other parts of your architecture? It’s important to take time to understand your business needs before you start building. It’s not uncommon to have to start over or even blow up an environment due to misconfigured understanding of up time.
A reliable workload starts with upfront design decisions for both software and infrastructure. Your architecture choices will impact your workload behavior across all five AWS Well-Architected pillars. Failure management and Change Control are still things important to your planning. You’ll have your change reviews and approvals, but you simply will be using the cloud provider’s services to make the changes in the various systems. Disaster recovery and backups (as well as the subsequent testing) fall under this category as well, so be certain to operate with these in mind. Remember, AWS is helping you by taking care of the basics, you’re responsible for your business, akin to the way you’ve been operating pre-cloud.
Like tuning an engine – your company will want to get the most out of the environment you’ve built. Gone are the days where you must order a system and beef it up for future use or possible issues, now you can configure your system for exactly what it needs to be, and then expand it on the fly! I personally used to be part of the procurement process at a large financial services firm. I’d spec out systems from HP and Dell and intentionally add resources to “future proof” them for different teams I’d install VMs for. Now this practice is moot – spin up and spin down what you need, when you need it!
Finding the optional solution for your workloads and what works (as well as tradeoffs on what won’t – enabling route 53 may mean extra work for your networking solutions). After you implement your workloads, this means you must monitor it continually to ensure you can remediate any issues before impacting your customers. This requires continual evaluation though – constantly changing services and updated technology mandates you are on top of the efficiency of your infrastructure.
And you can be – no need to order a new switch or router, no need to modify your cabling or protocols – it’s all done for you – simply configure and implement it correctly. Lastly, when you architect solutions, think about tradeoffs to ensure an optimal approach. Depending on your situation, you could trade consistency, durability, and space for time or latency, to deliver higher performance.
The Security pillar includes the ability to protect data, systems, and assets to take advantage of cloud technologies to improve your security. It also provides an overview of design principles, best practices, and questions to ask yourself. When building for security, you should implement a strong identity foundation, enable traceability, and apply security everywhere – at all services and levels of the environment. Also, be sure to protect your data and keep people away from it.
These sound like simple and effective rules, right? I think so too, but sometimes these rules are hard for organizations to build correctly. Don’t forget, incident response, identity and access, secure operations, as well as network and data protection all live here too and are also critical to get right.
Succeeding with your move
Combined, layered, continual, and monitored – the five pillars setup your organization for success in your first migration to the cloud.
Building this solid foundation will keep your organization operating well, and your customers and business happy. I know that there is quite a lot to learn here, but take some time and study the various pillars – and disseminate them to your entire team. Once you all have an understanding, dive into the planning and build phase for your cloud project. I promise you will be glad you took the time to get a solid foundation. Once you’re ready, turn on and “test” your environment with the AWS-Well Architected Tool.
Got any stories you’d like to share, good or bad, about your transition to the cloud? Experiences building with the AWS Well-Architected Framework in mind? Comment below and let’s hear it!