To get the full details on what we do for C. When you build and maintain your environment manually, change is risky and slow:Īs part of all of our automation, we use Git and other source control utilities so that whenever we create a set of changes, we have a clear audit log. When you are done, each server is in a known, ideal state. That means changes can be rolled out to many instances at once - and be rolled back. The value of Puppet (or the configuration management tool of your choice) is that when you want to change the OS, you can change code on the servers without making major changes to the servers themselves. Why build a new environment this way rather than just in the AWS console? While it is true that this process is substantially slower the first time around, it lets you build out new environments consistently, while Puppet provides a “central source of truth” for the configuration of all your systems. So every new environment follows the same build process, which begins with AWS CloudFormation templates: We could build things manually (in the AWS console) or automate. When we are creating a new environment or a new network architecture in an environment, there are two clear approaches.
An update to infrastructure or OS configurations.To design for constant change, first we need to understand what changes we anticipate. We try to avoid direct human intervention in an environment as much as possible and look for opportunities to avoid human error. We leverage some of the Auto Scaling features of AWS to make sure we have redundancy at every level of our stack.Īnd finally, human effort is a security risk. In the cloud, you must design a system that rarely fails, but you also need to design a system that fails well. The third principle we follow is to anticipate failure. That means designing repeatable components, not doing ad hoc or one-off builds or deploys just to get the job done. Part of designing for constant change is not just at servicing an individual stakeholder’s concern, but do it in such a way that issues can be resolved more efficiently when they come up again. That means building an environment that is not just suitable for Day 1, but can be managed efficiently and changed without too much risk. In modern development, the ground is constantly shifting underneath us, and we need to be comfortable with ongoing changes. The first, and probably the most important, is to design for constant change. Build repeatable components, not snowflakes.We follow a few different principles for DevOps in the cloud:
In the new world, we develop smarter software to control complex systems and deployments. You needed more hardware, or a bigger staff, and that meant more complex infrastructure buildout and development processes. It used to be that scaling and movement meant throwing people and money at problems. Automation allows us to efficiently manage the fact that infrastructure changes all the time. There are no “completion dates” on a lot of cloud projects. And because the cloud frees us from the limitations of hardware, there are a lot more moving parts that we have to consider. The days when IT departments managed a monolithic, infrequently modified stack are long gone. We talked about the art and science of DevOps on AWS, including infrastructure as code development and the role of configuration management.
Solutions Architect and DevOps Engineer Phil Christensen to get an in-depth look at how to build a mature automation practice. Automation is the engine that powers effective cloud operations teams - but what does it really look like in practice?