3 ms·
> Serverless first is a mistake. It should be "serverless where it's distinct advantages are actually useful" which is way less common than people think. Would
by xg15 4y ago
> Serverless first is a mistake. It should be "serverless where it's distinct advantages are actually useful" which is way less common than people think.
Wouldn't that approach take away the remaining advantages of Serverless while still leaving you with the cost?
My understanding was that Serverless is supposed to free you from the burden of maintaining a complete software stack, including configuring the db, server, application runtime etc and just focus on the business logic - a bit like one of the old "sharehost"/LAMPP setups from a few decades ago.
If that is true, then you'd be well-advised to either go all-in and structure your entire application as lambda functions, or don't use functions at all and go with a "traditional" kubernetes deployment.
As both strategies come with considerable complexity cost, combining them would give you the cost of both. I think you'd want to avoid that if possible.
- jpgvm 4y agoSomewhat. I think if I was to ever use serverless for something it would be in concert with a traditional setup so in a way yes, you pay 2x the deployment complexity because now you are orchestrating 2 environments. However if you have a usecase that is absolutely a perfect fit for serverless i.e incredibly bursty, unpredicable, very short runtime. To the point it would be to the detriment of other services hosted on the same infrastructure i.e would need say an isolated cluster anyway then yeah, serverless could be a cost worth paying.
- vbezhenar 4y agoMain issue of lambda and similar offerings is that you're pretty much bound to the cloud. Kubernetes is much more open standard. It's much easier to move to other cloud or self-host. It's more about insurance and keeping other options. Managed Kubernetes, managed databases are a thing and you should use them if you can. Just don't depend on cloud-specific stuff too much.