Live data from Hacker News

Back to the '70s with Serverless

evrl.com

91–100 of 310 posts

Re: Back to the '70s with Serverless

#91

For all its flaws in design or philosophy, cloud computing has a sweet spot. As an indie, lone dev, I can run my site, email and a basic web app for about 10 USD a month and, if my app kicks off, I can scale it to a million users without breaking a sweat. To me, that is the true power of the modern cloud computing paradigm. An influx of great apps and services enabled by cheap scalable and sweet competitive cloud ser…

Yes, albeit it was a bit more expensive. I was running multiple sites by myself. There was less encapsulation (unless you were working with someone on bsd), for sure, but I'd say the advantages are more visible in terms of security (hacking was much easier back then) than ease to deploy. Doing your own ops has never been that hard (YMMV) and I don't think it improved much nowadays. Scaling to n machines didn't change…

> Doing your own ops has never been that hard

I kind of disagree. It's doable, but still requires maintenance. For instance, even running a simple blog off of a VPS requires you to worry about setting up an SSL certificate and keeping it renewed, staying on top of security updates, and putting together some kind of scaling solution assuming you ever want to write a post which gets to the front page of hacker news.

I think there's definitely an argument at a certain scale to just outsourcing that complexity so you can actually work on what contributes to your unique value proposition.

Re: Back to the '70s with Serverless

#92

> Split your codebase, split your teams, create a lot of opportunities for mediocre coders to grow into mediocre engineering managers, everybody was happy. Too many companies have to hope of hiring the level of competence required to not suck. It's painful but true. AWS is cheap and serverless is popular when setting up a linux image security and correctly can take weeks or months.

Which is why it's great that server-less exists. I would much rather live in a world where a single developer can test out an idea in a way which will scale than where you need to hire from an expensive and scarce pool of dev ops engineers to get a product off the ground.

Re: Back to the '70s with Serverless

#93

For all its flaws in design or philosophy, cloud computing has a sweet spot. As an indie, lone dev, I can run my site, email and a basic web app for about 10 USD a month and, if my app kicks off, I can scale it to a million users without breaking a sweat. To me, that is the true power of the modern cloud computing paradigm. An influx of great apps and services enabled by cheap scalable and sweet competitive cloud ser…

Wait until you see the "data transfer" costs for what is basically or literally free from the bare metal/colo hosts. $10 is too much for what you're describing. You could be paying $0-$3.

Most users of the top public clouds are paying 2-10x more than they should just because using the public cloud "is what you do".

Re: Back to the '70s with Serverless

#94
post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

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…

Yes, "the cloud" is bunk from any technical point of view.

It exists to shift CapEx to OpEx for accounting. Any technical considerations are a distant third place on the list.

Re: Back to the '70s with Serverless

#95
post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

"You deploy, get an error message, and login to CloudWatch to see what actually happened - it’s all batch-driven, just like the bad old days, so progress is slow." Even without cloud APIs and containers and whatever, I find there's a creeping thing that happens here which has been helpful to become consciously aware of and intentional about fighting back on. Basically, the thing is that wrappers become interfaces. Yo…

You can solve anything by adding a layer of abstraction - except having too many layers of abstraction.

"Serverless" always reminds me of CGI/fastcgi, which was still a thing the last time I wrote web apps for money. It had the advantage of "scaling to zero" and could run a huge number of low-usage apps on a single 2000-era server.

Re: Back to the '70s with Serverless

#96

Earlier quoted context omitted.

Properly scaling a site is more than just clicking a button. Your architecture needs to have been built from the ground up in a way that actually can scale horizontally, for starters.

True. I made an assumption that the app is built that way. Of course, if te app architecture inherently unscalable, no amount of computing power or private servers is going to help.

> True. I made an assumption that the app is built that way. Of course, if te app architecture inherently unscalable, no amount of computing power or private servers is going to help.

Isn't it usually a mistake to design your app to be scalable to 10,000 users when all you may ever have is 10?

Re: Back to the '70s with Serverless

#97

Earlier quoted context omitted.

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.

When I used to work for an MSP, we would sell Dell servers to rural banking groups. We supported disaster recovery and high availability deployments. Any failed component, Dell would send us a replacement in less than 24 hours.

[deleted]

Re: Back to the '70s with Serverless

#99
post #88
post #31

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 the…

I can also imagine this approach having benefits as a consumer of services, but it's hard to imagine a world where vertical integration would not win over time. There's just too much of an advantage in terms of large cloud providers being able to optimize their hardware setups at data-centers to make their services cheaper, more performant, and more tightly integrated than 3rd party competitors.

I guess. But then Anthos, Arc, EKS Anywhere, they're all horizontal, and so it's odd that they are also all run by the cloud providers themselves. I'd think those services would be the next layer, run by different companies.

Still, what you said is right. I mean, heroku still exists, but the ever present complaints are that it's too expensive at scale and that it is too constraining. So, maybe the vertical is the best approach.

Re: Back to the '70s with Serverless

#100
Love the article and the perspective.

Don't think the general notion that serverless is either a return to the past or a negative development is true.

Long feedback loops seem to be more of an issue with a lack of engineering discipline where I've worked. Implementing a comprehensive, fast test suite is up to the team to build, not AWS. Serverless is a tool like any other that needs to be used in a responsible manner.

If you're using cloud features that geniunely cannot be tested locally or quickly I would reconsider using more stable technologies that are perhaps enhanced by your cloud provider instead of totally replaced by them. _You_ are responsible for creating a short feedback loop regardless of your deployment environment.

I've been using serverless in both GCP and AWS for many years now and have helped migrate mid sized startups onto those platforms for event processing and API build. In that time I've seen bills go from thousands of dollars to a few dollars a month.

Mid sized startups are now able to compete in data heavy fields precisely because of technologies like serverless that have enabled small teams to build scalable systems. When you work in transaction processing or analytics I think you'll understand that scalability directly limits how many customers your platform can support.

Not everyone just makes simple json http endpoints.

Post reply on HN