I often hear a lot about you should vs you shouldn't. How about just highlighting your experience with? Not all companies, people or circumstances are the same. To me, it's akin to comparing athletes and trying to debate who is the goat. Just talk about what you did and let people figure it out. If their startup failed because of it, then they got what they were after, to learn and grow for the next one. Or, maybe to not do one again. I can guarantee you that for every claim you make, there's someone who was successful in doing the opposite.
Kubernetes is a red flag signalling premature optimisation
361–370 of 558 posts
Re: Kubernetes is a red flag signalling premature optimisation
#362Earlier quoted context omitted.
>> I agree entirely. I agree entirely too. >> Start with a monolith on two VMs and a load balancer. Chips and networks are cheaper than labour, Kudos to you! You are a dangerous man for you opine the truth. My advice is generally, "Build something. Then see if you can sell it." or "Sell something and then go build it." Either way, it all starts soooo small that the infrastructure is hardly a problem. If you "get luck…
You can’t just hire 1 DevOps superstar though because they need to sleep and not burnout. You’ll need ~7 people on a rotation if you need to really support anything worth really supporting. DevOps is about giving Developers a dedicated System Operations job for some small fraction of their time.
> DevOps is about giving Developers a dedicated System Operations job for some small fraction of their time.
No. DevOps is about the development and operations disciplines working together in a cross functional way to deliver software faster and more reliably.
In a small enough startup both disciplines may be represented by a single person, though.
Re: Kubernetes is a red flag signalling premature optimisation
#363Earlier quoted context omitted.
I think the set of cases where "we need to scale up rapidly if it succeeds" and "Kubernetes solves all of our scaling needs and we aren't going to have problems with other components" is almost empty. On the other hand, there are quite a lot of startups that fail because they put too much focus on the infrastructure and Kubernetes and the future and too little on the actual product for the users. Which is the point o…
> I think the set of cases where "we need to scale up rapidly if it succeeds" and "Kubernetes solves all of our scaling needs and we aren't going to have problems with other components" is almost empty. I agree, but so what? K8s isn't magic, it won't make all your problems go away, but if you have people who are genuinely skilled with it, it solves a lot of problems and generally makes scaling (especially if you need…
What about CD of similar but not identical collections of services to metal? No scaling problem, other than the number of bare metal systems is growing, and potentially the variety of service collections. For instance, would you recommend k8s to tesla dor the CD of software to their cars?
Re: Kubernetes is a red flag signalling premature optimisation
#364Earlier quoted context omitted.
That's sad, JavaScript was already not great for front-end and we now get it in backend and even the edge. Most job offers are for a mythical full-stack developper that'll master web design, CSS/HTML, front-end interactions and code, networking, back-end architectures, security,... You end-up with people who don't have time to get enough expertise and write and build clean stuff. Hacking poor JavaScript code everywhe…
In my mind it is not code reuse between frontend and backend, but expertise and standard library reuse that is the winner. Better to have a full stack developer that can concentrate on becoming an expert and fluent in just one language rather than being kinda-ok in 3 or 4 IMHO.
The struggle is not learning a new language nor becoming fluent.
The real expertise is being a front-end expert, authoring efficient architecture around user interactions, browsing the MDN without effort, mastering the DOM... Then, being a back-end expert, knowledgeable on scaling, could architectures, security issues, being able to author good API design...
If you can be considered an expert in all of this, and also edge computing, I don't think switching language would be an issue for you. Language is a tiny fraction of required expertise and you might be more productive by switching to an appropriate one.
Re: Kubernetes is a red flag signalling premature optimisation
#365Earlier quoted context omitted.
> At the same time. I can scale heroku to 500 servers, and still be under the cost of one ops person. I can make that change and leave it there. I can do that all in under 30 seconds. Oh. And CICD is built in as a github hook. Even with blue-green deploys. And then Heroku shuts down. If you're building something that needs to scale up rapidly if it succeeds, k8s is worth thinking about. Either you don't succeed, in w…
> Either you don't succeed, in which case it doesn't matter what your stack was, or you do, in which case you'll be glad that you can scale up easily This take brushes right past the causes of success and failure. Early stage success depends on relentless focus on the right things. There will be 1000 things you could do for every 1 that you should do. Early on this is going to tend to be product-market fit stuff. If…
I certainly wouldn't recommend that anyone "focus on multi-cloud" in an early-stage company (unless of course multi-cloud is a crucial part of their product in some way).
Kubernetes is basically an industry standard at this point. It's easy to hire ops people competent in it, and if you do hire competent people, it will save you time and money even while you are small. As an investor "we use this product for orchestration rather than trying to roll our own solutions to the same problems, so that we can focus on $PRODUCT rather than reinventing half-baked solutions to mundane ops problems" should be music to your ears.
Re: Kubernetes is a red flag signalling premature optimisation
#366Earlier quoted context omitted.
Kubernetes is the React of devops. You wont get fired for picking it. And there will be a tonne of support available online, as well as courses, and experienced people you can hire. Also there is cloud managed k8s which takes most of the pain out of it. And plenty of out the box stuff. It is not a bad choice if you want to do the ops yourself for some reason. If you don't then use a BaaS or PaaS, that might be easier…
You seem to be saying there's nothing inbetween K8s and "use a BaaS or PaaS"? What about something that does the subset of what K8s does that is the simple bit and covers most use-cases outside of complex clusters? I get the strong sense people are just misusing it for the wrong types of task. I've seen this happen countless times in tech. Development by CV.
Docker Swarm, Nomad, ECS?
Re: Kubernetes is a red flag signalling premature optimisation
#367Earlier quoted context omitted.
I've told this story before on HN, but a recent client of mine was on Kubernetes. He had hired an engineer like 5 years ago to build out his backend, and the guy set up about 60 different services to run a 2-3 page note taking web app. Absolute madness. I couldn't help but rewrite the entire thing, and now it's a single 8K SLOC server in App Engine, down from about 70K SLOC.
What's your plan when (not if) Google deprecates GAE?
Not OP, but App Engine have actually been around for a long time.
Also, there's no inherent lock-in, you can basically just deploy it somewhere else.
Data is where the lock-in lies. Moving can be hard if you use proprietary databases. Can still be worth it.
Re: Kubernetes is a red flag signalling premature optimisation
#368Earlier quoted context omitted.
> In the limit, there are some startups that could run production on a single Linux host I guess redundancy is not really a thing then? With serverless offerings you can get rather good deals, I don't think you need your own K8S cluster if you can get away with a single Linux host, but a single Linux host is pretty pricey maintenance wise compared to google Cloud Spanner and cloud run.
> I guess redundancy is not really a thing then? Most of the time it really doesn't need to be. In the end what you care about is uptime and cost. A redundant solution doesn't have a perfect uptime just because it's redundant, in fact sometimes it might have even less uptime because of failures in the redundancy mechanism. Of course if you need to be always up it might be worth it. But for a lot of situations some do…
> A redundant solution doesn't have a perfect uptime just because it's redundant, in fact sometimes it might have even less uptime because of failures in the redundancy mechanism
I'm fairly sure that google does a better job keeping cloud spanner and cloud run working, and their redundancy mechanisms working, than whoever runs your single linux box will do.
> most of the time it's better to be on a simpler setup that's easier to debug and less costly to maintain
Keeping a whole linux box running is more complicated and requires more maintenance than Cloud Run and Cloud Spanner.
> Also, I wouldn't underestimate the cost of maintenance in managed solutions compared to self-hosted.
It is not 0, it is just that if you manage cloud run and cloud spanner you don't manage all the other things you have to manage when you self host, and managing cloud run and spanner is really not a lot of effort, it is a lot less effort than managing a standalone database at least.
> You also have to add the cost of adapting your solution to their infrastructure, which is not trivial either.
Cloud run can run stock standard docker containers, you will have a bad time if your processes are not stateless though, and you will have the best time if you have a 12-factor app, but I would not count that as adapting to infrastructure.
And you can use AlloyDB if you want Postgres.
Re: Kubernetes is a red flag signalling premature optimisation
#369Earlier quoted context omitted.
I've told this story before on HN, but a recent client of mine was on Kubernetes. He had hired an engineer like 5 years ago to build out his backend, and the guy set up about 60 different services to run a 2-3 page note taking web app. Absolute madness. I couldn't help but rewrite the entire thing, and now it's a single 8K SLOC server in App Engine, down from about 70K SLOC.
What's your plan when (not if) Google deprecates GAE?
Eh, it's just a simple node server, no real attachments to GAE. I could move it over to Digital Ocean or something within a day or two.
Re: Kubernetes is a red flag signalling premature optimisation
#370Earlier quoted context omitted.
What's your plan when (not if) Google deprecates GAE?
Not OP, but App Engine have actually been around for a long time. Also, there's no inherent lock-in, you can basically just deploy it somewhere else. Data is where the lock-in lies. Moving can be hard if you use proprietary databases. Can still be worth it.
Yeah the one good decision by that former dev was to use Mongo Atlas, so the data layer is completely decoupled from GCP.