Lambda Days 2018 - Wojciech Gawroński - Functional Programming in Serverless World
Cutting costs from AWS serverless to just hosting Elixir nodes. You be the judge. https://medium.com/coryodaniel/from-erverless-to-elixir-48752db4d7bc
Which brings up a thought I’ve had for a while, as K8s matures and it becomes less painful to set up the initial cluster, then a good chunk of what cloud providers offer becomes accessible to small operators on their own hardware.
Yes… There are many ways your AWS bill can wind up being way more than expected–moving to cloud to save money does not always work out quite how management anticipates–you have to understand you workload, cloud offerings, and monitor things
Functions in serverless architecture should, in general, be single-threaded and single task - but evidently there are cases where exploiting concurrency inside a single lambda function invocation can save money. So using a language that does not address concurrency at the language level could be a case of pessimizing prematurely.
This is a problem because if you build a business around this reasoning, then you are completely at the mercy of middleware you thought you could trust. If Amazon or whatever decides to make their services 10, 100 or 1000 times pricier because their marketing teams concluded it would raise their overall revenues, then you are fucked as there is no way you can rewrite all your codebase to run on something else quickly.
I’m not saying it’s not worth taking the risk, but saying there is no problem is really short sighted.
- Firebase Costs Increased by 7,000%!
- AWS announced over 57 price cuts in the last five years and zero price hikes.
- Fighting vendor lock-in and designing testable serverless apps using hexagonal architecture (the HN discussion has a lot of “it’s not worth the effort” opinions)
- Pricing pitfalls in AWS Lambda (article hosted by Binaris Serverless Functions)
- Cloud Complexity and Cybersecurity Drive IT Budget Growth
There is an underlying theme of “plan to move from serverless to containers when costs escalate” - must be the cloud version of Plan to throw one away.
For cost, if you own your physical servers … nothing can really beat that
And I thought I was being liberal by writing about a potential increase of 1000%
Such services are always priced cheap in the begginning in order to get people to use them, and when their market share is important enough (or when their clients can’t go back) they start upping the price to max out the benefits (and pay back the billions they owe to their early investors).
I think it’s even more complicated than that.
Based on the various reports where people claim that serverless is cheaper I suspect that they didn’t have that much traffic to begin with - so the always-on solution is wasteful. Serverless is flexible enough to handle traffic spikes - but it is going to cost you. At least you aren’t losing business (though your profit is going to take a hit).
- Why we switched from docker to serverless
- Forget AWS Lambda, so long Kubernetes - this is the future of serverless
But there is the very real possibility that if traffic increases steadily that eventually the serverless cost will exceed that of an always-on solution. So I guess you better be prepared re-architect your solution quickly - in case of unexpected success.
FYI: I encountered the PHP - FaaS parallel here.
I’d challenge the notion that serverless is actually simpler; granted there are quite a few services on the menu that save you from having to implement them yourself but those services often expose enterprise-grade complexity that still has to be understood even for simple use cases - and you still have to pay the same rate regardless of whether you are taking full advantage of the service’s flexibility.
And while the operations management overhead is reduced, there is still the issue of ongoing cost management, i.e. monitoring which parts of a solution are the most costly (e.g. API gateway) and being aware of cost effective alternatives while being ready to re-architect when the operational profile changes.
For example as Pricing pitfalls in AWS Lambda points out:
- Kinesis: $10.836 @ 1 msg/s, $47.088 @ 1k msg/s
- SNS: $1.296 @ 1 msg/s, $1296.00 @ 1k msg/s
- SQS: $1.0368 @ 1 msg/s, $1036.80 @ 1k msg/s
i.e. the “obvious choice” at the low end will cost you dearly if your throughput increases dramatically.
So it seems serverless is a viable option if:
- the solution will never see an extended period of relatively high volume traffic
- for “quickly” putting a business POC into production (provided the team is already well versed in the cloud vendor’s service offerings) with the understanding that the solution will have to be re-architected if the concept proves to be (too) successful.
In terms of switching costs between cloud vendors there is also the issue of data lock-in.
I don’t think serverless is even viable in your second case, as it doesn’t take much time to install a server and use it for POCs (and much less than rearchitecting the thing afterwards). But yes, it’s definitely great for low volume services.
We can always complicate the analysis if the question is whether serverless can be always cheaper. I think it could be, as those companies can benefit greatly from economies of scale, both in admin count and machine costs. So they should be way more efficient than any small to mid size companies (if not bigger ones), and thus be able to generate a profit whilst costing less than a custom solution.
But I think answering such a question is not really meaningful, as there is no reason that such a company would stay cheap if it knows it can earn more. So, as soon as enough clients will be locked in, as soon as competitors will be bought off, prices will rise up to and beyond the price of “serverfull” (not too much so people will continue paying for the serverless/hassle-free service, but still).
So I guess my problem with serverless is not so much technical than marketing…
A serverless service would only interest me if it was built around an opensource stack, with the (testable) promise that I could buy a server, install that stack and transition from one to the other in “a few” commands (of course the bigger the project the more difficult that would be, but it’s important the opportunity exists to ensure reasonable prices and policies).
I guess it depends but there are opinions to the contrary
- Serverless Isn’t About Cost Savings, It’s About At-Bats
- GOTO 2017 • Serverless + Modern Agile: A Match made in Silicon Heaven • Mike Roberts
A serverless service would only interest me if it was built around an opensource stack,
But even if the stack is standardized, vendors will try to couple you to the “value-added” services that are not part of the stack.
Serverless is great for intermittently-executed, independent, functions–like functions to manage & report on your cloud infrastructure. I think the use-cases for publicly-available services are very limited.
Sounds like OpenFaaS, and several other such things–they are popping up in various forms precisely because of the concerns you point out. (They vary in which cloud providers they support, some are tied to Kubernetes, some are not…)
Opensource stack or you can easy move between stacks …
Where do you run your own servers?
Just out of your home? Do you have issues with your ISP?
I have definitely been interested in running my own servers in the past but have been nervous about factors like ISP throttling/location/etc
I have a couple in california with one company and one in canada with another computer. In addition to a few at home I mostly just use for processing stuff and not for web hosting.
I don’t web host out of my house, so no.
Ah that’s awesome, so do you buy the hardware and then pay the company to hold it/hook it up to the network for you? That’s super cool.
Maybe I’ll look into doing that. Would you mind sharing the name of the company in California you use?
Nice topic about AWS ,maybe little of topic
Just dedicated servers or VPS’s. I use dedicated’s for things that need more power, and my sole VPS is just a front for an Object Storage backend.
If you want to play with that stuff like this I’d say try Linode or OVH, Linode is a bit more manage for you, OVH if you want to do literally everything yourself.