I'm in a professional services role associated with content delivery, and as such, I've been a bit removed from actual development. You could say I'd lost touch with my coding background. However, over the last 6-8 months, I've been focusing on DevOps at Akamai, and swimming in the deep end of the pool. Since there are are other developers out there embarking on a similar journey, I'd thought I'd share some of my journey with you.
As with most people, I had heard a lot about the cloud providers - Amazon AWS, Google Cloud Services and Azure, coupled with names like Github, Chef, Puppet and so on. I had assumed all of these amorphous things fit into a neat system that magically transformed into DevOps. And yet I knew this understanding was totally wrong.
I quickly realized I needed solid footing, so I took the Linux Academy course DevOps Essentials , which was very useful. It gave me a gentle introduction to DevOps as a technical practice, and how the common tools fit in.
Theory on DevOps
Now that I had a rough idea on the what of DevOps, I wanted to get the reason on why this had become so important. My search brought me to the book The Phoenix Project. It introduced the concept of the pains that a typically organization feels in delivering software, and walks through the transformation as a fast-paced novel. I'm still a big fan of this book and would highly suggest this for anyone coming from an IT Service background. I did collect a list of quotes from this book.
Within the Phoenix Project , there were references to an earlier book called The Goal. This was written in the manufacturing transformation era of the '80s and spoke about how to optimize the assembly line. Since it was referenced so heavily, I decided to pick this up - and I was amazed! The parallels between code development and assembly line manufacturing was spot on. It was one of those moments when you feel like “I could have thought of that!” And yet, it took over 20 years of painful lessons in bad software management to arrive at the same wisdom. If you’d like to understand the fundamentals of DevOps better, read this book and learn about the theory of constraints.
The next step was to get a more in-depth view and learn the how of devops. Actually, this step included more understanding of the what and why as well. For this purpose, I would highly recommend the book The DevOps Handbook. It explains in a very clear manner how organizations can approach the DevOps transformation. The authors cover various aspects from culture, the tooling, and the process necessary to make this transformation. I have published a collection of quotes from DevOps handbook as well.
Apart from the theory, I felt that I needed to understand the various things tools and techniques necessary that leads up to a DevOps organization.
Gaining Hands-On Experience
For hands-on experience, I decided to build some software and adopt the methods being taught by the books. So I used the following things:
|Purpose||Tool / Technique||Comments|
|Programming||Python||I was already familiar with Python and it just made sense to use it. I had lost touch with Java over the past decade.|
Creating virtual environments is essential to provide the exact same foundation for code development. So I had to learn the use of virtual environment. Using virtual environment and the command
|Code repository||Github / BitBucket||The holy grail of most DevOps initiatives is that everything must be an artifact that is tracked in a repository. This includes the project source code and the code necessary to build environments, the test scripts and the various design documents. I used Github, since it's widely used. For all my private coding efforts, I used BitBucket as they offer a private repository for free users.|
|Automated testing||python unittest||Automation testing is an indispensable part of the DevOps transformation. So I had to learn how to write unit tests using a simple framework that is supported by the platform. For my projects, unittest is sufficient. Theory on DevOps recommends more robust testing like Acceptance Test Driven Development / Behavioral Driven Development. Since I am just picking up, this was an overkill and I skipped it!|
|Build automation||Bitbucket pipeline
|To get a feel for the concept of build automation, I enabled the build pipeline on BitBucket. Basically, it takes my
|Build hardening||git hooks||As I was still learning, I experimented with the use of
Standing on the Shoulder of Giants
My learning effort was based on the amazing work being done in this field by so many authors, writes, bloggers and practitioners. I wanted call out a few of them that you could follow as well:
- Jez Humble: Author of the book and maintainer of eponymous website Continuous Delivery, he posts interesting nuggets on Twitter.
- Gene Kim: Co-author of the books Phoenix Project and DevOps Handbook, he's a good person to follow on Twitter.
- Martin Fowler: A veteran at ThoughtWorks, his blog at MartinFowler.com has very good resources and concise definition on the concepts of DevOps.
- DevOps.com: I recently started to follow the blogs from this website. They are quite well written and a good resource.
Developing a DevOps Strategy
At the culmination of my effort, I was able to put out a strategy for adopting DevOps with Akamai. I documented this in another blog post, Planning a DevOps Strategy.
That’s it for now, I hope this has been useful. I'm in the process of taking this further forward, and you can expect to see updates here as I learn more.