Hard technology, to make life easy
We often talk about technology making life easier. Yet ironically, technology is getting more complex.
Take Kubernetes, for example.
Think back to the first time you were asked to create a managed Kubernetes cluster with your cloud provider. At what point in navigating the cloud console did you feel your own sense of hope die? So many APIs to enable! What do they all do?
It’s clear that Kubernetes wasn’t really built with humans in mind.
But funnily enough, for me (and I imagine for many engineers), complex technology has always been irresistible. I dive in to learning it.
Maybe that’s why today my own home is entirely managed by an HA Kubernetes cluster that automates home security, lighting, power management, HVAC and more. I embraced the complexity and used it to make my life easier.
Automation is not just for lazy people
I was once told that I have the three great virtues of a programmer: Laziness, Impatience and Hubris.
Because I’m lazy, I hate doing something tedious more than once. So I invest significant time in automating it, even though automating it may be difficult.
Because I’m impatient, I want my automations to work now, so I use tools that give me fast feedback, and I build things that will give faster feedback.
And because I have hubris, even though I may be lazy, I want people to look at my code with admiration, and I want my creations to be easy for others to understand and use.
Case in point: My first corporate job was in a bookkeeper's office where I was asked to do check reconciliation.
This was a monthly, week-long task to compare thousands of paper checks against a printed journal to see which cleared and which were outstanding.
I spent a couple weeks writing a program that allowed me to record check numbers in the bookkeeping system of checks that had cleared. The company was chasing me about starting the reconciliation process — I was risking my job apparently. But once the program was written, I could do the reconciliation in an hour, and so could anyone else. I kept my job.
Automating Kubernetes: not just a ‘nice to have’
You may have guessed where I’m going with this. To manage the literally supra-human complexities of Kubernetes, the repeated task of setting up and managing clusters should be automated.
Enter a variety of tools that can get you there.
Most of these tools are “as code” systems (which people prefer these days).
They tend to satisfy the laziness and some of the impatience part of the three great virtues, but rarely do they solve for hubris. They also fall short when it comes to Kubernetes fleet management, because they are ‘fire and forget’ systems.
The situation gets even more complicated when you have to deal with multiple environments, the various versions of backend configuration, modules, resource lifecycle, etc. Dealing with all of that will make your code hard to read. You’ll have built a swamp of Helm charts and YAML that your peers, boss and users will drown in.
No programming language or configuration system will prevent you from writing code that confuses people.
Then there are standalone management systems that sit outside the clusters they manage, pinging the API to find out the state of the cluster — when 95% of the time nothing has changed. This is quite a bit of busy work to discover nothing. And this busy work will hinder cluster performance.
So let’s talk about how to do Kubernetes fleet management in a way that is easy to use, works quickly and is something you would be proud to show off.
Fleet management for the people
We built Palette with a simple goal: to make complex Kubernetes fleet management easy, whether you have 1 cluster or 10,000. It’s a modern, cloud native platform that repeatably automates everything from the very design of a cluster to cluster creation and ongoing maintenance.
Designing a cluster
The ease of use starts with the design of a Kubernetes cluster. Palette provides an interactive visual diagram of the ‘payload’ of your cluster, called a cluster profile. It documents all the software that goes into your cluster, from the operating system, version of kubernetes, storage, networking and all of the other applications you want in this cluster. Importantly, this is a GUI — for normal people to use — but if you want to flatter your hubris there’s a CLI and API too.
Adding a new layer is as easy as choosing the desired software from a marketplace of applications in our approved repo, choosing a Helm chart, or providing your own manifest.
Even things such as changing the version of a layer is easy. Click on any layer and the configuration options for that layer allow you to change the version, install order and any of the install-time values you need.
Creating a cluster
The act of creating a cluster from that profile is just as easy.
So easy in fact that Palette can be set up to provide a self-service portal where non-expert users can choose their cloud provider, assign a cluster profile payload of software, and the process will begin.
Imagine how much easier it would be to use a system that allows you not only to choose from a variety of cloud providers, but allows you to avoid using their various consoles.
Now the magic happens
An important concept here is that when Palette creates a cluster, it installs an agent in that cluster which is responsible for managing that cluster.
The cluster profile is sent along with that agent, which then takes care of adding worker nodes, installing all the applications and all of the day to day monitoring and upkeep of the cluster.
This means that the main Palette instance is not bombarding clusters with API calls to check for state or change any individual settings. In fact the main Palette instance could go offline and the agent will still ensure that the cluster stays true to the blueprint.
This distributed architecture enables Palette to both manage thousands of clusters (a feat you can read about here) but also in a way that is fast and extremely reliable. Configuration drift is corrected from within each cluster, including recovering failed nodes. A cluster could go dark from the console and remain healthy and reliable.
What the magic enables: day 2 operations
Now that your clusters exist and run reliably, how do you manage them?
This is where we talk about ‘day 2 operations’: activities like upgrades, configuration changes, policy updates, etc.
These challenging tasks are made much easier thanks to the foundation of the cluster profile.
It’s just as easy to update a cluster profile as to create one, and since every cluster follows the profile that created it, those clusters can easily be triggered to pull a new version of the profile and apply any updates.
Remember the magic: the cluster is doing the updates itself based on that profile, without relying on an external brain. This makes the update process fast. The main console is not involved once the new profile is sent to the cluster, so it will remain responsive even in very large and demanding environments.
This all sounds easy
And it is. I’m constantly impressed by how much Palette does to make the life of the people behind the management of Kubernetes easy. I don’t know if our product team ever read “The Humane Interface” by Jef Raskin, but it sure looks like they did.
And when it comes to the three great virtues of a programmer, Palette satisfies those too.
- Laziness: You can focus on interesting problems, instead of manually applying software updates to a hundred clusters, or making your as-code system readable by others.
- Impatience: It’s quicker to adopt Palette than to roll your own automation, and from that point Palette makes cluster setup fast. Take a cluster profile and build out a full stack, fully ready-to-use cluster in record time.
- Hubris: This is a setup you can be proud of. It doesn’t get in your way or frustrate your colleagues. No need to duck your head in shame when asked to upgrade a component in 200 clusters by Tuesday.
Want to see it for yourself? We’d be glad to show you.