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

41–50 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#41

Post by nicoburns »

lmm wrote: post #27
ale42 wrote: post #17

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the given problem. It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance…

> It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. But the overwhelming majority of the time you don't need it, at least not yet. I would say that unless you have actual evidence that your other language would not be adequate - i.e. an implementation of your system or some representative subset of it, in your main language, that you spen…

That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter), whereas rewriting it later would be a massive undertaking.

This I very different to say starting a with a micro service architecture which imposes relatively high overheads, with little benefit as splitting up a well designed monolith is easy.

Re: Kubernetes is a red flag signalling premature optimisation

#42

Post by maverwa »

pjmlp wrote: post #20
ale42 wrote: post #17

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the given problem. It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance…

Its seems to be a new thing with younger generations. We never had an issue with multiple languages across tier-n architectures. Suddenly with the uptake of HTML 5, it became an issue not being able to use JavaScript everywhere.

I think the argument was/is not "its a problem we cannot have javascript" but "if we can have javascript everywhere, we only need to hire javascript devs and only need to care about javascript tooling", which is a fair point.

That does ignore the fact that an experienced frontend JS dev is not necessarily also a good productive backend JS dev, but at least they know the language basics, can use the same IDE, etc.

If thats worth it is something that depends on what you try to achive, I guess. I personally would not pick JS (nor TS) for the backend.

Re: Kubernetes is a red flag signalling premature optimisation

#43

Post by ocius »

sorry_outta_gas wrote: post #33
ale42 wrote: post #17

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the given problem. It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance…

it's not but this article is just blogspam

We try to limit the amount of languages we use, but we have high performance Computer Vision code that is written in C++, we're interfacing that with Python for simplicity, and a web app in JS. Right tool for the job!

Re: Kubernetes is a red flag signalling premature optimisation

#44

Post by p_l »

mstipetic wrote: post #23

It depends how experienced you are with it. If your team has no experience with it, don't do it. I'm pretty experienced, having set up a bunch of infras, so I'd run a blog on it now

Indeed - having used it for few years, I'd start the initial infra (for testing/playground/whatever) as small k8s on a local VM or similar solution so that we could prototype against the target abstractions from day one.

Much, much less work to then move the deployments elsewhere, including building and teardown of integration testing environments.

Re: Kubernetes is a red flag signalling premature optimisation

#45

Post by shele »

> Imagine spending a lot of time and money picking out the best possible gear for a hobby before actually starting the hobby.

Haha, this is exactly what “hobby” means to a lot of people. Less judgmental: thinking and dreaming about the right tools in disproportion to the need is something people do a lot, presumably because it is a source of joy.

Re: Kubernetes is a red flag signalling premature optimisation

#46

Post by ocius »

davnicwil wrote: post #25
ale42 wrote: post #17

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the given problem. It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance…

How do you know what the performance will be in what language or needs to be, in numerical terms, before you are running the system in practice?

You can't really tell for a Web App whether it'll be faster in JS or Python, but you can definitely expect a Computer Vision application with lots of heavy number crunching to be a lot faster in C++ than in Python. We have actually also made comparisons, and even if you use things like numpy and Python bindings for OpenCV, you won't reach the speed that a C++ application achieves easily without optimization.

Re: Kubernetes is a red flag signalling premature optimisation

#47

Post by lmm »

nicoburns wrote: post #41
lmm wrote: post #27

Earlier quoted context omitted.

> It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. But the overwhelming majority of the time you don't need it, at least not yet. I would say that unless you have actual evidence that your other language would not be adequate - i.e. an implementation of your system or some representative subset of it, in your main language, that you spen…

That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter), whereas rewriting it later would be a massive undertaking. This I very different to say starting a with a micro service architecture which imposes relatively high overheads, with lit…

> That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter)

The cases where Go is significantly faster than JavaScript are vanishingly small.

> whereas rewriting it later would be a massive undertaking.

This is vastly overstated IME. Porting existing code as-is between languages is actually pretty easy.

> This I very different to say starting a with a micro service architecture which imposes relatively high overheads,

Disagree. You're imposing a huge overhead on hiring (if you want people with both languages) or on people's ability to work on the whole system (if you're happy hiring people who only cover one side or the other). Debugging also gets a lot harder. There's essentially twice as many tools to learn.

Re: Kubernetes is a red flag signalling premature optimisation

#48

Post by k8sToGo »

dj_mc_merlin wrote: post #18
k8sToGo wrote: post #11

Earlier quoted context omitted.

A managed cluster is not as much managed as you would think. Still have to configure and install a lot of things yourself.

Of course, managed means you don't take care of say, creating your own X.509 CA and issuing certificates, tending to their expiry, installing Tiller, setting up pod networking etc. etc. All of these much more annoying and harder than `helm update --install`ing some charts to your own cluster.

That is true. But if you compare it to, for example, managed web hosting, then it is a very different managed experience.

Re: Kubernetes is a red flag signalling premature optimisation

#49

Post by subhajeet2107 »

tenfourty wrote: post #2

[OP here] It feels bizarre saying this, having spent so much of my life advocating for and selling a distribution of Kubernetes and consulting services to help folks get the most of out it, but here goes! YOU probably shouldn't use Kubernetes and a bunch of other "cool" things for your product. Most folks building software at startups and scale-ups should avoid Kubernetes and other premature optimisations. If your co…

What about standardisation that comes with using a framework like kubernetes , while not using k8s you end up with adhoc deployment methods, clunky work arounds of handling networking, policies, secrets etc, with Kubernetes or even ECS it signals that the team or the developer is looking to use fixed set of rules for infrastructure, also k8s scales well even for smaller apps

Re: Kubernetes is a red flag signalling premature optimisation

#50

Post by ale42 »

ocius wrote: post #43
sorry_outta_gas wrote: post #33

Earlier quoted context omitted.

it's not but this article is just blogspam

We try to limit the amount of languages we use, but we have high performance Computer Vision code that is written in C++, we're interfacing that with Python for simplicity, and a web app in JS. Right tool for the job!

> Right tool for the job!

Well said: this should be the only rule!

Post reply on HN