DevOps Journey Part 5 – Production Infrastructure

We have talked about specific types of pain: things breaking in the production environment that didn’t in the development environment, which we called “Works for me;” taking too long to get features out the door, which we solve with continuous improvement / continuous development; and the pain of not having a staging environment in which to properly test features before rolling to production. This time, we address the worst kind of pain: the fear of change.

Question: How many psychologists does it take to change a light bulb? Answer: Just one – but the light bulb has to want to change. Raise your hand if this applies to you: you get to a production environment and you get some ideas for improvements, but you don’t want to risk implementing them because you’re afraid something might break. We’ve all been there. But, there are consequences to this thinking, aren’t there? Preferring the status quo leads to unmaintained servers and improvements that get pushed back.

Insert Crafty Penguins into the equation. We want as clean an environment as possible, but we’re not afraid to break things in our staging environment, because that’s how things improve. And, while we’re breaking stuff, you can focus on rolling out features (which is what you’d rather be doing anyway). Why is this so important? There are four reasons.

1. Our approach at this stage helps prepare for dynamic scalability. We break things, find solutions fast, then create automation around those processes to replicate them.
2. Second, our approach adds value for Cloud resources.
3. Third, we can design for maximum up-time.
4. Fourth, we can set up client-level feature testing (A/B, Canary, etc.)