4 ms·
I think you’re both right, even if I’d guesstimate the situation you encountered is very, very rare. You should make architectural choices that CAN be scaled w
by klabb3 4y ago
I think you’re both right, even if I’d guesstimate the situation you encountered is very, very rare.
You should make architectural choices that CAN be scaled within reason, on demand and ideally incrementally. That doesn’t mean you need to build your app on Kubernetes and automate welcome emails, surveys, metrics, A/B testing etc. But you probably shouldn’t build on top of fundamentally non-scalable systems either.
This is provided you’re in an environment that can reasonably scale to 1M users or whatever, which isn’t true for all domains. Say B2B where that last B is only 10000 people world wide.
- what-the-grump 4y agoIt’s difficult to explain to people what you said without the experience of living in the failures of early optimization. K8s from day one, a-b testing, programmatic quality control without any paying clients on the product, scrum master and a PM and a product owner for 5 devs! Whole thing feel like a Ponzi scheme to keep overseas staff employed, perpetrated by the overseas development shop. Unless you built something absolutely atrocious, scaling it vs getting it ‘right’ or ‘right enough’, is trivial. You couldn’t sign up to Facebook if you weren’t a college student. Chatgpt overloads daily so what? When your app becomes necessary to enough people, bring in your k8s evangelists and shove into x cloud provider. But by god it doesn’t take 30 people to write a marketable mvp.
- klabb3 4y agoCouldn’t agree more.
- deleted 4y ago[deleted]
- adrr 4y agoMaybe I had the fortunate luck that we never had issues of finding market fit. We also had lots of investment outside of software dev. Fintech for example requires significant investment in compliance(eg: kyc). Chatgpt doesn’t have competitors. Customers can’t go elsewhere. Twitter had the same protection when they launched, there wasn’t a short form social network so they could have full day outages. Friendster would be the opposite, when they closed signups, customers just went to MySpace. Scale goes beyond the ability to support traffic. It also means efficiently handle data/traffic. Heap is a good example, great product but they haven’t figured out to provide that level of analytics without significant costs which are passed on to the customer.
- vbezhenar 4y agoWhat's wrong with Kubernetes from day one? I'd use it from day one everywhere. Avoiding kubernetes is a sign of technical incompetence.
- doteka 4y agoNah, statements like the above are a sign of lack of experience, missing business understanding and/or hubris.
- lelanthran 4y ago> What's wrong with Kubernetes from day one? I'd use it from day one everywhere. Avoiding kubernetes is a sign of technical incompetence. Everywhere? Sounds like you're cargo culting. There's a use-case for it, and that use-case is when your load is so high you need the orchestration.
- vbezhenar 4y agoKunerbetes works just fine on a single node. And it provides a lot of good things over docker run scripts or docker-compose. Kubernetes basically is an OS for OCI images. Even if you don't need orchestration, it still provides great experience. And when you would need orchestration, you will grow organically. Right now I'm using cluster of 2 nodes (master, worker). No reliability, but convenience is good and we have very simple path to more nodes when we would need it.
- lelanthran 4y ago> Kunerbetes works just fine on a single node. But ... no one claimed it didn't, did they? The claim was that the unnecessary complexity (of which Kubernetes was just one) from day 1 consumes valuable time that could be spent on making the product better.
- Thiez 4y agoIs hosting in kubernetes really more time consuming than one of the proprietary PaaS cloud hosting options? What better alternative would you propose?