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.
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).
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).
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.
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.
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).
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…)
There’s some good info about dedicated servers here:
Generally if you want to rent a server you will want to google ‘dedicated servers’, or if you want to buy your own server and have a datacenter host it for you you will want to search for ‘co location’.
I would say most people opt to rent, as the hardware is covered by the company. If you co-locate, any issues with hardware must be sorted out by yourself or by paying the datacenter.
The funny thing is years ago the best option and the most expensive option was dedicated servers (as opposed to cloud). I personally feel the best option is still dedicated servers, but nowadays, it’s actually cheaper than cloud - if you are spending over $100 a month. However, it does involve more set-up and maintenance - as you do it all yourself (it’s almost become a bit of a lost art - as not many people run their own servers now, at least not as much as before).
Am I the only one seeing the issues “between the lines”?
We’ve had JEE vs .NET - how did that work out? AWS vs Google Cloud vs Azure vs the other guys is magnitudes larger in terms of skills fragmentation - it’s in the interest of the providers to de-commoditize the services and make skills less transferrable.
After cloud skills: ECS, RDS, Cloud Front, Route53 - skills that largely don’t translate outside of the context of AWS - i.e. these aren’t “cloud skills” but skills specific to AWS products.
J2EE collapsed under its own weight due to its complexity which is dwarfed by the complexity of the product offerings of these “cloud” vendors.
Back in the J2EE/.NET era we had in 2002 Patterns of Enterprise Application Architecture trying to document established architectural approaches in 18 chapters and 510 pages. I can only imagine how painful it would be to try to extract the commonalities between the major service provider offerings to assemble Patterns of Cloud Application Architecture. In a way the commercialization of the “Cloud concept” seems to mirror the tool vendor frenzy during the SOA era - which ultimately gave Service Oriented Architecture a bad name, destroying the WS*-tool market - and SOA was later reborn as “microservices” (do we have “microclouds” to look forward to?).
There is another reason why mastery of the product catalog is important - if you are using the wrong product for your needs you are likely paying through the nose because you are either underutilizing an expensive service or paying too much for each transaction (e.g. ECS vs AWS-lambda).
Forcing more vendor product knowledge/mastery onto software developers isn’t likely going to improve “business solutions”. Business solutions improve when developers start to understand the “business domain” better (either because they specialize in one domain or because they are adept in analyzing the domain under development).
Yes I agree that these some cloud vendor specific stuff. Some ok with this and some will try some level of abstraction like run kubernetes over AWS .
From other hand days when developers lived on own bubble (works on my machine, now is your problem) are ends.
Now days teams are responsible for full cycle developments: code, deploy run on production.
So you need to monitor service on production, gather metrics, and is something goes wrong on production you will get call :). This is your service and your problem know. Better to know as much as you can on what
environment your service is running.
And everybody know write or use distributed systems …