[sweaver]

For sure, there is power at the cost of agility!

I've seen cases where we started off as simply as possible with no k8's. We built the initial product really quickly using a ton of managed services. Whilst it was great to get us going, once we hit "growth" things just didn't scale. (1) The cost of cloud was getting astronomical for us (and growing with each new deployment) and (2) it was totally inflexible (whether that be wanting to deploy in a different cloud, or extend the platform's featureset) because we didn't own the underlying service.

We ended up porting everything to k8's. That was a long & arduous process but it gave us total flexibility at significant cost savings. The benefits were great, but not everyone has access to the engineers/skillset needed to be successful with k8's.

That's why we built Plural.sh – it takes the hard work out of k8's deployments. I've seen people go from zero to a full production deployment of a datastack on k8's in just 2 weeks. It deploys in your cloud, and you own the underlying infra and conf so you have total control of it. And because we believe in being open, you can eject your stack out of plural if you don't like it and keep everything running.

Great post, and hope all is well with you!

[candiddevmike]

I think it's funny that everyone uses/loves k8s ends up building a product to make it easier to use. There are a lot of examples in the comments here. To me, that's enough of a red flag that k8s doesn't understand their users or can't meet them where they're at.

[nouveaux]

Heroku and friends is literally built to simplify the complexities of VMs. Are you also arguing that deploying to VMs is too complex?

[ryanbrunner]

> We ended up porting everything to k8's. That was a long & arduous process but it gave us total flexibility at significant cost savings. The benefits were great, but not everyone has access to the engineers/skillset needed to be successful with k8's.

I think the argument from most people advocating against using k8s from the get go isn't so much that you'll never need it, but more that it's better to pay this cost later when you have a demonstrated problem that needs to be solved, even if it's a bit more expensive (and I would bet that the total time expenditure isn't really all that much more moving to k8s later, it's just in one chunk instead of spread over your history).

By deferring the cost of building more complex infrastructure:

- You can use those resources to advance your product (arguably some companies that have hit a wall with PaaS vendors may never have gotten to the point where they outgrew those vendors if they spent more of their time on infrastructure vs. company value) - You'll have a better idea of what you'll need and where your scaling hotspots are going to be if you've already encountered them. Building infrastructure that allows for flexibility in a few key areas is infinitely easier than building infrastructure that can scale in every way imaginable. - You can potentially take advantage of new technologies if you defer the decision to when you need it. It would be silly to assume k8s is the final word. If you wait a few years, things will have evolved and you gain the advantage of using those few years of advancement rather than cementing a choice early on.

[tr33house]

Had the same exact experience! Just posted a comment. I think could companies have done a good job marketing how cheap it is to get started on cloud. Once things scale, the bills change and it's no longer as cheap to use managed infra.

The night and day difference is hard to explain when people haven't had to deal with all these issues on top of scaling, uptime, performance issues etc. I just can't recommend k8s enough