Over the last 4 years at brightwheel We’ve been really lucky so far to be able to use a very popular PAAS (platform as a service) solution to manage a large amount of our infrastructure needs, but now, we need to start implementing some of the practices outlined in the DevOps Handbook to scale up our infrastructure and engineering teams.
For some engineers especially those in Silicon Valley, some of the practices outlined will be self-evident. I’ve worked in companies in and out of the valley, and have seen principles in this book executed very well, but have also worked at companies in other areas and have seen companies struggle to put these practices in place.
The authors are aware of these two worlds and have written this book to cater to engineers at companies that already do DevOps well, as well as engineers at companies where DevOps principles will require leadership’s buy-in.
I recommend this book for anyone looking to understand the philosophy behind DevOps.
Like I mentioned above, we’re working hard in Q4 to get brightwheel off of our existing PAAS based stack and onto a new cloud provider. Terraform is a great tool to help codify your infrastructure, and move it to the existing cloud providers. We use terraform to codify our networking (VPC’s, Subnets, etc), ACL’s (IAM privileges), our databases, and the rest of the more “permanent” parts of our infrastructure.
This book is a good introduction to Terraform, but the edition I had needed an update. Terraform is an open source project run by Hashicorp, as such the ground underneath Terraform is constantly moving, and many of the concepts in this book will be quickly out of date.
I’d recommend following the tutorials in this book, while also referencing the terraform documentation to see how best to update the tutorials for the newest versions of the API.
Having been an Application Engineer for most of my career I found of the movement in the DevOps/Infrastructure community over the last 10 years pretty intimidating. When I started, as a software engineer, Chef was in vogue, containers weren’t really in use (by anyone except Google, even Netflix was using AMI’s to deploy new code), and managing infrastructure in code was primarily done by the big tech companies.
This book is a great introduction to Kubernetes. The core concepts are clearly enumerated and the tutorials are straightforward. I definitely recommend it for anyone coming from an Application Engineering background who wants to get an understanding of how all this kubectl stuff works.
At Bonobos and Naturebox, I was part of the team that was primarily responsible for functionality on the php monolith. At brightwheel, we’ve built the majority of our platform on Ruby on Rails. We’ve used sidekiq, and delayed_job to offload specific workflows to different machines, but all of our code is deployed in a monolithic way. As such, I don’t have a huge amount of experience breaking up a monolith into microservices. The book does a great job outlining the key benefits of a microservices based architecture, and how a microservices based architecture benefits engineering organizations.
It’s a good field manual to understand the pre-requisites of building a microservices architecture.