We’re currently at a great place when it comes to platform engineering.
You’ve architected the platform. Kubernetes runs reliably. The team ships fast.
You have observability setup, pipelines, you name it. You’ve put the hard work and life is good, congrats!
All the sudden you get a call from management. With all the AI fuzz, the company is going to start running some inferencing on some specialized hardware. You of course want to integrate it within what you built but it’s not easy. These devices require a special image built by the vendor that includes all the firmware. Working with it feels like you’re back in the system administration days. This is not going to be fun!
Or maybe your problem is a little bit different. It’s not shiny new tech that holds you back—it’s legacy systems. Let’s face it, there are some systems which will not be cloud-native ready any time soon if ever at all. If you’re setup is too fixed with cloud-native, every time you need to deal with one of these systems it will feel dreadful, but it doesn’t need to be.
Even those of you who are not dealing with the latest hardware or legacy applications, if business is going well eventually compliance will knock at your door and guess what? They are going to tell you that you use a certain licensed image as base for your platform or some other request that doesn’t exactly fit with the current solution you have.
Cloud-Native sprinted ahead, but legacy software, hardware, and compliance never got the memo
IMO the reason why we reached this situation is because we tend to be presented with one of two options. Either we go fully managed, or fully DIY and people rooting for each of these solutions will always talk badly about the other.
Think of fully managed as a very expensive TV dinner, which has a service catalog that even if most things are within the foods you eat, as soon as you want something different you are hit with a hard NO, we don’t do that. It doesn’t matter if you are intolerant, either you eat it, or pay for it and discard it. And let’s be honest, this is true, sometimes you could have just installed a package or do a little configuration to solve your problem but since it’s not offered within the service catalog, then you end up over-architecting around their catalog. Yes, you saved some time with this kind of solution, but for the amount of money you’re throwing at it the experience should be better.
The opposite can be said for the DIY solution. Imagine if every time you wanted to have dinner, you needed to go and catch a fish first. And let’s accept it, we engineers tend to want to solve everything ourselves because it’s fun. But sometimes we need to accept that the result, while it may work, ends up being that project that no one in the organization wants to touch because it looks like it was put together with duck tape so it ends up unmaintained and your manager is just waiting that the TV dinner company offers a managed solution for it to change it ASAP.
Here’s the truth: we’re working on a spectrum—convenience on one side, control on the other. There are scenarios where fully-managed and fully DIY are needed, but they should not be our default way of solving these problems. A system optimized for convenience should feel like going to a restaurant, where there’s still a list of pre-defined services but if you have an intolerance they don’t mind doing a change here and there for you. On the other hand, a system optimized for control, should be like going to the market, where you can still get very fresh products without requiring too much effort.
In the world of running platforms, I think this can be achieved with Special-Purpose Operating Systems, which are built to run kubernetes workloads. These are a bit like going to a Poke Bar, where you can choose from a few pre-defined bowls, but you can also build your own bowl according to your needs. Are you running on specialized hardware, no problem. Do you need a certain base OS to comply with licensees, you got it. No Kubernetes for legacy applications, it can be done!
So what’s the payoff? With a SPOS, you get convenience and control—natively.
Where’s the convenience of running a SPOS? These systems are immutable, secure and reliable by design. You don’t have to go and mess into the complexity of mounting different parts of your OS as read-only yourself, or implementing a solution for signing different parts of your system to be sure only your OS boots in a machine, you don’t want to come up with your own mechanism to perform upgrades.
You want a platform that just works
And how should these SPOS give you control? They should allow you to choose your own stack, be extensible and configurable. You don’t want to be stuck in a scenario where you have chosen a unique OS because of how fancy it is, just to realize that you will still have to run a Red Hat for a certain customer, or Ubuntu with the Nvidia board, or something else because then you’re now maintaining two completely different projects. It should allow you to choose and match.
So be careful
You don’t want to end up locked-in with a vendor!
Remember that open-source is not enough to not end up locked-in, the solution you choose needs to play well with others.
If you want a solution that is well balanced between convenience and control, you should check out Kairos. It comes full of features like:
- Immutable design
- A/B atomic upgrades
- Trusted Boot
- Integrated mesh networking
- Choose a Linux distro
- Choose a K8s distro
- Container-based and extensible
- Cloud-Init-style configuration
- Cloud Images support
- RPi & Nvidia board support
And it’s fully open-sourced and part of the CNCF as one of its Sandbox Projects. There’s no freemium, you get access to all code and features.
Kairos is not just good in theory, it’s also been battle tested. Some of the places running Kairos are:
- Data Centers
- Smart Farms (drones)
- Hospitals (compliance)
- Dental Clinics
- Gas Stations (edge)
- Schools (teaching networking)
- Home labs
And more! One of my favorites is the DeEEP device by the guys at DeEEP.network. This is a node you purchase and run from home or wherever you want to in order to mine and run web3 applications within their own protocol. As you can imagine, giving access to such network requires a lot of confidence that the device will not be tampered. A hacker could just buy one of their devices and try to modify the OS to hack the entire network. Thankfully, the DeEEP device is running Kairos’ Trusted Boot underneath making it impossible to put any other OS or change the underlying OS without the right keys.
Here’s a quick demo of the new Kairos Factory Web UI. It’s still in heavy development but you will find it’s the simplest way to build your immutable images.
Obviusly, once you’re in the flow, you don’t want to build the images manually but make it part of your deployment pipelines. This is possible using the AuroraBoot CLI, you can find examples of how we build all our images within our main repository workflows directory
As you’ve seen, Kairos strikes the right balance between control and convenience—without the headaches.
So what are you waiting for? Head over to kairos.io and start building today.
Questions? Ideas? Just hit the “Reply by Email” button and reach out—I’d love to hear from you.
Reply by Email