Live data from Hacker News

Do I Need Kubernetes?

mbird.biz

81–90 of 180 posts

Re: Do I Need Kubernetes?

#81

Earlier quoted context omitted.

I’m not avidly opposed to k8s by any means, but you can get these same properties from any of a variety of easier-to-use schedulers such as Fargate, Heroku, or even EC2 autoscaling groups. Of course, there are probably Kubernetes distributions that lower the threshold of using Kubernetes (and if there aren’t, there really should be) by providing solutions for logging, monitoring, certificate management, Functions (a…

The problem with your approach is that you're firmly locked in to the vendor. And in the case of Fargate, Heroku etc you're paying significantly more than if you had made use of Spot instances or shopped around for a cheaper vendor.

Heroku costs about a nickel an hour per server, yeah? A dollar a day?

So I'll worry about that price when I get to at least 10 servers

Re: Do I Need Kubernetes?

#82
Remember Greenspun's 10th rule?

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Well, there's a kubernetes version, which is that any sufficiently advanced deployment system will ultimately be half assed version of kubernetes.

Re: Do I Need Kubernetes?

#83

Earlier quoted context omitted.

I’m not avidly opposed to k8s by any means, but you can get these same properties from any of a variety of easier-to-use schedulers such as Fargate, Heroku, or even EC2 autoscaling groups. Of course, there are probably Kubernetes distributions that lower the threshold of using Kubernetes (and if there aren’t, there really should be) by providing solutions for logging, monitoring, certificate management, Functions (a…

The problem with your approach is that you're firmly locked in to the vendor. And in the case of Fargate, Heroku etc you're paying significantly more than if you had made use of Spot instances or shopped around for a cheaper vendor.

Vendor lock-in concerns are overblown. Unless there’s a real chance you’ll need to pick up and move, don’t worry about it. Your savings by not building/operating everything yourself will dwarf other costs (unless your business has huge scale and you have a world class internal cloud capability which you probably don’t and if you do, you can probably just negotiate a better deal from a cloud provider a la Netflix and Amazon). To that end, you only “save money” by managing everything yourself if you write off the cost of engineering time and talent, which is to say you lose money by doing it yourself because you don’t have the scale or talent to compete with Amazon even with their markup (certainly not when you account for opportunity cost).

Re: Do I Need Kubernetes?

#84

> To make a cluster useful for the average workload a menagerie of add-ons will be required. Some of them almost everyone uses, others are somewhat niche. This is the concern I have with k8s. All this complexity introduces operational and security concerns, while adding more work to do before you can just deploy business value (compared to launching on standard auto-scaling cloud instances)

It's the classic trade-off of cost vs benefit. In places I've worked, the benefit has been worth it. The kind of add-ons mentioned in the article are in keeping with the decision for the orchestrator (which is already complex) not trying to do absolutely everything. I feel that is a good thing.

It's kind of like an API gateway with traditional microservice instances. If you have DNS and load balancers pushing requests directly to your services, you might wonder why you would ever need such a thing. Until you do.

Re: Do I Need Kubernetes?

#85

Earlier quoted context omitted.

The problem with your approach is that you're firmly locked in to the vendor. And in the case of Fargate, Heroku etc you're paying significantly more than if you had made use of Spot instances or shopped around for a cheaper vendor.

Vendor lock-in concerns are overblown. Unless there’s a real chance you’ll need to pick up and move, don’t worry about it. Your savings by not building/operating everything yourself will dwarf other costs (unless your business has huge scale and you have a world class internal cloud capability which you probably don’t and if you do, you can probably just negotiate a better deal from a cloud provider a la Netflix and…

Nobody is saying you have to build everything yourself.

But you can just use cloud providers for their hardware and not needlessly tie yourself to their software. For example you can use a managed K8s solution like EKS but then have all of your monitoring, logging, databases etc all be self-hosted.

And it's not just about cost but also about being able to take advantage of other cloud provider's unique strengths or being truly resilient to outages.

Re: Do I Need Kubernetes?

#86

Remember Greenspun's 10th rule? "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Well, there's a kubernetes version, which is that any sufficiently advanced deployment system will ultimately be half assed version of kubernetes.

Including Kubernetes itself!

Re: Do I Need Kubernetes?

#87
post #6

> Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state. I think this is the key take away for many startups. Get it so you: 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and…

> people were amazed by the productivity gains Yeah, docker compose is great for running distributed apps locally when everything “just works”. The problem is that it also impedes development when the compose setup isn’t fully optimized. I work on dockerized rails apps, and whenever a new dependency is added, it can take 15 minutes to rebuild the image, which completely breaks my flow. Docker also creates a ton of da…

If I understood correctly, this means that every time you add a new dependency, it takes 15 minutes to rebuild the first time you `docker-compose up` right?

I assume this is due to docker downloading the related image and running the container.

If this is the case, isn't this orders of magnitude faster than adding the dependency manually. And aren't the gains are even more significant when we factor the fact that most of the cases dev and prod environments are identical? Or am I missing something?

Re: Do I Need Kubernetes?

#89

Earlier quoted context omitted.

Dont these issues also apply to the docker-compose alternative? I'm recommending make as "the one tool" to use for all of your teams apps. No matter what app they work on, everything is setup with `make bootstrap` and everything is run with `make up`. Everything is deployed with `make deploy`. They dont need to understand the _how_, only the _what_.

No, other tools do not suffer from what makes make complex. Make is "hard" because of a few things: 1. The syntax is very complex 2. It's just a wrapper around shell command execution 3. There's no single standard everyone fully implements If I implemented a makefile then I'd have to make sure it's compatible with MacOS and GNU Make. The syntax for make files and target deps are also very complex "Do I want to use %…

> The syntax for make files and target deps are also very complex "Do I want to use % or $ or @?"

How is this any more complex than any programming language? Take javascript. Do I want to use =, ==, or ===?

> I cannot test if my Makefile will run on a developer's mac if I don't have a mac myself and even then it's a crap shoot (do they have homebrew? is their PATH correct? etc).

Containers suffer from these kinds of problems as well. For example, if your ip tables are not set up just so, you get no network access from inside your container.

Re: Do I Need Kubernetes?

#90

Earlier quoted context omitted.

Vendor lock-in concerns are overblown. Unless there’s a real chance you’ll need to pick up and move, don’t worry about it. Your savings by not building/operating everything yourself will dwarf other costs (unless your business has huge scale and you have a world class internal cloud capability which you probably don’t and if you do, you can probably just negotiate a better deal from a cloud provider a la Netflix and…

Nobody is saying you have to build everything yourself. But you can just use cloud providers for their hardware and not needlessly tie yourself to their software. For example you can use a managed K8s solution like EKS but then have all of your monitoring, logging, databases etc all be self-hosted. And it's not just about cost but also about being able to take advantage of other cloud provider's unique strengths or b…

The same arguments apply to hardware and software. Cloud providers’ core competency is cloud infrastructure and services and they have the scale to economize their offerings. Your business very likely can’t compete with them, so to the extent that you’re owning things that cloud providers could sell you, you’re throwing away money and that figure very likely dwarfs the risk adjusted cost of maybe having to migrate to another provider one day. (Of course, there are services that are overpriced here and there, but the general principle holds).
Post reply on HN