Preface

When you get older it seems to me that most people reflect on their lives. How they got where they are, where they succeeded, and where they failed. I can say in all honesty that I've failed in my career. I know it is abnormal to start a book with an admission of failure, but I figure why start the book off with lies about succeeding beyond my wildest dreams?

My aspirations align more with Jimmy Buffet than Warren Buffet. Keeping my interest in anything for more than a few years is a challenge and my idea of a hard day's work is sipping a piña colada on a Hawaiian beach. Alas, I have failed in my ambitions. The closest to that dream I've gotten is working for a boss who always wore Hawaiian shirts and I don't think that counts.

This whole "expertise" in automation came out of my need to do as little work as possible. When I was a desktop support technician, I needed ways to build a lot of machines in a few hours instead of manually installing Windows and applications. I wanted to spend my days in the office playing video games, reading books, or walking around and talking to people. When I was a network engineer, I wanted people to stop paging me when I was comfortably sleeping in the switch closets around campus. So I wrote tools that allowed others to switch VLAN ports or clear security parameters from a network port without calling me. Why manually balance BGP traffic every week when I could write a program that used SFLOW data to do it?

It was going so well until I got ambitious and went to Google. I wrote a few tools to help make the job easier for myself, such as figuring out whether on-call pages were really caused by ongoing scheduled work or programs to provision all load balancers in a data center. Back in those days, Google had plenty of massage chairs and other amenities I'd rather have been taking advantage of instead of migrating links on a data center router while on the phone with an overworked hardware ops technician in Atlanta and typing into an IRC channel on why my network drains were still in place.

But then people started wanting to use my tools. My friend Adel would ask whether I could make something to program facility routers or validate that Force10 routers were set up right. And he was such a nice person, you just couldn't say no. Or Kirk would come over and ask how we could automate edge router turnups because his team was getting overworked. Instead of making my job easier, I ended up working more hours to make other people's jobs easier!

Hopefully my failures can help you in your success (my father used to say that no one is completely useless; they can always be used as a bad example).

This book is filled with many of the methodologies I've used in my career and lessons on what I believe to be the best language for DevOps at this time, Go.

David (my coauthor who will introduce himself in a moment) and I come from two different extremes of the DevOps world. I come from a school of thought where almost no commercial or standard open source software is used. All DevOps tools are developed internally and are form-fitted to work in a specific environment. David comes from the school where you use as much open source software such as Kubernetes, GitHub, Docker, Terraform, and so on... as you can. This allows you to leverage a collection of available and popular tools that may not be exactly what you want, but come with support networks and lots of options. It is easier to hire engineers who already know how to work on industry-standard tools than those who work with custom toolsets. In this book, you will find a mix of these ideas and methodologies that encompass both schools of thought. It is our belief that a mixture of readymade and custom tools will give you the biggest bang for your buck.

Our sincere hope is that this book will offer you not only a guide in using Go for your DevOps needs but also the ability to write your own tools or modify existing ones to leverage the power of Go to scale your operational needs at any company. And if nothing else, both David and I will be giving our proceeds away to Doctors Without Borders, so if you bought this book and nothing else comes of it, you will be helping a good cause.

But maybe you will one day be sitting on the beach, collecting your paycheck while your automations take care of the day-to-day. I'll keep working on that goal, so if you get there first, have a drink for me.

With that said, I'd like to introduce my esteemed coauthor, David Justice.

As John mentioned, we come from different origins, but find ourselves approaching similar problem spaces. My background is in software development and software engineering spanning everything from mobile application development, web development, and database optimization to machine learning and distributed systems. My focus has never really been DevOps. I'm what you might call an accidental practitioner of DevOps. My DevOps skills have come from the necessity to provide ever-increasing business value, which required me to automate all of the things that were not related to delivering new features and defect resolutions. My secondary motivation for developing DevOps skills is my desire to consistently deploy code and sleep through the night. There is no motivation quite like running a start-up and being the only person around to service a high-severity issue at 3 a.m. to encourage you to build resilient systems and automations.

The motivations I described here should provide the basis for why I tend to choose solutions that are quickly applied and have considerable support in the open source community. If I can find an open source solution with great documentation that can do the vast majority of what I need pretty well, then I can glue and tape the rest together as needed (if you get down deep enough, at the bottom of nearly every solution is some dirty Bash script). For me or my teams to invest a great deal of time and effort into building bespoke tooling, I would need to have a considerable return on investment. Furthermore, when I think of bespoke tooling, I also consider the cost of ongoing maintenance and education of new team members. It's simple to point new team members to a project such as Terraform and ask them to learn it. There's great documentation and endless blog posts detailing every imaginable scenario. There's also a good chance the new team member already knows Terraform because they were using it at a previous job. This reasoning drives me to require a significant burden of proof to approve a project to build bespoke tooling. For these reasons, I've spent quite a bit of time using open source DevOps tooling, and I've made it my business to be as good at extending that tooling as I can be.

In this book, you will find a variety of bespoke tools for accomplishing tasks using only Go and the standard library. However, you will also find several examples of how to use existing open source tools to accomplish tasks that would otherwise take a vast amount of custom code to achieve. I believe our different approaches add to the value of the content and provide you with the tools needed for understanding the trade-offs involved in inventing your own solutions or extending existing solutions to solve common DevOps tasks.

As John left off, I too hope that this book will help you reach a Zen-like state of automation mastery so that you can follow in John's steps and live more like Jimmy Buffet than Warren Buffet.