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

Kubernetes is a red flag signalling premature optimisation

jeremybrown.tech

Post reply on HN
Print view View original

491–500 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#491

Post by AdrianB1 »

zelphirkalt wrote: post #457
choeger wrote: post #192

Earlier quoted context omitted.

Choosing more than one language as a startup can become really expensive quickly. As long as your tribes are small, chances are high that you one day run out of. e.g., python developers while you still have a lot of Java guys (or vice versa). This introduces unnecessary pain. (And obviously, you should have used Rust or Haskell from the get go for everything.) The sole exception to this rule I would make is javascrip…

Idk, I am someone, who has looked at many programming language, including all of those you mentioned. But a capable developer can be expected to learn a new language over the course of a few weeks if needed. I don't see how you could "run out of devs of language x", if you have capable devs on board. Especially, when those languages are all in the same programming language family/club.

Even the most capable developer that learns a new language in a few weeks will not be an expert in it. The difference in productivity and quality of the code will be huge. This is because in different languages things can be done very differently, it is not about the syntax as much as the best ways to do things.

Re: Kubernetes is a red flag signalling premature optimisation

#492

Post by iasay »

nouveaux wrote: post #488
iasay wrote: post #256

Earlier quoted context omitted.

It was AWS who had trouble fixing our CNI issues…

If AWS broke your CNI that caused you problems, it is also possible for AWS to break networking. I have used Managed K8s for 4 years and literally never had any problems with CNI. My clusters runs with no problems.

Yes we have no problems for 2 years. Then we had problems.

Re: Kubernetes is a red flag signalling premature optimisation

#493

Post by everfrustrated »

lebowen wrote: post #190
clubdorothe wrote: post #179

Earlier quoted context omitted.

Check into Amazon ECS or Google Cloud Run. It's basically a higher level of managed Kubernetes ( EKS or GKE ). You give your containers, and they take care of running it. Tim Hockin (one of kubernetes creator) support the idea to use something as much managed and automatic as possible : https://twitter.com/thockin/status/1539987108521054208

I'm aware of these products, but do not fit my use case. I need to run some services on premises and have set up a self hosted Kubernetes instance on a physical server in a rack. It could be overkill and maybe I could use something like Docker Swarm. Apart from this I am unsure what I can use that isn't K8s to orchestrate my containers on site.

AWS ECS can be run on-prem.

Re: Kubernetes is a red flag signalling premature optimisation

#494

Post by dang »

Jistern wrote: post #381
politician wrote: post #318

Earlier quoted context omitted.

I’ve run DevOps and know from experience the pitfalls. I’m sorry that you’ve interpreted my general agreement and elaboration of your comment as nitpicking foolishness.

Quoted post unavailable.

We've banned this account for repeatedly breaking the site guidelines.

https://news.ycombinator.com/newsguidelines.html

Re: Kubernetes is a red flag signalling premature optimisation

#495

Post by tomtheelder »

steveBK123 wrote: post #382
mixedCase wrote: post #373

I'm getting tired of the "You don't actually need Kubernetes while starting out!" crowd, despite being part of it. Of course you don't. Of course if you don't know Kubernetes, learning it as you try to get a company going on a minimum headcount is not the most efficient approach. But for pete's sakes man, if you have used K8s before, know what you're doing and you're running on cloud, just shove a couple off-the-shel…

I think it still bears repeating.. I've seen projects fail or take 10x as long due to choosing to go with k8s day 1 instead of starting with even a basic VM. It may be easy enough to get k8s itself setup. However, without an in-house expert sat within the dev team, all the access/permissions to resources to/from the cluster were hell. NFS disk Read/Write, S3 Read/Write/List, RDS DB access, Kafka access, corp network…

This sounds like projects struggling because they chose to go with k8s when the team lacked k8s expertise.

Honestly I feel like the original blog post shouldn't be talking about k8s at all. The real lesson, as far as I can tell, is just "when you're starting out, choose simple tech that you already know how to use."

If you already know how to use Kubernetes, then feel free to use it. If not then don't.

Re: Kubernetes is a red flag signalling premature optimisation

#496

Post by nouveaux »

movedx wrote: post #480
nouveaux wrote: post #478

Earlier quoted context omitted.

I'll be honest I haven't fully explored AMIs as a solution but how do you run the AMI in your local dev environment? I can replicate the same K8s with docker images easily in local dev.

If you can't run your software locally without Docker, I'd be worried. But to answer the question, VMs have been a thing on the desktop for a very long time.

How do you download AMIs of Redis, Postgres, etc? Are you building this all by hand?

Re: Kubernetes is a red flag signalling premature optimisation

#497

Post by antholeole »

First, to respond directly to the post: having a (stable, one you don’t tinker with every other day) k8 setup isn’t bad, its only bad when you have to pay the setup overhead. I built a boilerplate app with: - authentication (Google auth) - cloud run backend -CDK - CICD (GitHub actions) - full-boilerplate frontend - full boilerplate backend - Signal error reporting - Postgres - graphQL - all my other preferences like git hooks, linter rules, vscode workspace, local environment etc. Now, whenever I need to build an app, I just git clone this repo and its plug in credentials and play. My backend cluster doesn’t ever run more than one instance, so I guess having a scalable backend is pointless, but who cares? It’s free, time wise (and almost money wise since cloud run is pretty efficient). I built it a year ago and don’t touch most of the dev ops for any app, except to maybe rip out authentication when I don’t need it. Imo, I think this is a highly effective method of engineering. Everyone has their favorite stack, so it might be worth it you to take a weekend and fully build out your boilerplate app so that if you ever need to, you can get straight to building the actual features.

Re: Kubernetes is a red flag signalling premature optimisation

#498

Post by wahnfrieden »

okamiueru wrote: post #243
wahnfrieden wrote: post #227

Earlier quoted context omitted.

for example lambda (not microservices, running mini monoliths per lambda function) yes by simple I mean covering high availability requirements, continuous deployment, good DORA measures - not simple as in half-baked non-functional operations (such as manually sshing to a server to deploy)

Ah, I see. Well, lambdas are also a nice tool to have, but it certainly do not fit for all applications (same as with k8s). I'd also point out that lambdas replace a rather small capabilities of k8s, and the type of systems you can put together. You would end up needing to set up the rest either through a terrible AWS UI or terraform. Neither of which I find to simplify things all that much, but perhaps this is a mat…

>If you start hacking them to keep them alive because of long cold starts,

this is a few years out of date of platform capability, just fyi

Re: Kubernetes is a red flag signalling premature optimisation

#499

Post by WatchDog »

ocius wrote: post #39
WatchDog wrote: post #10

Earlier quoted context omitted.

What is it giving you over an ec2 auto scaling group or ECS/Fargate? Both can scale as much as you like, your config can live as cdk/cloudformation/terraform code?

I'm not an expert on auto scaling groups, but we have used the Google Cloud equivalent for a time. The biggest issue for us was that deployment is not as easy. Can you update the software on the ec2 instance without turning it on, for example? With K8s, we can leave the deployment scaled to 0 and just patch the image of the deployment to perform a release while the workers are all shut down. Similarly, we don't have…

> Can you update the software on the ec2 instance without turning it on, for example?

Yes, you can build an amazon machine image for ec2, update your cluster with the new image, without scaling from zero.

> As others have already pointed out, it is also important for us to remain independent from Google Cloud / AWS.

This seems like a good reason to use k8s, although as the original article touches on, it seems like switch cloud vendor rarely ever happens.

Re: Kubernetes is a red flag signalling premature optimisation

#500

Post by hsn915 »

huffmsa wrote: post #277
hsn915 wrote: post #200

Earlier quoted context omitted.

> The biggest learning curve is for the person setting up the initial deployments, services, ingress etc Most other team members may just need to maybe change the image name and kubectl apply to roll things out. This is a huge redflag. It's basically admitting that you expect most later employees to not understand k8s or how its being used. You may think they don't need because it works, but you have to think about w…

Just like how you don't really expect later devs to learn the intricacies of your hand rolled deployment setup. The difference is, kubernetes is pretty standardized and therefore learnable in a repeatable way, unlike the Frankenstein of tooling you might otherwise cobble together.

That would only be true if you actually need 90% of what k8s provides and will end up reproducing it poorly.
Post reply on HN