This week Sid Sijbrandij, Co-founder and CEO of GitLab, is back talking with Adam about all the details of their massive IPO last October 2021. To set the stage, this episode was recorded on Feb 1, 2022. During the show Adam mentioned they IPO’d at a $13B market cap, but they actually ended their opening day at approximately $15B. That’s a massive win for open source, GitLab, Sid, and the rest of the team. For loyal listeners you know we’ve had Sid on this show before, so of course we had to get him back on the show post-IPO to get all the details of this new journey.

Today we talk to Mark Ericksen about all the things that we could be doing on the new platform - this is a follow-up to episode 50.

Mark specialises in Elixir, he hosts the Thinking Elixir podcast, and he also helps make Fly.io the best place to run Phoenix apps, such as changelog.com. In the interest of holding our new platform right, we thought that it would be a great idea to talk to someone that does this all day, every day, for many years now.

We touch up on how to run database migrations safely, and how to upgrade our application config to the latest Phoenix version. We also talked about some of the more advanced platform features that we may want to start leveraging, like the multi-region PostgreSQL.

This is our 5th Kaizen where we talk about the next improvement to changelog.com: we are now running on Fly.io and our PostgreSQL is managed. This is a migration that many were curious about, including Simmy de Klerk, the person that requested this episode.

After migrating all our media files to AWS S3 (check episode 40), we thought that this part was going to be easy. Plan met reality. Pull request 407 has all the details.

We want to emphasise the type of partner relationships that we seek at Changelog & why they are important to us, as well as to our listeners. Honeycomb & Fly embody the principles that we care about, and Gerhard thinks that we are currently missing a Kubernetes partner.

We all hear a lot about MLOps these days, but where does MLOps end and DevOps begin? Our friend Luis from OctoML joins us in this episode to discuss treating AI/ML models as regular software components (once they are trained and ready for deployment). We get into topics including optimization on various kinds of hardware and deployment of models at the edge.

Nice to see some efforts around standardizing MLOps. Here’s their high-level selling points:

• 📦 Docker containers without the pain
• 🤬️ No more CUDA hell
• ✅ Define the inputs and outputs for your model with standard Python
• 🎁Automatic HTTP prediction server
• 🥞 Automatic queue worker
• ☁️ Cloud storage
• 🚀 Ready for production

Alex Sims, a Senior Software Engineer at James & James, an eCommerce fulfilment company, reached out to us about the Kaizen story of the third-party logistics (3PL) platform that he has been involved with for several years now.

The system delivered 16 millions of orders in 10 years, and 4.5 million in the last year alone. All the numbers are going up, and there is only so much that a single PHP monolith deployed as VM images can handle. So how do you even start thinking about the architectural improvements, and inspire everyone involved to move towards better?

We encourage you to look at the architectural diagrams in the show notes, especially the 10 year roadmap, and ask Alex for a blog post follow-up. While today’s episode was a good conversation starter, there is a lot that we did not have time to cover.

Gergely Orosz did an excellent job detailing the ins & outs of Atlassian’s epic outage:

Hundreds of companies have no access to JIRA, Confluence and OpsGenie. What can engineering teams learn from the poor handling of this outage?

The TL;DR on the cause of the outage is a script that was supposed to “mark for deletion” some records also had “permanently delete” functionality and was run against a wrong list of IDs, improperly deleting 400 of their customers. Oh, and their backup restore process is really good at doing all customers, but not a subset. Ruh roh!

Lots to learn here, and Gergely puts a fine point on the biggest takeaways. A must-read!

In this episode we talk about launching Dagger with all four founders: Andrea, Eric, Sam & Solomon.

While you may remember Sam & Solomon from episode 23, this time we assembled all four superheroes in this story and went deeper, covering nearly three years of refinements, the launch, as well as the world-class team & community that is coming together to solve the next problem of shipping software. Container images and Kubernetes are great steps in the right direction, but now it’s time for the next leap into the future.

You can use Dagger to run your CI/CD pipelines locally, without needing to commit and push. You can also use Dagger as a Makefile alternative, which resonates with Gerhard, but go further and your perspective on documentation & automation may start shifting.

Gerhard believes that this is the Docker moment of CI/CD.

This episode was requested by Tyler Smith who feels that he may not need Kubernetes just yet. Tyler has a few questions about Docker & Docker Swarm, so Andrea Luzzardi, former Docker Swarm Lead, joins us today to answer them.

We talk about Docker Swarm beginnings, some of the challenges that it faced, and what Andrea’s recommendation is for Tyler’s journey with Docker Swarm.

After dedicating four years of his professional career to Docker Swarm, Andrea is the best person that Gerhard knows to talk about this subject. And guess what, the same thing happened now as it did at KubeCon 2015: Sam pointed to Andrea. It will all make sense in the first five minutes. This one is going to be fun!

After recording Ship It! #46, Nabeel Sulieman and Gerhard stuck around to pair on getting KCert (a simpler alternative to cert-manager) set up on our LKE infra. It works!

The Squeaky team goes from dev straight to prod (same here), but many people advocate for (and use) staging or other “pre-live” environments instead.

While there are obvious benefits to deploying to different environments, at Squeaky we’ve decided to take a different approach. We only have two environments: our laptops, and production. Once we merge into the main branch, it will be immediately deployed to production.

Perhaps that sounds unusual, but so far it’s outweighed the benefits of pre-live environments, and we believe it’s helping us to ship faster, and lower the number of issues on production. So, I thought I’d write this post to share why we think it works, and why you should consider it too.

Nabeel Sulieman, Senior Software Engineer at Vercel, talks about KCert, a simpler alternative to cert-manager that he built. Gerhard tried it out, and he thinks that Nabeel is onto something. If you want to see the video that they recorded, ping us on Twitter or Slack.

We love this story, especially the long-term approach of working on something that one truly believes in, and the only reason is because it’s fun. The world needs more people like Nabeel, and we hope that this episode inspires you to go all out, and do just that.

Lars Wikman reacts to Gerhard’s excellent conversation with Kelsey Hightower on Ship It!

So he essentially said, I’m interpreting here, that when it comes to deploying software to servers the documented manual steps for deploying something need to be the canonical reference. Then whether you build bash scripts, Ansible playbooks, Makefiles, Dockerfiles, Terraform, Kubernetes or something else to encode that procedure into something repeatable and scalable that’s a separate step. Having documented the process required to set it up means that there is an answer to the question: How do I get this running? An answer that doesn’t require you to parse the .yml files or grok Ansible roles and groups.

Lars springs forward from there with many thoughts of his own on the matter.

Pia Wiedermayer, Lead QA at Zühlke, is talking with Gerhard today about software quality. If the name sounds familiar, check out episode 28. Thank you Romano for the introduction 👋🏻

Do you remember the last time that you used an app, whether it was in the browser or on your mobile, and everything just worked? What about that intuitive feel, snappiness and you achieving the task that you intended to without feeling that you are fighting tech? Experiences like those take a lot of effort across multiple disciplines. They are designed, built and maintained over long periods of time. It all starts with people like Pia that really care about quality. It’s so much more than just automated testing…

Today’s conversation with Kelsey Hightower showed Gerhard what he was missing in his quest for automation and Kubernetes. The fundamentals that Kelsey shares will most certainly help you level up your game.

This is a follow-up to the last 45 seconds of the Kubernetes documentary.

Oh, and we finally cleared where we should run our changelog.com PostgreSQL database 🙂

In this week’s episode Cameron Dutro, a software engineer at GitHub, Ship It listener and someone with an extraordinary attention to detail, joins us to talk about Kuby, a convention-over-configuration approach to deploying Rails apps.

The question that we will be trying to answer is what happened to Rails Active Deployment. The path to that promise land is paved with good intentions, but it’s complicated.

Rich Burroughs:

When you hear the phrase “cloud native,” is Kubernetes the first thing that comes to your mind? It is for me, and I expect I’m not alone. Kubernetes is now the second-largest open source project after Linux, and it’s the big fish in the cloud native pond. But there are many other projects in the CNCF landscape and the broader cloud native community.

So, I thought I’d list some cloud native tools that can be very useful for teams that aren’t using Kubernetes or aren’t using it for every workload. Here are 7 of them that I like a lot.

If Rich’s name rings a bell, that’s because he was just on Ship It! last week. 😉

This week we have the pleasure of Rich Burroughs, Senior Developer Advocate at Loft Labs and host of the Kube Cuddle podcast.

We talk about multitenancy in Kubernetes and how to run Kubernetes in Kubernetes with vcluster. If you are using KiND, you will find this episode interesting, and maybe even helpful.

We also talk about the role that Kelsey Hightower played in Rich joining the CNCF ecosystem. The key take-away is that people make all the difference.

ADHD is something that Rich thinks about often. Gerhard was curious about the difference between ADHD and burnout, as well as this Twitter thread on re-reading sent emails.

In today’s episode, Gerhard is talking to Mauricio Salatino (@salaboy) about the Continuous Delivery for Kubernetes book that he is currently writing.

Mauricio is a Staff Engineer at VMware where he spends most of his time contributing to Knative, an open source platform for running serverless workloads on Kubernetes. Gerhard & Mauricio spent a few months in 2021 working on Knative Eventing, and they both appreciate shipping great software continuously. Mauricio helped ship Knative 1.0.

The from-monolith-to-k8s application used throughout this book has been a few years in the making. It doubles-up as a workshop-style guide for rearchitecting a Java monolith to a Cloud Native architecture running in Kubernetes.

We finally did it! All our static files are served from AWS S3. This is the most significant improvement to our app’s architecture in years, and now we have unlocked the next level: multi-cloud. We talk about that at length, and how it fits in our 2022 setup. The TL;DR is that changelog.com will fly, both literally and figuratively.

We also address Steve’s comment that he left on our previous Kaizen episode - thanks Steve!

Towards the end, we talk about Gerhard’s new beginnings at Dagger, where he gets to work with a world-class team and build the next-gen CI/CD. That’s right, Gerhard is now walking the Ship It talk all day, every day. If you want to watch him code live, you can do so every Thursday, in our weekly community session.

Kaizen!

This week we are talking to Robin Morero, the person behind fabled.se, a DevOps consultancy from Gothenburg, Sweden. Their motto is “move faster and prosper”, which Gerhard prefers to the initial “move fast and break things”.

Fabled works with startups primarily, and after 26 years, Robin has a few interesting insights to share. What do you think, are haunted codebases real? At what point do pull requests become harmful? What about k3s running on KVM as a simple starting point for production? If this reminds you of #7, and the follow-up YouTube stream with Lars, it’s no coincidence.

Gunnar Holwerda (Engineering Manager) and Tom Pansino (DevOps Team Lead) share with us a few stories about how the teams at opensesame.com manage AWS operational complexity. The first link in the episode show notes are the slides that Tom & Gunnar prepared for this conversation. Check them out as you hear us speak about the Inverse Conway Manoeuvre, and why you should always go for the bananas.

If you like this episode, and have a similar story to share, please reach out to us. We all love real-world stories that we can learn from, and perhaps contribute to.

MLOps is an increasingly popular topic that is no longer just a subset of DevOps. Go is a great choice for infrastructure. What role does Go play in MLOps?

Vincent Ambo –the person behind nixery.dev, tvl.fyi, and a former Google engineer– shares his take on monorepos, Nix, and fully declarative systems without any Flux, Argo or Kubernetes.

While the tooling is impressive, it’s the principles behind it that captivated Gerhard’s imagination. Vincent has a rather interesting take on the monorepository idea, including one change - one version - one deploy. There are a lot of interesting links in the show notes, including all the code that Vincent uses to manage infrastructure.

As a result of this conversation, Gerhard is running Nix on one of his Macs, and also started experimenting with his first NixOS production instance.

Gerhard loves simple ideas executed well, which is why he is excited to be speaking today with Ildar Iskhakov & Matvey Kukuy about their startup Amixr, a.k.a. Grafana OnCall.

Ildar & Matvey started with a simple idea and a simple stack - Django, Celery, RabbitMQ & MySQL - all running on Kubernetes. Because they kept their main thing their main thing, and kept improving it every day for a couple of years, now your on-call can be simple too.

This is another Big Tent philosophy story with a Black Swan moment towards the end.