3 ms·

At a past company, we (incorrectly) assumed we'd always have to support an on-prem deployment capability, so we decided to build our own virtual appliance (assu

At a past company, we (incorrectly) assumed we'd always have to support an on-prem deployment capability, so we decided to build our own virtual appliance (assuming we'll do actual hardware one day). That appliance cluster had to do a bunch of heavy lifting to provide a bunch of services, and we had to do it all ourselves. We even had a Cassandra-like DB cluster, which we stupidly tried to do using Scylla-DB (Scylla is amazing now, but it was just getting started at the time, and while it was super fast even then, it was not stable or reliable enough at the time). To add insult to injury, we only did a single on-prem deployment ever, and that customer never actually converted to a paying one... If I could do it all again, I would have gone cloud-native (or at least leveraged K8s), and I'd use as many managed cloud services as humanly possible. At a later gig - we did just that, and we very very rarely had even 1% of the infra struggles we had with the solution I described above. Nowadays, my basic advice is to always buy the best possible service when you start out, and only start to think about replacing it with DIY services when you have enough scale to pay talented engineers a salary to build AND support replacing it - and even then, the potential loss of focus and velocity might still make this a bad idea. There's a reason Netflix is still on AWS.

naasking 4y ago
> There's a reason Netflix is still on AWS. I would counter with stack overflow which has scaled great over all this time on only a few self-hosted servers. The trouble with replacing the buy with a diy later on is that it will now cost at least twice as much to build, because 1) you're maintaining the existing system which takes some of the people most familiar with the problems of the existing system, and 2) the existing system will still evolve a bit because that's business, so you're also trying to hit a moving target. I think other posters have it correct, you have to think hard about how central a particular feature or service is to your business model. Chances are, differentiating yourself means off the shelf solutions won't be a perfect fit for your core revenue, but all other supporting services should probably be off the shelf.
- int0x2e 4y ago
  I suspect there's a hidden trap here due to survivorship bias - those of us who were lucky enough to see hugely successful products/services that got some of these decisions spot-on in the beginning, see how wonderful it can be when you are able to make these investments early on and build things once. The risk is that you fail to count the number of teams that did the same sort of analysis process and still made the wrong decision because they ended up pivoting, or just straight-up made the wrong call... Replacing a managed solution in a small-scale product really isn't required, because it likely doesn't cost you enough. Replacing it in a high-scale product does matter, but that also mean you should be making enough money to make the replacement pay for itself. If you make the decision to use the managed solution and it's wrong, that's something you can usually fix. If you go DIY when you should have paid for it - you rarely get to correct it in time, and it might just be another nail in your coffin due to lower velocity, focus, etc...
PassageNick 4y ago
It seems strange to me that anyone would go anything but Cloud Native today.

naasking 4y ago

> There's a reason Netflix is still on AWS. I would counter with stack overflow which has scaled great over all this time on only a few self-hosted servers. The trouble with replacing the buy with a diy later on is that it will now cost at least twice as much to build, because 1) you're maintaining the existing system which takes some of the people most familiar with the problems of the existing system, and 2) the existing system will still evolve a bit because that's business, so you're also trying to hit a moving target. I think other posters have it correct, you have to think hard about how central a particular feature or service is to your business model. Chances are, differentiating yourself means off the shelf solutions won't be a perfect fit for your core revenue, but all other supporting services should probably be off the shelf.

int0x2e 4y ago
I suspect there's a hidden trap here due to survivorship bias - those of us who were lucky enough to see hugely successful products/services that got some of these decisions spot-on in the beginning, see how wonderful it can be when you are able to make these investments early on and build things once. The risk is that you fail to count the number of teams that did the same sort of analysis process and still made the wrong decision because they ended up pivoting, or just straight-up made the wrong call... Replacing a managed solution in a small-scale product really isn't required, because it likely doesn't cost you enough. Replacing it in a high-scale product does matter, but that also mean you should be making enough money to make the replacement pay for itself. If you make the decision to use the managed solution and it's wrong, that's something you can usually fix. If you go DIY when you should have paid for it - you rarely get to correct it in time, and it might just be another nail in your coffin due to lower velocity, focus, etc...

PassageNick 4y ago

It seems strange to me that anyone would go anything but Cloud Native today.