The AWS Iceberg

As I mentioned in my previous post, delving into AWS is like spotting an iceberg. Prior to doing any technical research, I'd already looked at the myriad number of services available in the AWS universe. A lot of it looked like alphabet soup, but I'm happy to say I'm starting to make my way through the alphabet.

The documentation is a bit daunting. It's very thorough, and some of the tutorials are very clear. By and large though, the documentation looks like it's written by a technocrat. Side note - this is a beef I have with a lot of technical documentation, even documentation that's generally universally accepted as 'good.' While I do appreciate a very complete explanation of an API, when I'm starting on something, I'd prefer a narrative tutorial that I can read and re-read (so, not video documentation). Ah, well it seems that I'm more opinionated on documentation than I expected, so maybe that's a post for another day.

Anyway, here's the AWS link that got me started. Prior to actually starting up an instance, I had to run through these steps before introducing myself to EC2. A few notes on the steps:

1. Sign up for AWS - Well, this is a given.
2. Create an IAM user - IAM stands for Identity and Access Management and is the 1st key component in AWS security. Essentially, it allows you to set up users in your AWS systems with certain fine grained permissions.
3. Create a key pair - This allows your IAM users to login into AWS servers using a public/private key pair instead of a password.
4. Create a VPC - VPC stands for virtual private cloud and is set up by default when you sign up for a free tier account. This allows you to take Amazon's virtualized hardware and carve out your own little network. At the scale I'm working at, any service (or additional instance of say, EC2) that I add to my account is added to the VPC and can connect to other services and instances without headache.
5. Create a security group - This is an area I'm definitely interested in exploring more. These groups get tied to IAM users to give them particular permissions (say admin access across services). There are a slew of default options, but I believe these can also be created with more fine-grained permission as well. Having to deal with SOX compliance issues in the past from an auditing perspective, having out-of-the-box capability to restrict users via fine-grained controls is a very powerful possibility.

Even though I've got all of the basic security controls set up, I believe there are still some additional recommendations from Amazon that I need to heed. I'll discuss those in a future post as well.

Well, I was hoping to talk a bit more about my actual EC2 experience, but the post on AWS set up turned out to be a bit longer than expected, so I'll leave that for the next post

Back in the Fold

After about 4 years of managing development teams, I'm making the jump back into software engineering to assist my current employer in moving services to AWS. To say that there's some impostor syndrome here is a bit of an understatement. Prior to being a manager, I was a developer (predominantly Java) for 8 years and have continued to dabble, but haven't committed code to production since becoming a manager.

Needless to say, I've got a lot of ground to cover. In order to deploy services to AWS, there are three initial components I'm concentrating on:

• AWS (Up to this point, I can only tell you what EC2 and S3 are from memory. I really have no concept of how they're connected.)
• Docker (Containers for everyone!)
• Chef (I'm still trying to determine if, given an appropriate image for a Docker container, do I need configuration via Chef. So far the literature on the web has been a bit inconclusive).

I spent the 1st week of my new career reboot learning Chef. Not sure why I picked that 1st - probably because Docker necessitates a VM, and I'm on a Chromebook at the moment, and AWS seems a bit too much to bite off for a dilettante.

I really liked running through the exercises at the Chef tutorial site. Because I fat-finger a lot of commands while typing through the examples, I gained some pretty valuable experience about how to run basic commands in Chef and was able to browse the documentation a bit. I made it as far as Learn to manage a basic Ubuntu web application, but then got bogged down a bit while reading through the material on kitchen, Chef's integration testing tool, because I don't have the compute power at the moment to start up a VM (re: see Chromebook reference above).

Still, I'd like to go back and play with ChefSpec and kitchen a bit later to see exactly how one can test infrastructure as code. At this point,prior to trying anything in Docker,it's worth noting that infrastructure that can be saved via a source control repository appears to be very valuable. The literature that I've read seems to indicate that Docker lacks that, but I can't confirm that's the case yet. If it is true, then I can certainly see why Docker and Chef go hand in hand. The former deploys the containers while the latter manages the configuration of those containers via source control.

At this point, however, I've moved on to the basics of AWS by signing up for their free EC2 instance, so it'll be a little while before I solve that mystery. Hopefully, I'll have more to say about the Docker/Chef conundrum and AWS later.