AWS Re:Invent - ARC307 - Infrastructure as Code Session

Live Blog of the AWS Re:Invent Infrastructure as Code Session (ARC307)

Packed house - This session is offered in one of the large ballrooms. At least 1,000 people in the session and this session on the live stream as well. David Winter & Alex Corley from AWS as well as Tom Wanielista from Simple.com presenting

David up first - his background is a very traditional datacenter hardware centric background. He had a project to build on AWS.

Started simple with manual spin-up of instances, it wasn’t fast enough one person using a console. He needed to go faster. API was the next step, he then built a bash script. His first steps…

Hired somebody else, they then wrote the same in python. This was the beginning of using this as a “cookie cutter” repository for test/dev. Then one day something bad happened… (Security related event)

Production went down… hard. (Security groups were removed by beta product they were testing), all networking went “deny all” in the security groups, locking everyone in the world out

Had to rebuild them all by hand… (ouch)  How do you prevent this from ever happening again.

AWS Cloud Formation was now the basis for “Infrastructure as Code”. Too much configuration that was done by hand needed to be automated to recover quickly. Also, this allows iteration of new development cycles very fast as a side benefit to go forward.

Alex Corley is up - version control to wrap complex systems and provide a template for roll out. Cloud Formation uses a model methodology to define the infrastructure. You create models in Cloud Formation (CF from now on), JSON structure

CF supports just about all AWS services today (security groups, compute offerings, network services, etc.)

version control is built in CF. Store the intended stated (next rev) in CF and do a code review before it is published. Can use many different repositories (GitHub for example)

Create a template, check it in, code review, deeply worldwide across AWS regions. All automation handled through CF.

Tom from Simple.com - (customer testimony) - simple is a bank. SOA architecture on AWS from Day One. 

They started at the console just like most everyone. As they developed features and grew, this got out of control. They didn’t know who changed what and what happened.

And then along came PCI compliance… No way to audit and report on the current infrastructure. Had to start over from scratch.

Goals: Security / Insight / Growth / Speed - these were the 4 pillars of the new infrastructure.

The rebuilt using AWS Cloud Formation, then they wrote cloudbank in Python. Middleware between simple.com and AWS Cloud Formation from an operations stand point. Everything stored in github. They modify cloud bank, it talks to CF. Jenkins cluster in the mix

cloud bank applies the AWS standards under the covers (security groups, network settings, etc.)

What are the benefits of this automation? They write code every day, they simple added the ability to spin up infrastructure and moved this into the code flow greatly increasing efficiency and agility of the organization. This also makes the infrastructure programmable. For example, there is a chance in PCI compliance, simply push out the change in code. The developers can now handle the infrastructure.

They have evolved from 20-200 people and are still using this method.

David back up - demonstration time (Alex doing demo)

Alex - demo application (web application) running on AWS. Cluster of 5 machines. talking to a git repo, made a chance in the code to increase the size of a graphical fix. commit the change, refresh and it was fixed.

Supposed to be 5 machines, only one is talking. Modified Cloud Formation instance to talk to 5 hosts, commit, refresh the app, now more instances talking to the front end.

Last issue, throughput is insufficient now.  Double infrastructure now from 5 machines to 10 machines to get more bandwidth to the front end. This spins up 5 new AMI’s, some custom configuration and insertion into the cluster, all done with a commit

Application problem, security problem, infrastructure problem - all three fixed through the same process and change management model

Wrap Up:

Good for startups - Agile, developers ramp quickly

Good for Enterprises - Template driven, compliance oriented infrastructure