Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're Leaving Kubernetes

gitpod.io

Post reply on HN
Print view View original

321–330 of 348 posts

Re: We're Leaving Kubernetes

#321

Post by chipdart »

therealdrag0 wrote: post #298
redman25 wrote: post #279

Earlier quoted context omitted.

Shouldn't all systems be tested end-to-end regardless of if they are microservices or not?

You don’t have to test them all end to end before merging a PR. You should have multiple stable pre prod environments for e2e testing. But if most changes fail e2e testing then your sdlc is broken before then and that should be fixed first. You need better designs and better collaboration and better local tests and code reviews.

> You don’t have to test them all end to end before merging a PR.

You have to test the changes you want to push. That's the whole basis of CI/CD. The question is at which stage are you ok with seeing your pipeline build.

If you accept that you can block your whole pipeline by merging a bad PR then that's ok.

In the meantime, it is customary to configure pipelines to run unit, integration tests, and sometimes even contract tests when creating a feature branch. Some platforms even provide high-level support for spinning up sandbox environment as part of their pipeline infrastructure.

Re: We're Leaving Kubernetes

#322

Post by chipdart »

flimsypremise wrote: post #169
animal_spirits wrote: post #163

Earlier quoted context omitted.

Invariably this is an ideal and does not match up in reality. I work at ~50 ish employee company and we have layers of dependencies between at least 6 or 7 various microservices. I can see this adding up in complexity as the product scales

If the microservice has dependencies on other services it is not a microservice.

> If the microservice has dependencies on other services it is not a microservice.

You should read up on microservices because that's definitely not what they are not anything resembling one of their traits.

Re: We're Leaving Kubernetes

#323

Post by chipdart »

Cthulhu_ wrote: post #243
blitzar wrote: post #214

Earlier quoted context omitted.

Connecting to a messaging queue or database count as a dependency? Why not break a microservice into a series of microservices, its microservices all the way down.

Only if you cannot change one service without changing the other simultaneously. It's fine to have evolving messages on the queue but they have to be backwards compatible with any existing subscribers, because you cannot expect all subscribers to update at the same time. Unless you have a distributed monolith in a monorepo, but at least be honest about it. Multiple services connecting to the same database has been co…

> Only if you cannot change one service without changing the other simultaneously.

Not true at all.

You're conflating the need for distributed transactions with the definition of microservices. That's not it.

> Multiple services connecting to the same database has been considered a bad idea for a long time.

Not the same thing at all. Microservices do have the database per service pattern, and even the database instance per service instance pattern, but shared database pattern is also something that exists in the real world. That's not what makes a microservice a microservice.

Re: We're Leaving Kubernetes

#324

Post by chipdart »

0xCMP wrote: post #254
wlll wrote: post #247

Earlier quoted context omitted.

That's ~12 people per microservice. I understand that it might be hard to boot and coordinate all that on each developers machine, and that local docker images/vms/whatever might not suit you, but is it possible that this is a problem of your companies own creation?

It's very likely not their decisions that lead to this, but their responsibility to improve velocity. Imagine the goal is to fix the problems (e.g. make it possible to run less of the services or something like that): How do you do that without first running all the services, making the proper changes, and then testing those changes? You need to be able to run all the services in that interim period. So, wouldn't it…

> How do you do that without first running all the services (...)

Why do you need to run all services in isolation to be able to troubleshoot and isolate a problem?

Re: We're Leaving Kubernetes

#325

Post by chipdart »

KronisLV wrote: post #240
skydhash wrote: post #170

Earlier quoted context omitted.

This + k8s magic that seem to make thing coupled tighter.

> This + k8s magic that seem to make thing coupled tighter. I think nobody really talks about this, but unless you have a docker-compose.yml that includes everything you need for local development, it's increasingly more likely that you'll end up coupling things to Kubernetes to such a degree that running without it (and its abstractions) will become more effort than a person can muster. So while people try to create…

> I think nobody really talks about this, but unless you have a docker-compose.yml that includes everything you need for local development (...)

Is this a problem?

I mean, in this scenario docker compose serves two main purposes: launch a few mock services, and configure those services according to your needs. This means configuring them to consume services already deployed to a cloud environment of your choice. This is something you control.

Then all that's left is the service (or set if services) you need to modify. You run those locally and configure them to consume a mix of the mocked services and the services deployed to a cloud environment.

> (...) it's increasingly more likely that you'll end up coupling things to Kubernetes to such a degree that running without it (and its abstractions) will become more effort than a person can muster.

That coupling can only happen if you intentionally add it yourself.

If you need to run your services in isolation, you will be more mindful of the need to not introduce that sort of coupling.

Re: We're Leaving Kubernetes

#326

Post by chipdart »

liveoneggs wrote: post #300
justinclift wrote: post #271

Earlier quoted context omitted.

One per microservice.

This is a bad idea. It defeats a major feature of the jvm.

> This is a bad idea.

Not really. It all depends on what are your needs.

> It defeats a major feature of the jvm.

You're confusing things. Just because Java addressed the deployability problem for Java applications before containerization was even a word, this does not mean that deploying a JVM per service is a bad idea. Just think about it for a second. Why do you need to deploy and scale services independently? Do you mention the JVM in your response? No.

Re: We're Leaving Kubernetes

#327

Post by chipdart »

sgarland wrote: post #261
chipdart wrote: post #196

Earlier quoted context omitted.

> People just straight-up don’t want to learn. (...) but IME the majority of people in tech are incurious. They want to do their job, and get paid. Reading man pages is sadly not in that list. I don't think you know what you're talking about. Just because you know people who do not want to waste their time on a set of unproductive chores you arbitrarily singled out, that does not mean they are against learning. Your…

> Do you actually believe that you build up enough knowledge on [distributed services] to become a professional in the field if you "straight-up don't want to learn"? Given the modern hiring practice of "can you pass Leetcode," and "can you memorize and regurgitate how to architect a link shortener," yes, yes I do. There is a vast difference between learning to pass a test, and learning because you're sincerely inter…

> Given the modern hiring practice of "can you pass Leetcode," and "can you memorize and regurgitate how to architect a link shortener," yes, yes I do.

You are contradicting yourself. If there's anything that requires studying and preparation, that's leetcode.

Also, "memorize and regurgitate how to architect a link shortener" is also known as learning and knowing the basics of systems architecture and software architecture. That's an odd way of criticising others for being more competent than you.

Re: We're Leaving Kubernetes

#328

Post by saghm »

sgarland wrote: post #261
chipdart wrote: post #196

Earlier quoted context omitted.

> People just straight-up don’t want to learn. (...) but IME the majority of people in tech are incurious. They want to do their job, and get paid. Reading man pages is sadly not in that list. I don't think you know what you're talking about. Just because you know people who do not want to waste their time on a set of unproductive chores you arbitrarily singled out, that does not mean they are against learning. Your…

> Do you actually believe that you build up enough knowledge on [distributed services] to become a professional in the field if you "straight-up don't want to learn"? Given the modern hiring practice of "can you pass Leetcode," and "can you memorize and regurgitate how to architect a link shortener," yes, yes I do. There is a vast difference between learning to pass a test, and learning because you're sincerely inter…

> Of course I think that the way I do things is mostly correct; otherwise why would I be doing them?

"My way is correct" doesn't necessarily imply "other ways are incorrect". Sometimes there's not one single solution to a problem. I love using Linux for my personal machines, but I don't think that people who don't are doing things wrong; they just have different preferences on how to do things, and that's fine.

Re: We're Leaving Kubernetes

#329

Post by Tainnor »

chipdart wrote: post #319
Tainnor wrote: post #307

Earlier quoted context omitted.

Your whole argument boils down to "don't write shit software" which yeah, fair, but in the real world, the company that you just joined has shit code that evolved over 10 years and has accumulated all sorts of legacy cruft. The idea that there is "absolutely no need to launch a set of ad-hoc self-contained services to run a service locally and work on it" just doesn't match the reality of most places I've worked at.…

> Your whole argument boils down to "don't write shit software" (...) No. My whole argument is open your eyes, and look at what you're doing. Make it make sense. Does it make sense to launch 50 instances locally to be able do work on a service? No. That's a stupid way of going about a problem. What would make sense? Launch the services you need to change, of course. Whatever you need to debug, that's what you need to…

Just FYI, you come across as extremely antagonistic in the way you're conveying your message. The underlying tone seems to be "you're stupid".

Re: We're Leaving Kubernetes

#330

Post by vrnvu »

mstrangfeld wrote: post #221
vrnvu wrote: post #200

For development, I made the switch to nix/flox and it’s been a game-changer.

How well does Flox work out of the box? I would really like to introduce Nix to the dev environments in my company but the struggle of maintaining nix files and flakes is too large. I've looked at DevBox and it looks quite accessible but Flox also looks like a nice way to sneak some of the Nix goodness into the company.

It works pretty well for most common packages, if a rare package/dependency fails is mostly nix problem to solve upstream.
Post reply on HN