Adventures in Kubernetes (Part 2)

Starting with an honest map

This is Part 2 in our Adventures in Kubernetes series. In the first article, we explained why you can’t take everything we say at face value. Now, we want to explore the hard job of not trusting your own plans at face value either.

The ecosystem around Kubernetes has always been daunting. When we started, there was Kubernetes, Helm, Docker, Vizceral, and a few other tools which gave us a small headache, and made us worry if we would be able to train enough people with all the required skills for all the different tools. Today, the CNCF has a cloudnative map, which can really cause a team to enter permanent analysis paralysis.

Thankfully, we have some tools available, which can help us to filter out irrelevant blogs, webinars or social media posts, depending on which situation you find yourself in. Before diving into the tools, let’s discuss why these tools are important, and why the cloudnative landscape is so crowded.

Whether you are looking at Netflix’s seven year journey to microservices, or Spotify’s ever evolving Agile organization, or Facebooks’ move fast and break stuff path to growth, the common thread between all these success stories is that each one did what was right for them. They evolved their practices over time, building on the complexity that came before, but also unafraid to “throw it all away”, and do the next best thing. Uber has a great talk about how they moved from a monorepo to many repos and then back to a monorepo again. Because at each step, that made sense for them.

At OnceHub, we went through a similar migration, from a centralized Jenkins job, to three Jenkins files per repo, and then scaled back to a few shared Jenkins files managed in a central repository. At each stage of our progress, we did what made sense for us, based on the engineering staff, tools, and workflows that were already in place. It might be tempting to think that we made mistakes, and we should have just started with our latest iteration, but that would be wrong.

Firstly, yes we made mistakes, important mistakes, and learning from those mistakes allowed us to make better decisions. Secondly, when we started out, we knew about all our options and the pros and cons of each architecture. What changed for us, wasn’t the vision of where we wanted to be, but rather the infrastructure that was in place which made the next step easier to accomplish.

This is why brutal and honest assessments of where you are now and where you want to be are so important. You can’t take shortcuts, because then you will just be doing cargo culting. It’s not enough to know where you want to go, you have to know the route and learn all the obstacles that must be overcome along the way. Prepare yourself for a multi-year journey, with the changing seasons along the way. Don’t neglect your winter jackets, just because you plan on arriving in the summer.

The cloudnative landscape is so crowded because the cloudnative landscape needs to support all companies in every stage of growth, with myriads of unique use cases and industry specific needs. Your job is to assess your current position, assess your end goal, and figure out the next best step. You don’t need to know all the steps, those will likely change, but you do need to know how to figure out the next best step, without leaping too far. Below are tools that we found useful.

1. Wardley Mapping: Wardley Mapping is a great tool for helping you discover and reflect on your actual position and strategy. This is best used for figuring out if you should build or buy, learn or outsource. There are also more advanced usages for this tool but it’s a good start.
2. Kent Beck’s 3X: Explore, Expand, and Extract, is a great tool for assessing what sort of work you need to do, and where you are in your growth curve cycle. It can help temper the urge to either over or under-engineer a solution.
3. Start with what you know: A common problem we have is sticking with what we know even when a better option is available, such as the proverbial cart with square wheels. This is often accompanied by the phrase, “No thanks, we are too busy.” However, on the flip side, it’s best to at least try using the tool you know, and understand where they fail. It’s ok to start your Kubernetes journey with some hand crafted, bespoke, scripts. Learn where your pain points are, and then, with that knowledge in hand, go out and find the tool designed to scratch that specific itch.
4. Learn the context of a ‘Best Practice’: The internet is filled with best practices, and in general, those best practices are in fact very good practices for the context in which they were derived. Learn from them. However, also learn about that context. A best practice for hosting a .Net application will not be the same best practice for a Rails or NodeJs application. What works for a small startup may not work for a company with 12 teams. Learning the context behind the slogan will equip you with the knowledge needed to make wise decisions.

Knowing where you are, where you are going, and learning from others about how they went through that journey is your best bet to having a successful cloudnative transformation. Kubernetes will likely be at the hub of that transformation, but it doesn’t necessarily have to be.

Stay tuned for the next blog in our series, where we address the concern that maybe Kubernetes offers more than you need right now, and why it’s still OK to get onboard with Captain Kube.

Avi Kessner, Software Architect

Avi started as a Flash Animator in 1999, moving into programming as Action Script evolved. He’s worked as a Software Architect at OnceHub since September 2019, where he focuses on Cloud Native Automated workflows and improving team practices. In his free time, he enjoys playing games, Dungeons & Dragons, Brazilian jujitsu, and historical European sword fighting.