541–550 of 558 posts
There are two things that guarantee a click on HN due to the community's ignorance and arrogance: Crypto and Kubernetes.
The only question is which is which.
I disagree. K8s signals the team values infra and sees it as an important part of delivering their product. It's an investment like any other and for some teams it makes sense to set infra on a solid path sooner rather than later. You can move fast on things like serverless but the limitations of those systems can force architecture decisions that are sub-optimal whilst control of your own infrastructure can allow br…
But isn't "infra[structure]" what you run your product on, and not part of the product itself? If your "product" is so big it needs stuff like that built into it, then it feels to me that by defintion that stuff isn't "infra".
All in all, your sentence feels like "The Excel-Dell Humongo-XPS bundle signals that Microsoft values infra and sees it as an important part of delivering their product" to me. No, that only signals that A) Dell and Microsoft are using the dominant marketing position of Excel to milk money from naive customers, and B) If Excel can't run on more modest hardware, it's an unnecessarily bloated and inefficient product; look around for another spreadsheet.
Earlier quoted context omitted.
> Setting up environments becomes a massive PITA when working directly with VMs. The end result is either custom scripts, which is a messier version of terraform, which ends up being messier than just writing a couple of manifest files for a managed k8s. The author advocates using a high-level PaaS. For sure working directly with VMs is the wrong answer to premature optimization, but as an early stage startup, there'…
OP here, I agree. You can get super far with a service like fly.io/Heroku/Netlify/Vercel etc. (pick the one that works with your stack). VMs are an anti-pattern as well for the early stages of an application or startup.
Earlier quoted context omitted.
I'm far from a full stack developer, but really how much code would actually be common across the front and and back end? I would have thought maybe some validation code, not sure how much else?
Sounds about right. I have an API service written in Go for which we also offer a client library in Go. We moved the common ground between the two into a separate module to avoid code duplication. That module ended up having the type declarations that appear on the API in JSON payloads, plus some serialization/validation helper methods, and that's it.
I disagree. K8s signals the team values infra and sees it as an important part of delivering their product. It's an investment like any other and for some teams it makes sense to set infra on a solid path sooner rather than later. You can move fast on things like serverless but the limitations of those systems can force architecture decisions that are sub-optimal whilst control of your own infrastructure can allow br…
> K8s signals the team values infra and sees it as an important part of delivering their product. But isn't "infra[structure]" what you run your product on, and not part of the product itself? If your "product" is so big it needs stuff like that built into it, then it feels to me that by defintion that stuff isn't "infra". All in all, your sentence feels like "The Excel-Dell Humongo-XPS bundle signals that Microsoft…
First of all k8s isn't bloated, it's actually surprisingly compact if you think about what you are getting.
Second it doesn't imply the product -needs- it. Anything you can run on k8s can be run on bare boxes.
Just doing so probably means you either lack the scale to need k8s (i.e my spreadsheet doesn't have many users) or you lack the competence to understand you have reached the scale that it's required (i.e your spreadsheet is run by n00bs). So it's much more of a positive than negative signal if you are seeking a vendor. I think the product relationship thing is a poor analogy from that side though, it -mostly- matters for people that want to work there on/in/around the product itself.
As a primarily infra guy I have a preference for k8s because it allows me to have some reasonable set of services I can rely on being there if a place is "using k8s". If not I just have to hope either the existing infra team is competent enough to have things like service discovery, secret management, process monitoring, etc under control or that they are amenable to efforts to get it under control.
If I am approaching it from a backend developer perspective where most of that isn't my problem then it gives me some confidence the infra team has some idea what they are doing and that I won't need to deal with some sort of bespoke deployment system that has endless quirks and company-specific bugs that I shouldn't need to concern myself with.
Generally k8s just eliminates uncertainties by increasing standardisation so I don't need to watch people solve the same problem poorly over and over again for no reason at all.
I agree entirely. I like to call what the author is referring to as, "What-If Engineering". It's the science of thinking you'll be Google next week, so you build for that level of scale today. It involves picking extremely complicated, expensive (both in compute and skilled labour) technologies to deploy a Rails app that has two features. And it all boils down to, "But what if..." pre-optimising. It happens at all le…
>> Helm and the likes make it possible to spin up these kinds of solutions in a heart beat Genuine question, why is this bad? Is it because k8s can spin it up but becomes unreliable later? I think the industry wants something like k8s - define a deployment in a file and have that work across cloud providers and even on premise. Why can't we have that? It's just machines on a network after all. Maybe k8s itself is jus…
Earlier quoted context omitted.
> kubernetes is pretty standardized Sure. Though the standard changes weekly.
My favorite Kubernetes joke can be told in one word: v1alpha1
And the good thing is the graduation process means that this can actually be relied upon not to break compatibility.
Earlier quoted context omitted.
Rocket science isn't hard if you know it. Should we all build spaceships to deliver groceries? Good luck finding a few local rocket scientists in a pinch. You can find plenty of auto mechanics though. Cars are cheaper and ubiquitous. Maybe they can't drive to the moon, but they can get most things done. Unless your business is flying to the moon, stick to cars and trucks over spaceships.
lol what? k8s isn't rocket science, for a basic web app its a single yaml file
Earlier quoted context omitted.
lol what? k8s isn't rocket science, for a basic web app its a single yaml file
In the same sense that rockets aren't complicated either, you just put on a suit, climb in, press some buttons