25 Apr 2020, 17:14
You’ll find lots of blog posts and tutorials anxious to explain what Kubernetes is, in terms of APIs, clustering, reconciliation loops, and goodness knows what else. What they don’t tell you is why. Why do we need Kubernetes? Actually, let’s ask an even more fundamental question: Do we need Kubernetes? What’s the point of it in the first place? How do I know whether I have a problem that Kubernetes solves or not?
To answer that, we’re going to need to take a short detour involving eggs, jars, and omnibuses, via some big metal boxes, and ending up with an orchestra, a blue-green canary, and, perhaps inevitably, the Borg. Hold tight.
02 Apr 2020, 12:00
It’s hard to believe, but ‘Cloud Native DevOps with Kubernetes’ has been out for nearly a year! While much has changed in the Kubernetes landscape, a lot is also the same. In this post we’ll cover some of the things that have changed (and what hasn’t).
29 Feb 2020, 10:29
This is a guest excerpt from Golang trainer John Arundel’s blog. John is one of the authors of ‘Cloud Native DevOps with Kubernetes’, a full-time Go coder and mentor, and a somewhat less than full-time blogger.
Let’s build a Docker container with Golang! It sounds complicated, but it really isn’t. All you need are a few tools, a couple of simple commands, and ideally some cake. (The cake isn’t strictly necessary, but coding is hungry work. It’s a good idea to have some tasty snacks on hand, to keep your strength up.)
25 Jan 2020, 16:29
What does ‘DevOps’ mean? Where did it come from? What came before it? How do you do it? And what happens next?
When we decided to write Cloud Native DevOps with Kubernetes, we knew we wanted to explain what DevOps practices look like in the ‘new stack’ environment: cloud, containers, and Kubernetes. But we didn’t want to assume any prior knowledge of these things; that’s why we explain in simple terms, with a step-by-step tutorial, what containers are and how to make one, how to get started with Kubernetes, and so on.
But while most people have probably heard of DevOps, not all of them are confident they actually understand what it means. So before explaining what DevOps means in the cloud, let’s take a moment to clarify exactly what we mean by ‘DevOps’ in the first place.
30 Mar 2019, 12:00
In this post we’re going to talk about how versioning works in Docker container images. We’ll also explore some different strategies you will want to consider when using image version tags in your own Dockerfiles.
Docker container names are split into 2 parts: the name of the container image, and the version tag of the container image. For example, the container
python:3 is a container hosted on Docker Hub at https://hub.docker.com/_/python. The name of the container is
3 is the version tag. There are several other version tags of
python also available, such as:
Most of the popular languages use a similar tagging pattern in their official images on Docker Hub. Each of these tags represents different variations of an install of Python. Some use a different base operating system images (Alpine VS Debian VS “slimmed-down” Debian), and they also indicate the specific versions of whatever language is installed in the image.
python:3 container image specifically uses Python version 3.8. Whenever 3.9 is released, that tag will get updated and the
python:3 image will then contain version 3.9 instead. In a similar way, the
python:3.7 image would be the latest available security patch of Python 3.7. Currently that happens to be 3.7.3, but tomorrow that could be 3.7.4 if a new version is released.
When writing your own applications, you will need to decide which version of the base image(s) you will use in the
FROM statement(s) of your Dockerfile(s). The options include:
- None (just use :latest, for example, just
- Specify a tagged version number (for example,
- The exact
sha256 digest of an image (for example,
Let’s look a bit at each option, and discuss why you may want to use one tagging strategy over another.
19 Mar 2019, 10:17
John and Justin made a guest appearance recently on the ‘Deloitte: On Cloud’ podcast with David Linthicum, talking about cloud native, DevOps, and Kubernetes from the business perspective.
What I want is just a big ol’ cloud of compute and I can just stuff my container in it and have it work. And we kind of have that now with Kubernetes. It’s not that there’s anything so magical about Kubernetes itself so much as the fact that it’s just universally adopted now.
It was great for us to have a chance to talk about the organizational and business side of things—as David points out in the show, DevOps is always about the people. The ‘Cloud Native DevOps’ book is as much for IT directors, CTOs, and tech leaders as it is for engineers. If you’re not necessarily sold on the whole cloud and container thing, we explore the arguments for and against, and look at why, apart from sheer hype, Kubernetes is rapidly becoming the standard platform for modern apps. The book also explains how and why you need to transform your engineering organization along DevOps lines, and what that looks like in cloud native land.
Kubernetes is a no-brainer when you’re at the hyper-growth stage, and if your business is stable, it’s just the amount of time that you save by using a standard platform. There’s a migration cost, but I think there’s huge cost savings in the long run. It’s absolutely right to ask the questions, what is the ROI, when do we expect
to see this thing pay off, and how do we know if we’re on the right track.
Check out the podcast here:
Deloitte On Cloud Podcast: Cloud migration with containers and Kubernetes
If you don’t have time to listen, and we’re all busy people, you can also read the transcript of the show. Enjoy!
11 Mar 2019, 10:36
The big day is here. It’s been a long time coming, but ‘Cloud Native DevOps with Kubernetes’ is finally published! Your pre-ordered copies should be with you very soon, if they’re not thumping on the doorstep already. If you didn’t pre-order, what were you thinking? Go ahead and buy the book right now:
Buy ‘Cloud Native DevOps with Kubernetes’ on Amazon.com
Buy ‘Cloud Native DevOps with Kubernetes’ on Amazon.co.uk
Cloud Native DevOps with Kubernetes: Building, Deploying, and Scaling Modern Applications in the Cloud
Some reader reviews:
The most encompassing, definitive, and practical text about the care and feeding of Kubernetes infrastructure. An absolute must-have.
—Jeremy Yates, SRE Team, The Home Depot
This book got me really excited. It’s a goldmine of information for anyone looking to use Kubernetes, and I feel like I’ve levelled up!
—Adam McPartlan (@mcparty), Senior Systems Engineer, NYnet
Cloud Native DevOps is an essential guide to operating today’s distributed systems. A super clear and informative read, covering all the details without compromising readability.
—Will Thames, Platform Engineer, Skedulo
Basically, this is the book we wish we’d had when we started trying to do stuff with Kubernetes. It explains the whole background to containers and Kubernetes, tells you what your options are for getting Kubernetes, what to do with it once you’ve got it, how to run it, how to deploy and scale your apps, how to secure your containers, how to monitor and gather metrics on your services, and much, much more! (See the table of contents)
- Pages: 346
- Chapters: 16
- Words: 97,115
- Writing time: 433hrs, 35m
03 Jan 2019, 09:36
Some reactions from the recent Kubecon event in Seattle:
CNCF Projects are a good bet
With an ecosystem changing and splintering as fast as the cloud native world, the CNCF projects are a safe place to bet. They are stitching together a constellation of open source tools that you can use to build the foundations of your applications. All the pieces that you will need to glue together including the runtime, packaging, monitoring, tracing, etc. are there under the CNCF umbrella. Hopefully cloud providers will all rally behind these standards and focus collective efforts to maintain and improve them.
It seems like there are 2 growing and diverging groups in the Kubernetes community: Those who have no idea where to start, and those who have already moved on to newer things. Lots of new folks are just getting started thinking about running applications in containers or starting to use a cloud provider, and others have been using Kubernetes for years and ready to jump into Knative or start tackling different software problems entirely. I imagine this usually happens in any fast-moving community.
I am grateful to all of those people who worked to make the event happen. Thank you to the presenters, cooks, cleaning staff, folks who worked at information desks, drivers, vendors, volunteers, and the organizers.
30 Dec 2018, 12:30
We’re a few days away from going to press, so I thought you might like to see
the up-to-date table of contents! If this whets your appetite for the book, why
not pre-order your copy of ‘Cloud Native DevOps with Kubernetes’ now?
13 Dec 2018, 12:00
Applications with databases usually need to run migration tasks as part of their deployment processes. For example, in a Rails application this is done with the
rake db:migrate command. Other frameworks have similar commands to manage the migrations. Typically, running migrations is one of the first steps in a deploy when upgrading the application to a new version. In a CI/CD pipeline for deploying an application running in Kubernetes there are a couple of options for how to handle migrations. In this post we’ll discuss two of them:
- Running migrations from your CI/CD tool
- Using a Kubernetes Job
This option involves adding a step to your CI/CD pipeline to run the migrations as part of a deploy. A common CI/CD workflow in Kubernetes looks something like this:
- Push code to source control
- Build a container with the new code
- Run the test suite
- Publish the container to a container registry
- Deploy the new container to a Kubernetes cluster with
kubectl apply… or
This last step is where the migration needs to happen. Jenkins, Drone, GitLab CI, or whatever CI/CD tool you use could migrate the database before setting a new version of your application to run. For example, you could add a step in the pipeline to run something like
docker run <your-app-container>:<your-newly-built-container-tag> <your-db-migrate-command>....
The advantage to this method is that if the migration fails, the whole deployment fails and you can see right away that the deploy did not completely succeed. However, in order for this to be possible, your CI/CD tooling needs access to your application’s database, along with the application’s database credentials. This may not be possible if your CI/CD pipeline tools run in an isolated or separate environment from your application. For example, if you are using a SaaS CI/CD tool, network access to your application’s database may not be an option.