I'd be curious how thing would look if the cloud providers broken up horizontally. Like, if the companies that provided VM's were different from the ones who provided higher-level services. That's kind of how it was originally with Heroku and its add-ins, and AWS/Rackspace. I liked that so much better and wish it stayed that way. If you want a VM, go to Rackspace and knock yourself out. If you want a hosted thing then go to Heroku, or whichever service hosts things in the language of your choice. But the point is, you make a choice, when you sign up for whichever service, what level of the stack you want to operate in.
Back to the '70s with Serverless
31–40 of 310 posts
Re: Back to the '70s with Serverless
#32Earlier quoted context omitted.
Everyone's chasing "scalable", mostly for no reason at all. There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. And that hour or two is often less than…
> A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. Right up until something crashes or some hardware fails.
> Right up until something crashes or some hardware fails.
Unlike the public cloud where Nothing Ever Goes Wrong (tm).
There are never brownouts.
There are never latency spikes.
No undocumented quota limits.
Documented but confusing quota limits.
Unexpected performance issues caused by other customers.
Forced upgrades.
Forced patching.
Shock bills.
No siree Bob, that kind of thing just doesn't go on in the public cloud! It's all rainbows and unicorns....
Re: Back to the '70s with Serverless
#33> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…
Why is the alternative to serverless, colocating servers in a DC? The alternative is renting VMs from those same clouds. It works fine and is cheaper when you work on software that actually has users. It also doesn't result in the cloud provider cramming a crappy under-baked programming model down your throat. Per request pricing and "scaling to zero" is just old fashioned unbundling. You are selling a smaller quanti…
> Why is the alternative to serverless, colocating servers in a DC?
Because that’s what the author was comparing it to. Yes you can rent vms, and that works for many workloads. However serverless platforms provide other benefits like deployments, load balancing, and auto scaling that you’d need to setup yourself on raw vms. Plus, with services like AppEngine Flex you can run serverless on vms to cut costs if you have consistent traffic.
> Per request pricing and "scaling to zero" is just old fashioned unbundling. You are selling a smaller quantity of a product at a higher unit price and putting a bit of lipstick on that pig to convince people they are not getting hosed.
It really depends on your problem. Sometimes you might have a very low QPS service (like maybe a few QPH) and running a whole vm would be overkill. Some business have really bursty traffic and maybe some regions won’t get any traffic at all during the night but they still want to deliver low latency service to the people living on that side of the globe. Additionally, these are just reasons to serverless for scale to zero and ignores other benefits, like reduced operational costs, that business can use to justify paying more for compute time.
There are lots of reasons to use and not use serverless for compute. I don’t think it is the solution for everyone and everything, but I do think the hate and FUD directed towards it is unwarranted and uniformed.
Disclaimer: I work for Google, opinions are my own
Edit: typos and disclaimer
Re: Back to the '70s with Serverless
#34Earlier quoted context omitted.
Everyone's chasing "scalable", mostly for no reason at all. There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. And that hour or two is often less than…
Makes me think of those old "Webscale" skits on YouTube.
Re: Back to the '70s with Serverless
#35I'd be curious how thing would look if the cloud providers broken up horizontally. Like, if the companies that provided VM's were different from the ones who provided higher-level services. That's kind of how it was originally with Heroku and its add-ins, and AWS/Rackspace. I liked that so much better and wish it stayed that way. If you want a VM, go to Rackspace and knock yourself out. If you want a hosted thing the…
[deleted]
Re: Back to the '70s with Serverless
#36While I think this article is a great discussion about the increasing complexity of software and how the trends driving that complexity are marketed, but I think any article discussing these trends without also talking about the organizational structures of the teams delivering and running the code miss the point a bit. When you have an organization with hundreds or thousands of developers delivering code that works…
Most organizations don't have hundreds or thousands of developers working on some coherent product.
In fact this is quite seldom. So all the tech that solves problems that occur in such constellation should be quite exotic.
But it isn't. The reason is that computing "on a mainframe" (the cloud) can be sold orders of magnitude more expensive. The rest is marketing of the mainframe owners.
Re: Back to the '70s with Serverless
#37> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…
lol. You are totally conflating 'serverless' with using the cloud, period.
Not going with Lambda in AWS doesn't mean you can't use EC2, EKS, ECS, Elastic Beanstalk, and so on and so forth. You're the one spreading FUD.
Re: Back to the '70s with Serverless
#38Earlier quoted context omitted.
> A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. Right up until something crashes or some hardware fails.
> Right up until something crashes or some hardware fails. Unlike the public cloud where Nothing Ever Goes Wrong (tm). There are never brownouts. There are never latency spikes. No undocumented quota limits. Documented but confusing quota limits. Unexpected performance issues caused by other customers. Forced upgrades. Forced patching. Shock bills. No siree Bob, that kind of thing just doesn't go on in the public clo…
You have all that DIY too, except maybe shock bills, but it's your problem to fix. Like with everything, extremes are bad and all managed or all unmanaged are both bad. My personal guideline is use off-the-shelf services if they are cheaper than DIY, including labor, or if DIY provides no competitive advantage and off-the-shelf is cheap enough. But if DIY is much cheaper or gives a competitive advantage, do it yourself.
Re: Back to the '70s with Serverless
#39Earlier quoted context omitted.
> A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. Right up until something crashes or some hardware fails.
> Right up until something crashes or some hardware fails. Unlike the public cloud where Nothing Ever Goes Wrong (tm). There are never brownouts. There are never latency spikes. No undocumented quota limits. Documented but confusing quota limits. Unexpected performance issues caused by other customers. Forced upgrades. Forced patching. Shock bills. No siree Bob, that kind of thing just doesn't go on in the public clo…
I fail to see how this supports your claim that you can get by with "a few minutes per month" of devops. In fact, it's a classic red herring.
Your original claim is quite unrealistic and you'd do well to retract it. It's bad advice both for public cloud and for self-managed efforts alike.
Re: Back to the '70s with Serverless
#40A lot of truth in this article, but dont get me wrong, the added complexity is what is fuelling the market and we are all parts of this.
I dispute that I am a part of this. HN is a big "we" - you don't get to include everyone here in your "we".