HN user

stevenacreman

268 karma
Posts26
Comments24
View on HN
kubedex.com 7y ago

A comparison of Kubernetes specific operating systems

stevenacreman
5pts0
kubedex.com 7y ago

7.5 tips to help you ace the Certified Kubernetes Administrator (CKA) exam

stevenacreman
3pts0
kubedex.com 7y ago

Is Azure Kubernetes (AKS) any less terrible?

stevenacreman
6pts0
kubedex.com 7y ago

90 Days of AWS EKS in Production

stevenacreman
5pts0
kubedex.com 7y ago

The Kubernetes Operator landscape

stevenacreman
4pts0
kubedex.com 7y ago

A comparison of Kubernetes container runtimes

stevenacreman
4pts0
kubedex.com 7y ago

A comparison of Kubernetes network plugins

stevenacreman
3pts0
kubedex.com 7y ago

Serverless on Kubernetes

stevenacreman
4pts0
kubedex.com 7y ago

Google GKE vs. Azure AKS – Automation and Reliability

stevenacreman
5pts1
kubedex.com 7y ago

Creating a good technical resume

stevenacreman
2pts0
kubedex.com 7y ago

Time Series vs. Logging vs. Tracing

stevenacreman
3pts1
kubedex.com 7y ago

A comparison of Linux base images

stevenacreman
10pts0
kubedex.com 7y ago

Small Docker images to use instead of Alpine

stevenacreman
3pts0
kubedex.com 7y ago

Kubernetes on Google, Azure and AWS Compared

stevenacreman
228pts120
kubedex.com 7y ago

Alpine containers in production? Possibly not a good idea

stevenacreman
3pts0
kubedex.com 7y ago

Container vulnerability scanning options compared with extremely poor results

stevenacreman
4pts0
kubedex.com 7y ago

Autoscaling nodes and pods on Kubernetes

stevenacreman
2pts0
kubedex.com 7y ago

Linkerd2 went GA. How does it compare to Istio and Consul?

stevenacreman
4pts0
kubedex.com 7y ago

Kubernetes, Helm, Prometheus

stevenacreman
1pts0
kubedex.com 7y ago

A comparison of all Kubernetes ingresses

stevenacreman
2pts0
kubedex.com 7y ago

Kubernetes service mesh showdown: Istio vs. Linkerd vs. linkerd2 vs. Consul

stevenacreman
2pts0
kubedex.com 7y ago

Show HN: Discover, Compare and Share Kubernetes Applications

stevenacreman
2pts0
kubedex.com 7y ago

A Top10 list of Kubernetes applications

stevenacreman
2pts0
www.linkedin.com 7y ago

Monorepo and multi repo: tips for those who are multi

stevenacreman
3pts0
www.linkedin.com 8y ago

Software craftsmanship in Dubai

stevenacreman
1pts0
www.linkedin.com 8y ago

Monitoring Kubernetes with Prometheus (outside the cluster)

stevenacreman
2pts0

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.

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/

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.

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.

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.

The spreadsheet linked in the blog is almost entirely factual and I made quite a point of adding comments with links to various sources.

If you want to be pedantic about the sentence you took offense at it is actually true. There are operations that can only ber performed using Powershell. People have given examples in this thread. But that isn't the point.

What I should have written for that part was that most people google for solutions. I've done this in the past on Azure and you get a random assortment of answers. Click here, Powershell this there, do whatever. It's disjointed and takes you out of mental context. I could update the blog with more clarity but I don't think anyone will change their mind.

I've used Azure, GKE, AWS. It was played down a little in the blog, but I have used the non AKS parts of Azure pretty extensively. Have you tried GKE? My suspicion is that you've been stuck in a Microsoft world for a while.

Not everyone is a paid shill but some people have a lot invested in the Microsoft ecosystem and I can only assume that's the reason for some of the comments here. I do 100% believe the Microsoft PR team has posted in here at least once though :)

Author here.

I can say that this has pretty much gone as I'd expected.

Microsoft have 80,000+ developers. Their partner ecosystem is absolutely massive. I've watched them hire hundreds of developer advocates that talk at events. It's therefore quite hard to write anything online that's critical without at least half of the comments coming from a biased source.

It is interesting to see the gap between views in the comments here.

Edit: I watch this comment go up and down a lot as the vote battle between those with an agenda and those without click against each other.

Weirdly, I did criticise AWS a bit for their EKS offering in the blog but I've not had anywhere near the toxicity from people about that.

Hi, there's a comment on the cross region networking for GKE.

"Each cluster receiving an IP range for nodes and another for the containers inside, which are directly routable across your private network, other clusters, and regions."

AWS and Azure don't have a flat global network. You have to setup VPN's and complicated overlay networks.