Privacy

I usually am very open to new technology, even at the cost of some privacy. For example, my home is as smart as I am able to afford it; and if Alexa listens in to conversations, I am generally not too bothered by it, especially since I am sniffing the traffic between my Echo and my router, and generally and on the surface of it, can confirm what Amazon claims with regards to when data is transmitted to the cloud.

But more recently I have taken another look at some of the free services I am using. Gmail especially; and I am not very fond of what I discovered. Turns out, if you don't have to pay for it, you are the product, and while that's been subconsciously obvious to me for a while, I refrained from doing anything about it. Until I discovered ProtonMail and ProtonVPN.

Some time ago, I switched from WhatsApp to Threema, a secure alternative (although I have to say, I'd rather see this fully released as open-source). But I liked the story of how this Swiss company, with the correspondingly strict privacy laws, and their use of end-to-end encryption, personal verification of contact identities, and so forth, is able to provide not only better security, but first and foremost, privacy. Similarly, ProtonMail offers complete privacy to its users, and while there is a free tier, most of the functionality is restricted to their "Plus" offering. If you get it, you also receive a discount on their VPN connectivity. What I like about them is their focus on privacy, without compromising on functionality. I use a PGP key for work, and I was able to integrate it with ProtonMail without a hitch. I love the fact that my emails are stored encrypted and that not even ProtonMail employees can access my data.

Kubernetes is a feature not a product: SuSE drops out of OpenStack

SuSE discontinues OpenStack

It's interesting that SuSE decided to get out of the OpenStack business. However, I disagree that they do so because Kubernetes eats its lunch. The notion that Kubernetes would somehow replace OpenStack is comparing apples to oranges, or in this case, comparing a feature with a product.

The ability to manage workloads is a completely different use case than the ability to manage infrastructure. It is no wonder Kubernetes has gotten the larger number of supporters because, simply, there's more developers compared to SREs.

Containers, much like VM images, application packages, or source code repositories, are artifacts that can be characterized by their ephemeral nature, and their delivery mechanism via an active publishing pipeline. They are inherently different to the host operating system, hypervisor management, network configuration or server security. In contrast, Kubernetes helps schedule and maintain a controlled set of containers across a compute cluster, and intersects with infrastructure only inasmuch it connects to software defined (or host-provided) storage.

I should probably point out that I do not consider this in any way shape or form a flaw of Kubernetes; in fact, I would argue that Kubernetes should stay away from infrastructure as much as possible, in order to focus on what it does best: coordinate containers, and interact with infrastructure as a service as a client, not a provider.

It is also true that of course almost anything can be done if one sets ones mind to it, and if you so desire, can make your Kubernetes look very much like an infrastructure management tool. But the argument that "design a tool to do one thing well" so absolutely not lead one to the natural conclusion that Kubernetes management should be done by adding the feature of Kubernetes cluster management to Kubernetes. It might be a great idea, and hey - it might even work, but to me, that argument is inherently flawed.

This is also not an apologist post for OpenStack. OpenStack is flawed, severely so, by its complexity, unnecessary performance issues, and multi-tenancy that ignores years of industry learnings around domains, RBAC and directory management such as with LDAP or AD. But, restricted to the core competency of what OpenStack is supposed to deliver - compute, network, storage, with a little bit of load balancing and DNS sprinkled in - one can't help but note that it does this remarkably well. The stable subset delivering this core functionality can be run, managed and upgraded with relative ease, won't interrupt network connectivity, and represents an excellent alternative to virtual machine management tools such as VMware.

In fact, when one considers that today's workloads should be cloud-native ... wait a second, isn't that what Kubernetes is supposed to deliver? Cloud native applications running containerized on an IaaS?

To me, running Kubernetes on OpenStack is a perfect use case, and a great alternative to proprietary systems. Why throw out the baby with the bathwater?