Book Club: Cloud Native DevOps with Kubernetes

Welcome to my journey to better understand Kubernetes.

A quote I’ve taken to heart is: “You will change by one of two ways: the books you read and the people you meet.”

Reading is a core part of my regimen for learning any new skill and Kubernetes is no exception.

I recently finished:

Cloud Native DevOps with Kubernetes: Building, Deploying, and Scaling Modern Applications in the Cloud by John Arundel and Justin Domingus

I’m a consistent proponent of defining shared nomenclature (a fancy word for how we name things) to foster teamwork, collaboration, and communication. Towards that end, the Cloud Native Computing Foundation defines “Cloud Native” as:

“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”

Kubernetes is by no means a small part of this approach and John and Justin have put together a fantastic guide on how to stand up, run, maintain, and secure Kubernetes in a cloud native environment.

Now, let’s dive in.

Keep Tooling Decisions Simple

The book begins with the discussion topic of managed services and open source offerings in the Kubernetes ecosystem (AWS EKS, Google Kubernetes Engine, Azure Kubernetes Service). The authors make the following points very clear:

Kubernetes is hard
Start with managed services

The reasoning behind this approach is that simplicity is the best way to combat complexity.

Simplicity.

One of the most important principles I adhere to that can often be difficult to achieve in practice in our complex world. Sometimes the simplest solution can still be complex, and it can be difficult to properly distinguish which side of the line you’re on.

John and Justin point out early the vast array of ever-growing tools and complexity within the Kubernetes ecosystem. Some may relate to this gif.

To combat this complexity, they recommend the “Run Less Software” approach by Rich Archbold, of which there are three pillars:

Choose Standard Technology
Outsource undifferentiated heavy lifting
Create enduring competitive advantage

This approach definitely resonates with my experience both in and out of software development as these pillars offer a rationale by which to make the simple/complex distinction. Choosing standard technology helps avoid the trap of “reinventing the wheel.” Outsourcing undifferentiated heavy lifting improves your organizations focus on impacts that truly enact change and deliver value. Both of these pillars directly contribute to the third - creating an enduring competitive advantage.

If you would like to dive in further, check out Rich’s classic blog:

https://www.intercom.com/blog/run-less-software/

Tie concepts to practical application with Clusters, Pods, and Containers

I’m a big hands-on learner. In my experience, practicing tactics provides better understanding of strategy, and learning strategy provides better context to practice tactics.

With that in mind, I appreciate the authors including a few walkthrough steps to build and deploy an example application to Kubernetes and learn about the fundamentals of pods, deployments, and services, and how to manage them with manifest files and helm charts. The authors also kept it simple enough to not lose me needlessly in the weeds.

Sections of the book also walkthrough:

Managing Resources
Operating Clusters
Running Containers
Managing Pods
Configuration and Secrets

Security is an Ongoing Process

It never fails to humor me how the common mantra is “shift security left,” and yet the security chapters are always in the back half of the book.

The authors dive into managing access control by cluster, introducing RBAC, Kubernetes scanning, backups and leading tool options, and monitoring cluster status. I saw some familiar tools referenced which definitely helped me reinforce how concepts relate to tooling (such as backups and use cases with Velero).

The Problem with Continuous Deployment is the Sheer Range of Choices

The authors include discussion on various Continuous Deployment tools as well as steps for deploying to the cluster and creating deployment triggers.

This is a pretty short section, and was written more as “pick the best tool for your needs”, rather than being prescriptive.

Observability is about Understanding Systems

“Automated monitoring is checking the availability or behavior of a website or service, in some programmatic way, usually on a regular schedule, and usually with some automated way of alerting human engineers if there’s a problem.” Observability extends beyond traditional monitoring.

The authors discuss Logging, Metrics, Observability, and Monitoring with touches on familiar tools like Prometheus, Grafana, Google Stackdriver, and AWS Cloudwatch. They start with a brief history of blackbox monitoring with tools like Nagios, and a brief discussion of logging and its limitations (scaling difficulties, hard to extract information, etc.)

These discussions continue to the concept of tracing. “While metrics and logs tell you what’s going on with each individual component of your system, tracing follows a single user request through its whole lifecycle.” I very much enjoyed their reference to Masroor Hasan’s blog post on Distributed Tracing Infrastructure with Jeager on Kubernetes which elaborates on how to use Jeager for distributed tracing in Kubernetes.

The authors gather the collection of these discussions into the common definition for observability “as a catch-all term that covers all of these techniques” given that “monitoring” means different things to different people. They present a very useful way to distinguish the terms observability and monitoring as “monitoring tells you whether the system is working, while observability prompts you to ask why it’s not working.”

Tying back to our earlier discussion of software being complex, it is also opaque. Observability is about understanding systems and what they do in order to diagnose problems through that opaqueness and ensure our systems are working properly.

Bonus: People and Culture First

In addition to the “Run Less Software” philosophy we reviewed at the start of our dive into Cloud Native DevOps with Kubernetes, there are two other philosophies the authors touch on:

4 Pillars of DevOps - John Willis
1. Culture
2. Automation
3. Measurement
4. Sharing
DevOps Trinity - Brian Dawson
1. People and Culture
2. Process and Practice
3. Tools and Technology

I find these critical refreshers on remembering that for all the talk of “automation” in our industry, people and culture are the driving force behind that automation. Even with these takeaways and time investment into learning new technologies, I read far more on leadership, mindset, and teamwork fundamentals, and appreciate that the authors acknowledge these philosophies at the outset.

Automation and measurement, along with process and practice, are the strategic level concepts that I feel this book did a fantastic job of providing tactical information for in the context of Cloud Native DevOps with Kubernetes. Knowing why you’re automating a process, measuring a system, or using a tool is critical before diving into the many rabbit holes of how to properly build and scale processes, as well as implement tooling.

Finally, all this information is limited in value if retained and hoarded by individuals. I thank the authors for sharing their insights, and hope you found value in me sharing my experiences. May you share your learnings with others as well.

A rising tide truly lifts all boats.

Thank you for reading!

We’re all on the learning journey together. I enjoy writing these book reviews as they help me review and digest the information I’m reading and I hope you enjoyed reading as well. I look forward to putting together more of these book reviews here at the Aquia Blog “The Tributary” and LinkedIn.

If you found value from this, please share or send a connection.

Please support the authors, John Arundel and Justin Domingus as well!

If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.