The Friday before class started I received an email from people running the Architecting with AWS training class about how to get to the class, what time class got started, a schedule of topics, and a link to prerequisites that I should go through before arriving at class on Monday morning. Most training classes I’ve attended haven’t done anything like this, so I was anxious to get started with the prerequisites. The homeworks was simple: they walked attendees through setting up an AWS account, sign up for the necessary AWS services, and locate AWS account information. All in all, I was pretty impressed with how things started – a lot of the set up for AWS can be overwhelming the first time through and the prerequisite homework would have been very helpful when I first got started.
Day One: The Big Picture
On the first day of class, I grabbed a cup of coffee and headed over to the training class. I attended the class in Seattle. It turns out that Seattle is a great place to attend the Architecting with AWS training: the class is held in the same building that houses the AWS team. At several times during the class we had guest appearances from AWS staffers who gave short training sessions on different technologies. A few of the AWS staffers also hung out in the back of the classroom to help answer questions.
Class began with a round of introductions. The instructor, Evan Brown, lead off and discussed his experience with both AWS and the course material. What surprised me the most was the makeup of the attendees. There were people from large and small companies across many different industries. I had expected that the focus would be on smaller companies or consultants, but I was wrong. There were new hires at Amazon getting brought up to speed on the technical side, pure R&D teams, consultants, and people from some very traditional companies.
Training started immediately after the round of introductions. We started with a discussion of the course layout and then dove into our first sample architecture: a scalable web application. The sample application was presented as a set of business requirements and a loose set of SLAs. After going over the general application, Evan led a white board discussion of different features and functionality from AWS that could be used to build the application.
Architects have to deal with the big picture. Depending on your specialization, this can be a database, network, or application stack. In AWS, the architect’s domain is everything that lives in or touches AWS – from software to storage to security. Needless to say, there was a lot of material to cover. We spent an hour or so discussing the core features of AWS – Amazon Machine Images (AMIs), RDS (database as a service), load balancing, and the different ways of storing files in AWS (S3, EBS, and ephemeral storage). Even though I’ve been using AWS for a while, this was a very helpful part of the course. It’s important to understand the different services that AWS offers and how they fit together as part of a larger solution – there are many services in AWS and they accomplish a lot more than a casual observer might think.
One of the most interesting parts of the day was the discussion around security in AWS. I know that the cloud is secure, but I also know that I’m not a security expert. The security section of the course made it clear that it’s possible to create applications with very fine-grained security. Not only can users be granted specific security permissions but the security model extends to VMs, services, and even API calls. I’ll admit that security is well outside of my comfort zone, but I came out of this portion of the class knowing that I have a good starting point for communicating my security needs when I design solutions in AWS.
Days Two and Three: Application Services
The second day started off where we left off the day before. After discussing the IaaS platform of AWS we started talking about the different services that AWS provides on top of the infrastructure as a service platform. Combining the AWS services with different ways of running your application in the cloud gives architects and developers flexible ways to create very rich services. With a little bit of development and configuration it’s possible to create automatically scaling, self configuring application server tiers behind load balancers that respond to increases and decreases in customer demand. In short – you can make an army of evil server robots that will do your bidding.
Day two was entirely centered around application services. We worked on material to help build out our multi-tier web framework from day one and then switched gears to design a batch processing application. Although the requirements were very different – batch processing has doesn’t have nearly the interactive needs of a web application – we were able to build on the knowledge of AWS services that we gained early in the class. This brought up some great discussions over when an architect should choose one service (Simple Workflow Service) over another (Simple Queue Service) when the overarching idea (queue up work and then do it) might be exactly the same.
In case you didn’t notice the theme of the first day, a lot of the classroom time focused on discussion. While there was plenty of lecture time around the AWS services, there was also a ton of time devoted to sharing experiences and ideas with other attendees. This was, hands down, my favorite part of the class. The best part of classroom discussion is building on the knowledge of others to get a deeper understanding the problem domain as well as potential solutions. In such a big class it was only natural that there were a lot of technical problems spread across a wide range of potential problem domains.
The Bad Stuff
Every topic in class could have been a 5 day training class. There was simply too much material to cover in any depth, so I was left hungry for more. I have a laundry list of things to try from building simple CloudFormation templates to building rich self-deploying application stacks. There is a follow up 4 day class for operations staff that focuses entirely on the automation piece of AWS, but that still didn’t stop me from wanting more detail right away. There is a lot of AWS documentation available, but the downside is that there’s a lot of documentation available (the EC2 guide would be 700+ pages long if you printed it out).
I mentioned how much I enjoyed the in class discussions, and they were a critical part of the event, but they could also be a bit much. It only takes one person to dominate a conversation or a classroom and it did happen once or twice. The instructor did a good job of handling the discussion and pulling things back around to the class material, but if you’re really bothered by that sort of thing, be careful if you go to this class. The other downside of classroom discussions is that you can’t predict how long they will take. Just because the syllabus says there are 15 minutes for class discussion, that doesn’t mean anything – At the end of the first day we were over an hour behind schedule. We caught up by the end of the class, but discussions can drag things off in a different direction.
Homework? Only If You Want It
There wasn’t any homework. At the end of each day I went back to my hotel room and reviewed my notes and went over the presentation material. When I wasn’t clear on something, or just wanted to play around with spinning up a few EC2 instances, I was able to repeat the exercises in the course material and make sure that I fully understood them. Thankfully, Evan showed up to class early on days two and three so I was able to head in early and ask any questions that I had about the previous day’s lecture or exercises.
At the end of the three days, I wasn’t feeling exhausted but I did feel like I’d been working my brain. I knew more about the AWS ecosystem than I did going in and I felt reassured that other people are running into the same problems moving into AWS and are solving them in a bunch of different ways.