stevenacreman
Joined 9 years ago
Karma
268
Submissions
51
Member since
Aug 6
Recent submissions
Comment · 7 years ago
Comment · 7 years ago
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
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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?
Comment · 7 years ago
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.
Comment · 7 years ago
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/
Comment · 7 years ago
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.
Comment · 8 years ago
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/
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.