4 ms·
Usually,. the thing that you lose is scalability, availability any reliability. You will need a remote backup and a secondary located service, just in case. Po
by AstralStorm 8y ago
Usually,. the thing that you lose is scalability, availability any reliability.
You will need a remote backup and a secondary located service, just in case. Potentially a third development one to not push breaking changes directly into production.
Skipping any of this will make your service brittle in addition to not being scalable.
And it already hits the rule of three... (of "don't repeat yourself") that makes a lightweight Kubernetes deployment worthwhile.
(Perhaps without all the bells and whistles.)
Remember, downtime is usually lost money. A day's worth can be thousands of dollars at least, and that's two nines already. (99.99%)
- chii 8y agoOr, you ship 2 months earlier, and the trade off being suffering a day's worth of downtime. It makes no sense to start with a more complicated setup, until there is clear evidence of a need.
- AstralStorm 8y agoThe main problem is that usually low quality infra bites you when you get exposure. Which is exactly when you don't want it to fail... For a start, Heroku or AWS instance will do and they scale. (As the other commenter said) If you're doing your own infra, you need at least basic fallbacks and safety.
- theblackcat1002 8y agoWell if the first day you shipped your product and it's already worth 1k, yeah it makes sense to do everything the "correct" way. But for most of the side projects and startup products this makes no sense at all.