stevenacreman

https://kubedex.com/ - I write about playing with Kubernetes

When I was young, before my first IT job, I used to love playing with Xen, distcc and watching my desktop pc scroll compiler output for days rebuilding my X-Windows. I fell in love with the idea of Beowulf clusters and Gestalt computing.

Kubernetes combines a lot of all of that stuff so I'm very lucky to both work and spend my free time on what would be a hobby anyway.

I keep a Google sheet updated with feature differences between LinkerD, LinkerD2, Consul Connect and Istio.

https://docs.google.com/spreadsheets/d/1OBaKrwR030G39i0n_47i...

From my own experience I've had some great success with LinkerD in the past on Mesos DC/OS.

Since moving companies, and switching to Kubernetes, we've yet to deploy any service mesh into production.

The blog from Jerome highlights many of the benefits already.

From my perspective the bigs ones in the past were:

    - Tracing (with Zipkin)
    - Retries which removed or fixed dodgy app reconnect logic
    - Time series metrics in LinkerDViz showing realtime rates and latency and errors between services

The reason we haven't used any service mesh at my current company is mostly based on stability concerns.

Istio gets all of the cool press attention and blogs written about it. Yet, you also read a lot of warnings about it always being 6 months away from being really robust. Even at version 1 we read some horror stories about obscure bugs showing up in fairly standard use cases.

Connectivity between services is too scary to gamble on. It's a similar deal with CNI (we're still on Calico despite arguably cooler stuff being out there) and Ingresses (still on ingress-nginx).

AWS have a service mesh that is probably going to be the one we trial next at work.

Improved observability and retries would definitely be of benefit on our current platform. Another driving factor is also our security team wanting mutual TLS between services.

I personally don't really understand this approach. In fact, this approach annoys me.

In this situation I feel like the product has already wasted my time and now people are contacting me to waste more of my time.

The blog is really detailed and includes screenshots. You could fix the obvious issues and then follow up with an update once it's released.

This is true of all of the services I've tried across Azure, AWS and Google cloud.

Microsoft are always last place in terms of performance and reliability.

For Kubernetes I actually keep track of exactly how bad they are with an automated testing tool.

Results of the last test are here: https://kubedex.com/is-azure-kubernetes-aks-any-less-terribl...

I've complained about UX before in the context of the Azure portal being, in my opinion, terrible. But that's subjective and I respect that others may like it, although not sure how they do.

Has anyone tried signing up for remote.com?

I just did and they wanted an email for jobs which I thought was OK.

Then I tried to add a profile and it prompted me to export my entire LinkedIn history. It says to export "The Works".

My LinkedIn is quite massive and I've checked the export for "The Works" includes my entire contact list.

That's pretty shady. Why not just import my profile? There's an option to export only profile data. How many people will follow these default instructions and upload everything they have ever done on LinkedIn?

It's good to see a project focussing on production-grade databases on Kubernetes. Particularly the production grade part.

There are 33 open source operators for managing databases on Kubernetes. Out of that list only 3 claim to be production ready.

Out of 126 Operators that I've looked into the vast majority are abandoned and unfinished. Most state the project status as Alpha in the readme.

Kubedb itself has a version number of 0.8.0 for the operator and very low version numbers for the databases. For example version 0.2.0 for Redis.

Version numbers can mean anything but they are usually a good indicator of what the project owner thinks the status is.

It would be cool to see a break-down of status and expected dates for milestones for Kubedb.

For anyone interested in browsing other Operators I keep a table updated half way down this blog post.

https://kubedex.com/operators/

The project statuses come directly from what the authors have stated. Many beta status projects are being used in production.

Just wanted to clarify that Kubernetes was still scheduling containers. Even if VM's are being used to isolate them.

It's not all or nothing either. Containerd will support running a mix of containers and kata-containers across workers.

For anyone interested in this topic I wrote about some other container runtimes here: https://kubedex.com/kubernetes-container-runtimes/

It's still containers. On a cloud provider the Kubernetes workers are VM's which orchestrate containers. With Kata Containers you're just spawning containers inside micro-vm's.

It's even worse than that.

Knative is really an alpha piece of software at version 0.2.2 for the serving component. Riff is also at 0.2.0. What do Pivotal plan to do if both implement breaking changes (extremely likely), maintain a fork?

The other issue is what value is this all really providing? Kubernetes provides a standard API that abstracts infrastructure and deployments.

The benefit that Lambda brings is very simply connecting together cloud services. None of these FaaS on Kubernetes products do that. For anyone interested I looked into the current landscape on Kubernetes and gave up since it's all pretty worthless. https://kubedex.com/serverless/

Added as the final column in this sheet.

https://docs.google.com/spreadsheets/d/1qCOlor16Wp5mHd6MQxB5...

As somebody who has created a product in the past and also reviewed quite a few I've given up doing performance comparisons. This is quite sad as comparisons help people save time and money and cut through the marketing which technical people hate.

Every time I've done a performance comparison an expert pops up and says the result is invalid because of X. It takes 10 seconds to write the comment but perhaps a few hours to redo the tests and update the blog contents.

The blogger doesn't want an inaccurate blog and the software authors don't want bad benchmarks left up which constantly crop up in search results. As a blogger you feel a little duty bound to work on updating a blog you know probably won't be re-read by the majority of people who have already opened it anyway.

My conclusion is that fault should fall on the side of the software developer in most cases. Having created a startup I understand the time pressures and motivations driving the roadmap. There is a natural tendency to work on the differentiators and high value complex features. Blogs like this should act as a reminder that there is massive value in prioritising sane defaults, tests, documentation and building logic into the application that makes incorrect settings that effect performance unlikely.

From reading this blog I get the sense the author is quite technical. A positive public relations move would be to spend your time replicating the results and then when the problem is found make it difficult for the next person to have the same issue. Preferably with logic in the software, but worst case scenario with some bold text towards the top of the readme so it's not buried somewhere obscure.

For those interested in a feature comparison I did one here:

https://kubedex.com/kubernetes-network-plugins/

With postage the item must fit into the container and not be over weight.

Airports have full body scanners. Surely these could be modified to determine if a person can fit into the container they purchased.

People are upvoting the title because I guess they agree to some extent.

It seems everyone starting an open source project nowadays needs to protect against the cloud providers.

The topic on here about the new CI tool from the creator of Ansible also had an element of this. But I actually quite liked his solution. He gives everything away for free and the source is open. You just cannot profit from his work unless you join a partner system.

Maybe I'm being naive but that seemed like it may work. Although not sure how you qualify not being used for commercial benefit if the software you're building with the CI tool produces a paid product. I think the software creator would only really enforce the license if you started a business up doing hosted CI with it or offering it as a cloud service.

That just means they excluded Google GKE, Microsoft AKS, Amazon EKS etc.. all of the public clouds.

I have another comparison sheet for those if anyone is interested.

https://docs.google.com/spreadsheets/d/1U0x4-NQegEPGM7eVTKJe...

The report is from Forrester. I hardly ever read them but Docker has it posted all over its website so I was curious.

Forrester and Gartner seem too high profile to be biased. This one isn't sponsored so the researchers will have had free reign over what was added. If Azure Stack is really in use by many companies I'd be surprised if they missed it.

Docker, as mentioned in the Forrester report is "Docker Enterprise 2.0" and as the text mentions it's a Kubernetes platform with Swarm and Kubernetes orchestrators.

AzureStack presumably runs AKS, the same as the Kubernetes service that runs in Azure, which is totally different.

The market size can't be attributed in any way to Azure Stack which is why I was surprised you mentioned it was heavily used. Gartner talks to a wide range of companies usually.

Regarding the claimed market presence of Azure Stack can you explain why it's not in the recent Forrester report?

https://reprints.forrester.com/#/assets/2/431/RES141562/repo...

I've been keeping track of the various Kubernetes services and agree the market is massively crowded right now. AWS, Google and Azure dominate the cloud market. IBM is a distant joint last place by most metrics.

OpenShift won't compete with the cloud offerings in the long run. Redhat are currently competing with On-Prem offerings and trying to make a case for 'hybrid'.

Even in this market OpenShift is competing against at least 15 alternatives. For anyone interested I've been crowd sourcing data for each and trying to work out key differentiators.

https://docs.google.com/spreadsheets/d/1nAgDxQZYeAMLwz8iI3_a...

OpenShift is definitely differentiated in terms of security. They also have network and storage features that are arguably valuable to enterprise customers.

Google GKE On-Prem is out soon. I never see Azure Stack mentioned so maybe Microsoft will look into a Docker acquisition to boost their enterprise footprint.

The cloud seems like the bigger growth area though so perhaps this On-Prem container platform land grab will be short lived.

Done. https://kubedex.com/project-dolos-testing-kubernetes-on-goog...