Live data from Hacker News

Kubernetes Academy, a free product-agnostic education platform

kubernetes.academy

31–40 of 70 posts

Re: Kubernetes Academy, a free product-agnostic education platform

#31
post #28

Earlier quoted context omitted.

I think that you might be able to replace SQS specific queues with knative eventing. This should provide some insulation from aws specific services.

1) I don't use "work-in-progress" things in production (unless I own it and wrote it) and I have a hard time recommending others do so. 2) It's not just events in your application you have to worry about, but environmental stuff as well. SNS is the lingua franca of AWS and you've gotta put it somewhere, with reliability guarantees. That increases the amount of orchestration you have to do outside the safe-and-happy c…

So I have no doubt that SQS is more mature than knative. In my case I am developing an actual product IN k8s (with around 40 new CRDs) , so my goal is to use as much of the platform as possible (including istio and knative) and avoid cloud specific services.

The value with k8s is that you can abstract the underlying hardware by using only k8s objects.

Re: Kubernetes Academy, a free product-agnostic education platform

#32
post #28

Earlier quoted context omitted.

1) I don't use "work-in-progress" things in production (unless I own it and wrote it) and I have a hard time recommending others do so. 2) It's not just events in your application you have to worry about, but environmental stuff as well. SNS is the lingua franca of AWS and you've gotta put it somewhere, with reliability guarantees. That increases the amount of orchestration you have to do outside the safe-and-happy c…

So I have no doubt that SQS is more mature than knative. In my case I am developing an actual product IN k8s (with around 40 new CRDs) , so my goal is to use as much of the platform as possible (including istio and knative) and avoid cloud specific services. The value with k8s is that you can abstract the underlying hardware by using only k8s objects.

"The underlying hardware" has side effects. You can't exactly ignore them. And your cloud provider has non-substitutable stuff. Just as an example from my day today, by hewing to k8s you lose stuff like Athena and Glue for data analytics and ETL. I'm sure somebody out there would like to charge me 10x what AWS does to do a worse job of it inside of k8s, but no. So instead you get a Frankenstein of Terraform/Pulumi/CloudFormation and (poor and poorly expressive) k8s configuration and you've geometrically increased the complexity of your system, your failure cases, and the challenge of solving a problem when you're under the gun.

So your product might be fine, but everything that exists to feed it--be it monitoring and alerting or business analytics or security or even hands-on operational control surfaces--is going to be worse for it and create marginal drag every step of the way (either in terms of labor or money).

More and more (and your comments are reinforcing this position, TBH) I get the "it's a slick five-minute demo" argument out of k8s, much the same way that Docker brainwormed people long before it was good or useful. I have a cluster at home, and it's fine, but it's for play. I can't afford systemic drag from immature and possibly-wrong tech choices where I've gotta make money, though.

Re: Kubernetes Academy, a free product-agnostic education platform

#35
I wish more orgs would move over to orchestrating fleets of NixOS machines with NixOps. I can't overstate the benefits of truly immutable deployments. "Be this, machine, and be nothing else."

Feels like DevOps championed the lowest common denominator. I have to deal with containers flipping out all the time because the distros running inside these containers were never intended to be what we demand them to be with orchestration.

Re: Kubernetes Academy, a free product-agnostic education platform

#36
post #32

Earlier quoted context omitted.

So I have no doubt that SQS is more mature than knative. In my case I am developing an actual product IN k8s (with around 40 new CRDs) , so my goal is to use as much of the platform as possible (including istio and knative) and avoid cloud specific services. The value with k8s is that you can abstract the underlying hardware by using only k8s objects.

"The underlying hardware" has side effects. You can't exactly ignore them. And your cloud provider has non-substitutable stuff. Just as an example from my day today, by hewing to k8s you lose stuff like Athena and Glue for data analytics and ETL. I'm sure somebody out there would like to charge me 10x what AWS does to do a worse job of it inside of k8s, but no. So instead you get a Frankenstein of Terraform/Pulumi/Cl…

Thanks for the feedback. I do not think that k8s is bad bet long term as you paint it to be. Of course it is less mature than AWS. But the point is 5 years from now.

The problem with AWS is the price and the latency. Everything is fine until you get the bill. But by than you are completely locked to that architecture. The same apply to all the public cloud providers, not just AWS.

So as I see it, for new applications which are based on micro services, and want some day to become self managed, K8S is the only long term good bet.

Re: Kubernetes Academy, a free product-agnostic education platform

#37
post #3

Looks like this is all setup to get you to ultimately take some exam called the CKA

Hi! I manage Kubernetes Academy. We are not affiliated with the CKA Exam, and have no expectation for people to take it. Our team has received questions on how to best prepare for the exam, so we created a prep course. No strings attached.

Re: Kubernetes Academy, a free product-agnostic education platform

#39

I wish more orgs would move over to orchestrating fleets of NixOS machines with NixOps. I can't overstate the benefits of truly immutable deployments. "Be this, machine, and be nothing else." Feels like DevOps championed the lowest common denominator. I have to deal with containers flipping out all the time because the distros running inside these containers were never intended to be what we demand them to be with or…

Luckily, most of the time you should be using well-designed containers, or even build your own.

Except for 2 containers, I’m only using FROM: distroless, FROM: alpine and FROM: scratch. All using multi-stage builds and pretty much none of them running as root.

Post reply on HN