Book Image

Implementing Modern DevOps

By : Danny Varghese, David Gonzalez
Book Image

Implementing Modern DevOps

By: Danny Varghese, David Gonzalez

Overview of this book

This book follows a unique approach to modern DevOps using cutting-edge tools and technologies such as Ansible, Kubernetes, and Google Cloud Platform. This book starts by explaining the organizational alignment that has to happen in every company that wants to implement DevOps in order to be effective, and the use of cloud datacenters in combination with the most advanced DevOps tools to get the best out of a small team of skilled engineers. It also delves into how to use Kubernetes to run your applications in Google Cloud Platform, minimizing the friction and hassle of maintaining a cluster but ensuring its high availability. By the end of this book, you will be able to realign teams in your company and create a Continuous Delivery pipeline with Kubernetes and Docker. With strong monitoring in place, you will also be able to react to adverse events in your system, minimizing downtime and improving the overall up-time and stability of your system.
Table of Contents (17 chapters)
Title Page
About the Author
About the Reviewer
Customer Feedback

DevOps and microservices

Microservices are a big trend nowadays: small software components that allow companies to manage their systems on vertical slices of functionality, deploying features individually instead of bundling them in a big application, which can be problematic in big teams as the interaction across functionalities often leads to collisions and bugs being released into production without anyone noticing.

An example of quite a successful company using microservices is Spotify. Not only at the technical level but at the business level, they have organized things to be able to orchestrate a large number of services to provide a top class music streaming service that pretty much never fails, and if it does, it is a partial failure:

  • Playlists are managed by a microservice; therefore, if it goes down, only playlists are unavailable.
  • If the recommendations are not working, the users usually don't even notice it.

This comes at a huge cost: operational overhead. Splitting an application into many requires a proportional amount of operations to keep it running, which can be exponential if it is not handled well. Let's look at an example:

  • Our system is composed of five applications: A, B, C, D, and E.
  • Each of them is a microservice that is deployed individually and requires around 5 hours a month of operations (deployments, capacity planning, maintenance, and so on)

If we bundle all five applications together into a single big application, our maintenance cost goes down drastically to pretty much the same as any of the previously mentioned microservices. The numbers are clear:

  • 25 hours a month for a microservices-based system
  • 5 hours a month for a monolithic application

This leads to a problem: if our system grows up to hundreds (yes, hundreds) microservices, the situation becomes hard to manage as it consumes all our time.

The only solution to this is automation. There will always be an operational overhead, but with automation, instead of adding 5 hours a month per service, this time will decrease with time, as once we have automated our interventions, there is pretty much no time consumed by new services as everything happens as a chain of events.

In Chapter 8, Release Management – Continuous Delivery, we are going to set up a continuous delivery pipeline to demonstrate how this is possible, and even though we will have some manual steps for sanity, it is possible to fully automate the operations on a microservices environment running in a cluster such as Kubernetes.

In general, I would not advise any company to start a project based on microservices without proper automation in place and more specifically, if you are convinced that the system will grow over time, Kubernetes would be a very interesting option: it gives you the language that other platforms lack, such as load balancers, routing, ingress, and more. We will dive deep into Kubernetes in the upcoming chapters.

All these activities are supposed to be part of the DevOps engineer's day-to-day work (among many others), but first, there is a problem that we need to solve: how to align our company resources to be able to get the most from the DevOps engineer figure.