Found 3 results in infrastructure as code

In this blog post I am going to talk about several security best practices, particularly for configuring AWS Access Keys. Some of these practices are based on a project that we inherited which was compromised by hackers. Best practices are often learned from mistakes; and when the mistakes are someone else's, so much the better!

Earlier this year we wrote about adopting Vagrant and Terraform in our steady march toward Infrastructure as Code. We recently added a new tool to this list, HashiCorp’s Packer. Packer automates building machine images, and with a single set of provisioners, creates images for multiple builders (such as VirtualBox, DigitalOcean, and Google Cloud).

Intended audience: technical managers, senior developers

Agile developers must constantly strike a balance between building solutions for a known existing case and building solutions that can scale to handle unknown future cases. On the one hand, Agile philosophy encourages us to build and iterate as necessary: Move Fast and Break Things. On the other, various programming best practices encourage us to build in an extensible and modular way from the start: Do One Thing and Do It Well. On smaller projects, these two goals can be achieved simultaneously; but on larger projects – especially given time and budget constraints – it is sometimes necessary to prioritize one over the other. 

Project managers and full-stack developers face such choices almost immediately, during the initial development, staging, and deployment phases. For instance, a project may begin with a narrow scope and require only a single developer’s time. In this case, it often makes sense to forgo provisioning a dedicated development virtual machine (VM) or staging server, and instead, to use generic or shared environments. But as the scope of the project grows, for instance with caching or proxy layers, it often makes sense to implement better development, staging, and production parity.