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

171–180 of 348 posts

Re: We're Leaving Kubernetes

#171

Post by nightski »

animal_spirits wrote: post #163
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)

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

So basically a distributed monolith :P

Re: We're Leaving Kubernetes

#172

Post by justinclift »

themanmaran wrote: post #165
justinclift wrote: post #157

Earlier quoted context omitted.

> installing ~50ish microservices on their machine Ouch. Where they using macOS at the time with laptops having not-enough-ram? I've seen that go poorly on macOS with java based microservices. Largely due to java VMs wanting ram pre-assigned for each, which really chews though ram that mostly sits around unused. This was a few years ago though, at the tail end of Intel based mac's where 32GB ram in a mac laptop wasn'…

I bet it's less of a RAM issue, and more of an orchestration problem. Making sure you have the latest version of every microservice and it's configuration. "Oh it's not running locally, you need to also run service_18_v2.js, and include the right env variables"

No, it was definitely a ram issue in this case. The laptops had 16GB of ram, the maximum available at the time. With the java VM overhead that ran things straight into swap and then some.

Running the dev environments remotely (or rewriting in Go) were the options being considered before the whole project was canned and people redistributed to other things.

Re: We're Leaving Kubernetes

#173

Post by [deleted] »

czhu12 wrote: post #148
horsawlarway wrote: post #33

Personally - just let the developer own the machine they use for development. If you really need consistency for the environment - Let them own the machine, and then give them a stable base VM image, and pay for decent virtualization tooling that they run... on their own machine. I have seen several attempts to move dev environments to a remote host. They invariably suck. Yes - that means you need to pay for decent h…

We tried this approach at a former company with ~600 engineers at the time. 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. I guess one can grumble about bad architecture all day but this had to be solved. we had to move to remote development environments which…

[deleted]

Re: We're Leaving Kubernetes

#174

Post by Imustaskforhelp »

bhouston wrote: post #47
rglover wrote: post #36

Earlier quoted context omitted.

I'd investigate getting a build out to Node.js (looks like you already have this) and then just doing a simple SCP of the build to a VPS. From there, just use a systemd script to handle startup/restart on errors. For logging, something like the Winston package does the trick. If you want some guidance, shoot me an email (in profile). You can run most stuff for peanuts.

> I'd investigate getting a build out to Node.js (looks like you already have this) and then just doing a simple SCP of the build to a VPS. From there, just use a systemd script to handle startup/restart on errors. For logging, something like the Winston package does the trick. If you want some guidance, shoot me an email (in profile). You can run most stuff for peanuts. I appreciate the offer! But it is not as robus…

to be really honest , why don't you use cloudflare for blog post hosting / their storage mechanism if you really want comments hosting.

Why are you actually using google cloud for blog post hosting.

Also you said a million $ kubernetes

wait a second ,have you converted those million $ to 4$ per month

what tom foolery is this

Re: We're Leaving Kubernetes

#175

Post by eichi »

Kubernetes is just combined infra admin practices. Whether we use it or not, we need to do the same things by local oriented way or vendor specific way .

1. Some operations on remote in local oriented way are time consuming and unmanageable.

2. With vendor specific way, our skill would be deprecated, having dependency to the vendors.

3. Kubernetes is not the best tools but it it popular.

As always, custom solution is the most powerful but should be replaced with more unified way for the stability of the development.

Re: We're Leaving Kubernetes

#176

Post by otabdeveloper4 »

pmarreck wrote: post #88
horsawlarway wrote: post #33

Personally - just let the developer own the machine they use for development. If you really need consistency for the environment - Let them own the machine, and then give them a stable base VM image, and pay for decent virtualization tooling that they run... on their own machine. I have seen several attempts to move dev environments to a remote host. They invariably suck. Yes - that means you need to pay for decent h…

In my last role as a director of engineering at a startup, I found that a project `flake.nix` file (coupled with simply asking people to use https://determinate.systems/posts/determinate-nix-installer/ to install Nix) led to the fastest "new-hire-to-able-to-contribute" time of anything I've seen. Unfortunately, after a few hires (hand-picked by me), this is what happened: 1) People didn't want to learn Nix, neither d…

> there is no (to my knowledge) general-purpose, broadly-accepted way to deploy via Nix

`nix copy .#my-crap --to ssh://remote`

What you do with it then on the remote depends on your environment. At the minimum do a `nix-store --add-root` to make a symlink to whatever you just copied.

(The most painless path is if you're deploying an entire NixOS system, but that requires converting the remote host to NixOS first.)

Re: We're Leaving Kubernetes

#177

Post by otabdeveloper4 »

kstenerud wrote: post #152
pmarreck wrote: post #88

Earlier quoted context omitted.

In my last role as a director of engineering at a startup, I found that a project `flake.nix` file (coupled with simply asking people to use https://determinate.systems/posts/determinate-nix-installer/ to install Nix) led to the fastest "new-hire-to-able-to-contribute" time of anything I've seen. Unfortunately, after a few hires (hand-picked by me), this is what happened: 1) People didn't want to learn Nix, neither d…

After my personal 2-year experiment with NixOS, I'd avoid anything Nix like the plague, and would be looking for a new job if anyone instituted a Nix-only policy. It's not the learning new things that's a problem, but rather the fact that every little issue turns into a 2-day marathon that's eventually solved with a 1-line fix. And that's because the feedback loop and general UX is just awful - I really started to fe…

> ...but at least it's generally easy to see what you did wrong and fix it.

You're not actually "fixing" anything, you're just passing the ball of shit down the responsibility chain to the ops/infra team.

Which is fine if you work in a large corporation where this is a valid strategy.

Unfortunately though the software supply chain problem is a) very difficult and b) unavoidable.

Nix is the best (or maybe only) attempt to solve this problem with programmatic (vs organizational) tooling.

Re: We're Leaving Kubernetes

#178

Post by Jack008 »

Make sure you need microservices-based architecture because it comes with its own complexity - a load balancer, container networking, distributed tracing, etc. If you application does not need to scale its sub-components independently, you are better off using a VM-based application. It's 10X cheaper to maintain/troubleshoot and is high performance/resources.

Re: We're Leaving Kubernetes

#180

Post by pxc »

kalaksi wrote: post #111
pmarreck wrote: post #88

Earlier quoted context omitted.

In my last role as a director of engineering at a startup, I found that a project `flake.nix` file (coupled with simply asking people to use https://determinate.systems/posts/determinate-nix-installer/ to install Nix) led to the fastest "new-hire-to-able-to-contribute" time of anything I've seen. Unfortunately, after a few hires (hand-picked by me), this is what happened: 1) People didn't want to learn Nix, neither d…

From my perspective, installing Nix seems pretty invasive. I can understand if someone doesn't want to mess with their system "unnecessarily" especially if the tool and it's workings are foreign. And I can't really remember the last time I had issues with non-deterministic dependencies either. Dependency versions are locked. Maybe I'm missing something?

> From my perspective, installing Nix seems pretty invasive.

How so? With what other software does Nix interfere?

Post reply on HN