Our official whiteboard for blog posts, musings, and occasional swashbuckling.
Co-founder, CTO at TurnKey
I've been a co-Founder and CTO of a number of startups. Currently, I help software product companies build Yourshore teams in Latin America and Eastern Europe.
👍 Rating — 5 (2 votes)
Many product managers have two recurring nightmares. The first is that the coffee in the break room is decaf. The second is being stopped in the hallway by a senior executive with a question about a certain piece of technology and not having a ready answer. Kubernetes is one such technology since it is mainstream enough to show up occasionally in popular media but geeky enough to feel inaccessible to most mortals.
Thankfully we are here to help (at least with Kubernetes—nothing we can do about the blasphemy that is decaf coffee). In order to understand what Kubernetes is all about and why it’s so special, we have to first start with three concepts that have gained popularity over the past few years:
Let’s take each in turn.
As it relates to microservices, you might have heard another term thrown about in your product development meetings: “monolith.” Building a monolith was the old way of making software applications; think of it like a Swiss Army knife that has all its functionality in one place. The problem with the Swiss Army knife approach is that each function in the “monolith” is never as good when compared to a stand alone application for that function. In other words, the screwdriver embedded in the Swiss Army knife is not as good as a regular screwdriver.
And there is one other glaring problem: it’s hard to fix. If you need to repair the screwdriver in the Swiss Army knife, you have to take apart the whole contraption and then struggle putting it all back together.
Thankfully Microservices comes to the rescue to solve this problem. Microservices are more like individual power tools that share the same component. The battery that powers the jigsaw is the same as the battery that powers the drill. The tools are independent – and are maintained independently – but they follow the same set of principles so they can all work together in a Swiss Army knife way (but without the downsides).
So in sum: the main feature of microservices is that they are hosted separately and usually interact with each other through APIs.
Keep that in your back pocket, along with a real Swiss Army knife just in case you get lost in a forest.
Containers solve a different problem from Microservices. Containers are all about automating the software release process. But to see why containers are awesome, we need to go back to the standard for doing releases before their invention.
The old way to do a release – which doesn’t really have a fancy name though most folks refer to it as a “manual release process”– worked liked this: a server hosted your application and when you wanted to release an update, you would update the individual files on said server and run some scripts. In metaphorical terms, it’s like opening up a computer each time you wanted to upgrade its memory.
This led to all sorts of things breaking in the process so some brilliant engineers tried to automate this process instead. They came up with the ingenious idea that rather than update the memory in one machine, you can release a “container,” which is the whole machine with the upgrade baked in. This was possible only with the advent of cloud computing; you couldn’t upgrade the physical hardware each time, but once machines became virtual, you actually could.
This clever engineering trick brought tremendous advantages because now you could release a copy of the machine, test it, and – if it worked – release an exact copy without worrying that something would break.
Editor’s note: I wish I was smart enough to come up with that.
Orchestration engines were created to help solve two key issues that emerged with the rise of containers. Once developers could release things that are in essence virtual machines, they needed to:
This is what great orchestration tools do (there are several of these engines but Kubernetes is the most popular by far). With Kubernetes you can spin up as many containers as you want when demand goes up, and spin them down when load reduces. This saves a ton of cost.
And Kubernetes can be installed on any cloud so that your containers can work without having to worry about compatibility. This removes your dependence on any one cloud and allows you to create truly resilient applications.
So now you are a true expert in all things Kubernetes. Use it to both eliminate the bad dreams and impress your friends at the next cocktail party (everyone loves talking about orchestration engines in the cloud!).
Still got questions about how to effectively deploy Kubernetes? We are always here to help at email@example.com or 310-699-6884.
Tailor made solutions built around your needs
Get handpicked, hyper talented developers that are always a perfect fit.
Here are recent articles about other exciting tech topics!
MLOps vs AIOps: Exploring the Difference
Unveiling the Future: Understanding HR Transformation in Tech
16 Web Developer Portfolios to Inspire You in 2023
Difference Between Web 1.0, Web 2.0, and Web 3.0