Going into Amazon Web Services (AWS) architecture training last week, I expected to get whiteboard-level training for project planners, and it met expectations.  We spent time talking about how Amazon’s most popular services fit together and how they can be used to solve our business needs.  Nothing in the training itself was groundbreaking for me – I keep up with the AWS blog enough to know what’s going on – and I think I actually learned more about the state of consulting than I did about the cloud.  Here’s the highlights:

Most attendees were consultants trying to get their heads into the cloud.  They weren’t hands-on implementers – they just wanted to be able to point their customers to the right services.  Their heads were swimming with all kinds of crazy (no, really) ways to use cloud services to solve client pain points, like connecting Amazon-based storage to on-premise servers over Fiber Channel over Ethernet.  (Jeremiah’s retort made me laugh out loud in the middle of training: “HELLOOOOOOOOOOOOOOOOO IIIIIIIIIIIIIII AMMMMMMMMMMM LATENCYYYYYYYYYYYYYYYYYYYYYYYYYY”)

The rest were implementers tasked with moving their company’s operations into the cloud.  They had already built successful technology companies using on-premise hardware, and now they wanted to migrate out of the expensive server-and-space problems.  They wanted to know the best practices on how to make this transition.

DevOps is going to be the story of 2013.  In the cloud, you use scripts to monitor load and adjust your infrastructure automatically.  Put another way, your code makes continuous decisions about how much your monthly bill will be.  The smartest coders will use a combination of on-demand instances, reserved instances, and the new black market.  This blew away all of the attendees, and they asked a lot of questions like, “Who’s responsible for this – development or admins?”  It’s neither – welcome to the world of DevOps.  I was pretty surprised that even Amazon’s trainers didn’t bring up this concept, because it’s fundamental now.  To learn about DevOps, check out What Is DevOps?, then Dmitriy Samovskiy’s excellent primer from way back in 2010 (he’s @Somic), then Mike Loukide’s historical perspective.

Cloud service sprawl is going to make SQL Server sprawl look like nothin’.  Amazon’s architecture best practices actively encourage people to think of technology as a bunch of loosely coupled black boxes.  Sure, that works today to build a very scalable infrastructure quickly, but think about how it’ll look 5-10 years from now.  If you’re a CIO and you get a big bill for thousands of instances of hundreds of services, how do you even begin to identify where to cut costs?  Be careful what you ask for – I’d be terrified to inherit a bunch of uninstrumented black boxes.

It’s really hard to train people on cloud services.  Cloud services change everything: storage, networking, app/database interplay, caching, replication, you name it.  To get the most value out of cloud architecture training, you have to come armed with a really solid understanding of networking, hardware, server virtualization, service-oriented architecture, and more.  During the sessions, if any one attendee wasn’t familiar with any one term, we had to go off on a 5-15 minute tangent.  That was pretty frustrating for those of us who came prepared.

Everybody’s struggling to keep their skills up.  Technical services are changing faster than ever, and Amazon’s own trainers often had to stop and ask each other because things had changed since the training material was last updated.  (Example: “Wait – the prices on this slide are wrong – they’ve dropped.”)

Developers who know the cloud can run rings around everybody who doesn’t.  The most junior programmer in the room with some background in Amazon Web Services was far, far, far more capable of making business-changing improvements than the most savvy (but hands-off) consultant.  One guy actually said, “I wish there was some kind of drag-and-drop Visio-style tool to just link these services together to build stuff.”  Bad news: GUI tools can’t keep pace with the rapid changes in cloud services, and the guy who can code the cloud wins.

Thinking About Attending the AWS Architecture Training?

I’d recommend that you spend a few days working with the online services first.  Consider doing the following tasks:

• Set up a Windows virtual machine in EC2
• Assign it a publicly accessible Elastic IP address
• Configure security so that you can remote desktop to it
• Add an EBS volume and hook it up to your Windows server
• Create an S3 volume, upload some files to it, and download them via a web browser

Those simple infrastructure experiments will get you familiar with the basics of configuring the most common Amazon Web Services capabilities.  Many of the other services build atop EC2, EBS, and S3, so this ground knowledge will help you get the most out of the architecture training.

Next, read the most recent month or two of posts from the Amazon Web Services blog.  When you don’t understand a term, spend a few minutes Googling it.  When you feel comfortable digesting posts like Amazon EC2 Reserved Instance Marketplace and AWS Cost Allocation for Customer Bills, good news! You’re not just ready for AWS training – you’ve actually given it to yourself for free.

I’m not quite sure I can recommend the existing AWS architecture training that I took – it was a rough mix of out-of-order content and basic-level questions from attendees.  I think the training would be much more valuable if you attend in a very high-tech area like Silicon Valley or Amazon’s home base in Seattle.  There, you might meet more hands-on implementers and have more valuable real-life experiences to share.  (For example, in Dallas, I was the only attendee who could answer questions about how to help clients choose between on-demand and reserved instances.)  I’ve discussed my experience with the Amazon training team, and they were already making changes to reorganize the content and raise the bar on testing attendees to make sure they’re qualified for the course.

The Biggest Thing I Learned

Even when you don’t learn much from a class’s training material, that teaches you something: you know more than you thought you knew.

I wasn’t all that upset that the material wasn’t new to me.  This just means I need to step up my blogging game here – we’ve gotta do a better job of sharing the things we’ve learned about cloud infrastructure.  People find it valuable – after all, they’re paying to attend the Amazon classes – and I heard a lot of good questions that we can address here in the blog.

We’ll be sharing more of our success (and failure) stories in migrating database applications to the cloud including our very own site.  Yep, BrentOzar.com is finally moving from a single virtual server to a highly available and elastic infrastructure using Amazon RDS, EC2, and load balancing.  We’re aiming to go live next month before the conference season starts, and you’ll know when we do – we’re bringing an amazing new look to the site, too.

Learn more about our SQL Server in Amazon cloud resources page.