January 8, 2018

Principle One: Be Well-Architected.

As AWS recently tipped the scales at 47.1% of total cloud market share, an increasing number of businesses are looking to move their IT operations to the AWS platform. At the most recent annual re:Invent conference, the company expanded their platform substantially, announcing several dozen new products and features available to customers.

As a certified AWS Solutions Architect working on the platform since 2009, I often get asked something like ‘what does a prescriptive roadmap to success look like on AWS?’ It’s a tough question to address given all the shapes and sizes of businesses, and the moving target that is AWS. While there is no one-size-fits-all-color-by-numbers recipe, thinking about it more there certainly are cogent sets of Guiding Principles that IT teams can use to maximize their success on AWS. Following a set of principles like these will provide a decision-making framework for teams to define their own prescriptive steps to success to AWS, and ensure they get every last ounce of benefit from the platform. Before we dive into my best attempt at Four Guiding Principles for success on AWS, let’s take just a moment to allow some very non-AWS wisdom to inform and influence our AWS journey:

‘Give me six hours to chop down a tree and I will spend the first four sharpening the axe.’ ~Abraham Lincoln
‘If you can’t explain it simply, you don’t understand it well enough.’ ~Albert Einstein
‘Make it nice, or make it twice.’ ~Richard Blondin, Executive Chef at The Refectory*

While not part of The Four Guiding Principles per se, these quotes serve to help us get our mind right in the early stages of a successful AWS project. Cultural alignment around The Four Guiding Principles is key to your organization’s success. So, slow down to speed up, invest a few days or even weeks with your team to dive into the subtext of each of these principles, and others you may discover for yourself along the way. Meet with your team and discuss these principles, hack them into shape and make them your own, until you have cultural alignment around the collective approach.

AWS has grown into a deep forest of capabilities, so spend some time sharpening your axes a bit before getting to work in the forest. When you can simply and intuitively re-explain these principles back to yourself and among your team, then let the dirt fly in anger on you implementation. Doing so will empower your team to make it nice, while starting without this cultural alignment will almost certainly guarantee you will make it twice!

Ok, so now that we have sharpened our axes, and have established our cultural alignment around engineering excellence on AWS, let’s get to the first of my personal Four Guiding Principles to Success on AWS!


Guiding Principle One: Be Well Architected.

The AWS Well-Architected Framework, or the WAF as it is called, is a collection of only 6 documents. Each is only about 20–30 pages in length, free of jargon or lengthy prose, and quite easy to digest in a single sitting. Have everyone on your team download all 6 documents, grab a cup of coffee, and spend an hour or so on their own becoming intuitively familiar with the WAF. Then, meet as a team and discuss and review the WAF until everyone ‘understands it well enough to explain it simply.’ Here is the WAF:


Try to adopt the WAF at face value, and do your best to avoid cherry-picking around the hard ones. Example: nearly every enterprise AWS project I’ve ever worked on begins with ‘how much of this AWS capacity do we think we will need?’, usually in an effort to budget and estimate costs. Yet, the WAF specifically tells us, twice actually, to ‘stop guessing capacity.’ This is because the WAF has been produced with the wisdom of hindsight learned through hosting over a million customers, one of which (Netflix) is responsible for 37% of Internet traffic in North America. They tell us to ‘stop guessing capacity’ because they’ve learned from that experience, that we are asking the wrong question: “How much will my apples cost when I turn them into oranges?” A scalable, dynamically provisioned and fully automated AWS environment looks (and costs) nothing like a statically provisioned vm based legacy premise environment. AWS knows this for us. They put it in the WAF for this reason. Don’t cherry pick, just do it. The WAF is your note to yourself, from your future self. The stuff that doesn’t make sense initially is the stuff that will transform you and your team, if you embrace it.


Also, don’t feel the need to become a WAF experts or endeavor to address every WAF requirement on the first steps of your AWS journey. We will talk more about how to smartly scale into full WAF compliance, over time, in Principle Four: MVP to Cloud Maturity Model.


Bonus sub principles: while in WAF-ville, be sure to spend some time absorbing the AWS Reference Architectures resources. You’re not in Kansas anymore! Also, check out some other guiding frameworks like 12 Factor, and consider what you can learn from those.


That’s it for the First Guiding Principle. I look forward to sharing more in subsequent posts. Here are the remaining three principles, so you know what to expect:

  • Guiding Principle Two: Build with AWS Components First
  • Guiding Principle Three: Automate Everything
  • Guiding Principle Four: MVP to Cloud Maturity Model


* Regarding the obscure quote from Richard Blondin: prior to IT, almost 20 years ago…my life was one of a cook. After Culinary School in the U.K., and staging at pretty much every brutal Michelin starred establishment in London for a year, I thought I was a pretty good cook. My last 2 years in the industry was spent under Richard Blondin of The Refectory. Richard, in his own quiet and unassuming manner, helped me realize how little I really knew, how much there was to know, and what greatness in the kitchen really looked like. ‘Make it nice, or make it twice.’ was a one of the many lessons we all took away from our time under Richard, whose skill was matched only by his humility. From the Kitchens, to the Cloud!