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

311–320 of 348 posts

Re: We're Leaving Kubernetes

#311

Post by pxc »

sgarland wrote: post #135
nixdev wrote: post #86

Earlier quoted context omitted.

> Personally - just let the developer own the machine they use for development. Overall I agree with you that this is how it should be, but as DevOps working with so many development teams, I can tell you that too many developers know a language or two but beyond that barely know how to use a computer. Most developers (yes even most of the ones in Silicon Valley or the larger Bay Area) with Macbooks will smile and no…

This is an unpopular take, but entirely true. Skilled at a programming language, other than maybe C, does not in any way translate to general skill with system administration, or even knowing how to correctly operate a computer. I once had to explain to a dev that their Mac was out of disk space because a. They had never removed dangling containers or old image versions b. They had never emptied the Trash.

Unpopular take? I thought it was common knowledge that computer operation and computer programming involve distinct (if overlapping) skillsets.

Re: We're Leaving Kubernetes

#313

Post by lmm »

0xbadcafebee wrote: post #296
lmm wrote: post #234

Earlier quoted context omitted.

> Most teams/products I have been involved in, the stack always grows to the point that a dev can no longer test it on their own machine, regardless of how big the machine is. It doesn't have to be like that. I've worked on a 10MLOC codebase with 500+ committers - all perfectly runnable locally, on admittedly slightly beefy dev machines. It's true that systems will grow without limit unless some force exists to count…

It depends on the application. I've worked at places where the main application being written needs 128GB to run. Another where it's computationally intense and will take hours for a single run on anything but the most massive machines. Another where the dataset is huge and simply being remote makes the bandwidth requirements untenable unless you live across from a data center. I've seen teams just accept their workf…

> Remote dev gives you as beefy a machine as you want, with the fastest network and lowest bandwidth.

Yes and no. Realistically, the range between the beefiest possible remote server and the beefiest possible workstation is what, one order of magnitude? So in a growing environment doing remote dev will maybe let you kick the can down the road a year or two, but you'll still have to deal with whatever was causing your requirements to grow pretty soon.

> But that's only the resource problem. Another problem I have seen my entire career, is devs can't keep their machines configured the same. They have different model laptops, they don't pin their app versions, they configure and install things by hand. Each time they change something by accident it takes them hours, days, sometimes weeks, to get it working again.

> Finally, it's rare for local setups to be secure. Often devs get too much access from their local machines, and this is stolen by infostealer malware and compromise happens. A protected remote environment is easier to secure. A lot of development is hampered by all the crappy corporate security tools that's on laptops now. Remote dev allows you to bypass all that and have a fully working yet protected network without restrictions.

This isn't a remote versus local question, it's a question of how much control developers have over their environment and how much you manage and standardise what's installed. You can have a fully locked down local machine where developers can't install anything except a short whitelist (of course you may get some pushback) and you can have a remote VM where developers curl|sh whatever random repack of Python they wanted this week - I've seen both these things happen in practice.

Security junkware I sort of agree with you, but I think that's more of an artifact of bad laws/policies and if and when remote dev takes off we'll see just as much junkware on remote dev machines as on local ones.

Re: We're Leaving Kubernetes

#314

Post by pmarreck »

rtpg wrote: post #224
pmarreck wrote: post #190

Earlier quoted context omitted.

> installing Nix seems pretty invasive I'm writing a test to check whether a tool I'm writing can work without Nix (it works with it perfectly, but I want it to also work without it because there are a lot of folks like you, and like me about 3 years ago, who still think they'd rather struggle with manually installing the right glibc that goes with the right python dependency installed with the right pip and venv ver…

Nix on MacOS makes a bunch of build users and has a bad habit of touching files that then get touched by MacOS updates, leading to a system that works... then doesn't work.

The Determinate Nix installer flavor is supposedly more resilient to this. Have survived at least 1 OS update unscathed with it.

Re: We're Leaving Kubernetes

#315

Post by chipdart »

mattacular wrote: post #273
chipdart wrote: post #187

Earlier quoted context omitted.

> Trying to boot the full service on a single machine required every single developer in the company installing ~50ish microservices on their machine, for things to work correctly. Became totally intractable. This is certainly one of the critical mistakes you did. No developer needs to launch half of the company's services to work on a local deployment. That's crazy, and awfully short-sighted. The only services a dev…

> You launch your local service locally, you consume whatever you need to consume straight from a cloud environment, you test the contract with a local test set, and you deploy the service. That's it. If your services are mostly stateless and/or your development team is very small that can work. If not, you will quickly run into problems sharing the data. Making schema changes to the shared cloud services. Cleaning u…

> If your services are mostly stateless and/or your development team is very small that can work. If not, you will quickly run into problems sharing the data.

No, not really. The size of your teams have zero to do with whether your services can corrupt data. That's on you. Don't pin the blame on a service architecture for the design errors you introduced. Everyone else does not have that problem. Why are you having it and blaming the same system architecture used by everyone else?

> Making schema changes to the shared cloud services.

What are you talking about? There is absolute zero system architectures where you can change schemas willy nilly without consequences. Why are you trying to pin the blame on microservices for not knowing the basics of how to work with databases?

In all the times I had to work on schema changes, the development was done with a db deployed in a sandbox environment, and when work was done we had to go with a full database migration with blue-green deployments along with gradual rollout. Why on earth are you expecting you can just drop by and change a schema?

> Cleaning up dev/test/etc data that has accumulated, etc.

Isn't this a non-issue to anyone who works with databases? I mean, in extreme scenarios you can spin up a fake database with your local service, but don't even try to argue this is the justification you need to launch dozens of services.

The truth of the matter is that this is extremely simple: if you want to work on a service, launch that service locally configuring it to consume all dependencies running in a non-prod environment. That's what they are for. If you have extremely specialized needs, stub specific dependencies locally. That's it.

Re: We're Leaving Kubernetes

#316

Post by chipdart »

Tainnor wrote: post #309
OrderlyTiamat wrote: post #284

Earlier quoted context omitted.

What was the point of microservice architecture if you can't develop each service individually in the first place? Sounds to me like the architecture you're talking about isn't an actual microservice, and it's just ball 'o mud over TCP instead of as a single monolith. At a previous place of work I worked with a monolith structure, and it was actually perfectly fine. Development got done separately on several large su…

> Then what was the point? Resume chasing and trying to paper over the fact that you don't understand architecture, plus bad tooling that e.g. doesn't properly support incremental compilation and so makes monoliths painful.

> Resume chasing (...)

No one does microservices for resume chasing anymore, because everyone is already doing it for practical reasons. I never came across a monolith that wasn't in the process of peeling responsibilities to either microservices or function-as-a-service. For project managers to open their eyes, all that's needed is something like a deployment going wrong due to a single bad commit, or things scaling weird because a background process caused a brownout, or even external teams screwing up a deployment after pushing bad code.

Re: We're Leaving Kubernetes

#317

Post by chipdart »

Capricorn2481 wrote: post #281
redman25 wrote: post #276

Earlier quoted context omitted.

You can always spin up several services locally or if you have a development cluster run the service you are working on locally against development services.

You're going in circles. That is what the commenter is replying to. You often can't just go off dev because other people use it while you're testing, and you're back to just launching everything yourself.

> You often can't just go off dev because other people use it while you're testing.

Why do you think that other people using a cloud environment prevents you from using the environment?

Re: We're Leaving Kubernetes

#318

Post by chipdart »

rtpg wrote: post #223
rileymat2 wrote: post #154

Earlier quoted context omitted.

I may be misunderstanding, but wouldn't you want the particular microservice you are working on independent enough to develop locally, then deploy into the remote environment to test the integration? (I don't work at this scale)

This is how you get to "I wrote to the spec, it's your problem that clicking the button doesn't do the thing". Huge feedback loops. When you run it "locally" enough you can do your integration stuff before you even ask for review.

> This is how you get to "I wrote to the spec, it's your problem that clicking the button doesn't do the thing".

No, not really. You only find yourself in that spot if you completely failed to do any semblance of integration test, or any acceptance test whatsoever.

That's not a microservices problem. That's a you problem.

You talk about feedback look. Other than automated tests, what do you believe that is?

Re: We're Leaving Kubernetes

#319

Post by chipdart »

Tainnor wrote: post #307
chipdart wrote: post #299

Earlier quoted context omitted.

> Apart from the fact that not everyone uses Visual Studio, "connected services" appears to be something by which you can connect to existing cloud-based services. Yes. That's the point. > How does that solve the problem of a mess of interconnected services (...) I don't think you got the point. The whole point is that you only need to connect your local deployment to services that are up and running. There is absolu…

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 run locally. Everything else you consume it from a cloud environment that's up and running.

That's it. Simple.

If there's something preventing you from doing just that then that's an artiicifal constraint that you created for yourself, and thus that you need to fix. We're talking about things like auth. Once you fix that, go back to square one.

Post reply on HN