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.

The community is diverging

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.

• Justin

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?

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

CI/CD

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:

1. Push code to source control
2. Build a container with the new code
3. Run the test suite
4. Publish the container to a container registry
5. Deploy the new container to a Kubernetes cluster with kubectl apply… or helm upgrade…

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.

Kubernetes security is in the news at the moment, not necessarily in a good way. We thought it might be an appropriate time to share an interesting conversation we had recently with our friends Todd and Hannah at Threat Stack about Kubernetes, container security, and much more! We also had the fun of answering some questions from members of the audience.

Apart from hearing what we sound like, and in Justin’s case, look like, you’ll also hear a bit about how we came to write the ‘Cloud Native DevOps’ book, and exactly where we think security fits in to cloud native (spoiler: everywhere!)

Many thanks to DevOps.com for hosting the webcast, and to the magnificent Charlene O’Hanlon for being our moderator.

‘Cloud Native DevOps with Kubernetes’ is now available for pre-order! Despite what Amazon says, the first copies should be shipping in February, but make sure you get your order in now to beat the rush.

Pre-order ‘Cloud Native DevOps with Kubernetes’

Over the next couple of months we’ll be posting some teasers, previews, and exclusive extracts from the book here—so keep checking the blog!

Kubernetes is hard

If you’ve been hearing a lot about Kubernetes, and maybe read some things about it, or even tried to get started running something in Kubernetes, you may be feeling a little dispirited, confused, overwhelmed, puzzled, and possibly suffering the early symptoms of imposter syndrome. Well, don’t worry: it’s not just you.

Here’s the shocking truth that conference talks, promotional material, corporate press releases, and those other blogs won’t tell you:

Kubernetes is hard.

Of course, everyone who’s enthusiastic about Kubernetes wants to tell you how easy it is. “You can learn Kubernetes in a day!” Well, that would be quite a day. While Kubernetes is powerful and useful, it’s not necessarily so easy to get your head around, especially at first. It involves a lot of puzzling jargon and technical terms which don’t mean much to the newbie:

• Pod
• StatefulSet
• PersistentVolumeClaim
• Custom Resource Definition
• Ingress
• Deployment
• Horizontal Pod Autoscaler

… and so on. If you feel depressed and angry at the amount of new things Kubernetes requires you to learn, then we can absolutely relate to that. We’ve been through some of the same emotions on our Kubernetes journey, which is by no means complete, but the point of this blog is to hammer a few signposts into the swamp to help others feeling similarly lost.