DevOps Playbooks

March 12, 2018 Back to home

There are several books, blogs, and tutorials about devops. There are thousands of approaches to a devops playbook. If you noticed, my title is not "the devops playbook", it is simply devops playbooks (plural). Why? Because the more you create code, the more you attempt to create boilerplates, patterns, and strategies, the more you realize is that each one is slightly different.

There is no silver bullet

Devops is a buzzword that is rarely understood and often is as mystical as an entrance to different dimension. Devops is often bundled up as infrastructure work or architecture implementations. It is much more than that. I want to identify that whatever boilerplate you are starting from, you will change it. There is no silver bullet. Are you deploying an API, a mobile app, a web application, a database? Are you using Circle CI, Jenkins, VSTS, CodePipeline? Are you using AWS, GCP, or Azure? Those are some of the things to consider. Technology moves faster than an atom in supercollider. :-) There are now containers, docker, and container orchestrations (Kubernetes, Docker Swarm, and Mesos). To approach a devops playbook is quite a challenge...

There is a consistent approach though!

You can approach your playbook creation with the same process though. You need to identify what you are trying to solve with devops. You should ask this: What are you doing?! Seriously, start there. I have seen so many people jump onto, we need jenkins, 2 servers, a mongo db, a sql server, and 3 build environments. Wait why? There is a book called, Start with Why. It is a good read, but I love the title most of all. Why do you need Jenkins, is that really the best process, where are you hosting, why are you hosting there, do you need to host, or is it a native deployed app? So start by identifying what are you doing, as in, what are you building, an app, a web site, a data store, an api, etc... Then after you identify what you are building, don't immediately jump to scale, everyone wants to know how you are going to handle 10 million concurrent connections. How about starting with one. How are you going to handle one? Security should be consider before scale. How are you going to secure your application? So let me list the things to consider:

What are you solving by building your thing?
What are you building? Native App,Web App, Data Store, API, CMS, etc...
Where are you hosting it? AWS, Azure, GCP, Hostgator, BlueHost, GoDaddy, etc..
What level of security do you need?
How do you deploy it locally?
How do you deploy it to the host?
How do you handle moving from local to host?
How many environments do you need hosted? (The answer to this should always be at least 2, one qa, one prod)
How do you move from environment a to environment b?
How do you automate this?
How do you make sure it is stable? (Unit tests, integration tests, ui tests, build checks)
What are syntax rules and are they enforced (lint as much as you can)

This by no means is an exhaustive list, but it should get you started in developing your playbook. Remember it is a playbook not definitive recipe. You can have multiple plays in a playbook, but that doesn't mean you have to call every play. That is what I have learned.

You can always call an audible

Since everyone has tied this to a playbook, let's keep with the football analogy. You can call an audible. You can make a different decision at implementation time. Don't be dogmatic about anything in tech. When you are, you are killing the concept of being agile. You are not open to new technologies, You are now limiting yourself to a potential better option. If you ever hear, "This is how we have done every other project", you should always respond with, "Why?". Jenkins has several security risks recently, Circle CI is a relative new comer but it isn't free, then there is Team City which I really like, and now AWS CodePipeline is pretty amazing. Regardless, there are a lot of options. You will get comfortable with a certain technology and then figure out how to make it fit.

Everything is not a nail

I loved that analogy, if all you have is a hammer, then every problem looks like a nail. That is a real difficult perspective to break. The experts of a certain technology can show you how this amazing "hammer" can be tweaked to work for any problem that come along. I have seen WordPress be used as static website, I have seen WordPress used as a full CRM with e-commerce. I am not sure which is the right approach without more details, but WordPress doesn't solve every application problem. Also, custom .Net applications is not the right answer every time either.

Conclusion

Think of what you are building and address each problem as a new problem. You will gain experience over time on possible solutions, but be open to the new options. Be excited about an easier solution, not dogmatic about "how you have always done it". If that were the case, I would still be doing deployments with batch scripts and ftp. There are better options! Think, ask why, and research what is out there. Then automate it. Remember, you can't start with automation, you should start with manual to make sure you know what is happening, then automate what you know works.

Go build your playbooks... and share them with the world... we all need your solutions!