AWS: Infrastructure as Code

If you spend any time around DevOps, you will start hearing about infrastructure as code. It sounds cool, but what is it, what does it mean practically, and why is it beneficial?

As Julio Machado Faerman explains, “Managing infrastructure as artifacts of code, instead of hardware, is key to scaling software organizations. Cloud APIs and automation tools can bring many techniques from software engineering to platform operation, including version control, automated testing, configuration management and reliable duplication. Programmable infrastructure becomes invaluable as organizations and applications scale and decomposes.”

Julio is a software engineer and works in developer relations for Amazon Web Services (AWS). He spoke about infrastructure as code and implementing it on AWS at the All Day DevOps conference.

Julio starts his talk with examples of some of the most complex clusters of microservices - such as AWS and Netflix. He underscores that infrastructure as code is important because if you want to scale your organization as much as your software, you need microservices, and, if you need microservices, you need infrastructure as code.

He walked through automating the provisioning, configuration, and deployment of complex applications on top of AWS services. Here are some of his key points.

Build your pipeline automatically with CodeStar. It also allows you to pick your technology profile and different runtime environments.

Automate deployment, load balancing, and scaling of your web applications with AWS Elastic Beanstalk. Julio also mentioned some tools to help stress test your applications and deployments, such Chaos Army, Latency Monkey, and Chaos Guerilla. These tools introduce chaos - unpredicted situations - to test how your system responds. For instance, they will randomly shut down servers.

Julio recommends a concept called Blue Green Deployment, explained by Martin Fowler. It advocates completely automated deployments, and the ability to switch back to other deployments if something goes wrong - automatically. The diagram shows two, but the number is unlimited.

Handle data appropriately to allow for server switching. The bottom line is that you will need to share databases. Sometimes it might be a simple, shared database, but you can run into compatibility issues. Alternatively, you can a non-relational database because the applications can be very write intensive. You can store commands in one database, and use ElastiCache on the read side so that the database can answer queries while it is changing schema. Bottom line recommendation from Julio - don’t introduce unnecessary complexity.

Keep your production environments healthy by having more than one. You can setup rules, such as shifting a percentage of traffic to different servers. One example Julio gave was to direct more traffic to the server with the version of our website that is generating more conversions. He also recommends having an on-premises server and switching between it and your cloud provider.

Test it in production with gradual rollouts, also called canary releases, because they gradually rollout a release to see how it does. CodeDeploy can manage this.

Security and compliance needs to be automated. For instance, all API calls on AWS can be logged on CloudTrail.

Immutable servers are vital. With the ease of creating, cloning, and destroying servers these days, when a server is created, it should be set in stone. If you need to change it settings you create a new server with the new settings. This eliminates issues such as snowflake servers or not knowing how a server was setup because someone can’t remember or they are no longer at your organization. It also means you can provision, configure, and deploy all at once.

Julio also dug into managing shared and dedicated resources with cross stack references and nested stacks and how to manage multi-tenant environments. 

As the industry continues to evolve, Julio's insights give a great foundation for anyone looking to expand their knowledge. You can view his full talk below: