Live data from Hacker News

Back to the '70s with Serverless

evrl.com

131–140 of 310 posts

Re: Back to the '70s with Serverless

#131
post #96

Earlier quoted context omitted.

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?

Nah. Scalable design is good design. It forces you into thinking a level deeper about your app and forces you to use good architectures.

Re: Back to the '70s with Serverless

#132
He started out talking an out how a quick feedback loop was of paramount importance, and then got pretty far afield. Eventually he asserted that Serverless elongates that loop. Maybe so; I don’t know, I haven’t used it.

That a fast feedback loop is important was the only contention he made that I found important.

Re: Back to the '70s with Serverless

#133
I do not think that serverless is the thing that the author thinks it is. It's definitely not "batch", and it's definitely really cheap. I think that the fact that the author doesn't look at the economics of various deployment mechanisms is pretty revealing - within the first three hours of my first cloud engagement we were making faces about the costs of different options. To be honest this is the biggest preoccupation of every team doing cloud that I have looked after. It's also the reason (the only reason why business are going to cloud. If you can get 20% e-2-e soup to nuts savings that is fantastic but in terms of system architecture that's a very thin and high risk landing zone to aim for - it's really easy to screw up and get +20%. Serverless is one of the methods that can help a project drive overall costs under the line, and I say "good for serverless".

Re: Back to the '70s with Serverless

#134
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…

I find your quote here and the follow up seriously unconvincing. You know what a miserable workflow is? Preparing all my build scripts according to the half baked build tool that our in-house Deployment team cooked up to use fabric to spray my deployment onto a bunch of nodes in our data center, all the tests and script linting pass, so then I go push it through our CI/CD pipeline (which can’t do the above tests for…

Cool story, but the majority of that is not related to serverless. You still need a CI/CD pipeline with serverless and I’ve dealt with just as many miserable setups there.

> I can’t give the cloud providers my money fast enough

People run VMs and k8s on the cloud as well and run into every one of the problems you just described (aside from literal hardware failures).

Your rant seems to mainly be about having a good CICD pipeline and that’s not really related to cloud or serverless.

Re: Back to the '70s with Serverless

#135

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

> virtually infinite auto scaling

Ah, the bullshit. When we showed GCS engineers our hadoop workload, their eyes went really big and told us that they don't have that kind of capacity in a single AZ.

Re: Back to the '70s with Serverless

#136
post #67
post #17

My company is migrating a huge monolith to microservices. One of the proposed benefits is that it makes end to end testing easier because each service only interacts with a couple other services, so each service will be easier to write integration tests for. But in the monolith, those services communicate over interfaces, and are currently tested as unit tests! So we're replacing unit tests with integration tests and…

Reminds me of the tweet - we replaced our monolith with Microservices so that every outrage is like a murder mystery

I believe the technical term for a tightly coupled set of microservices is a 'distributed microlith'.

Re: Back to the '70s with Serverless

#137
post #69

Earlier quoted context omitted.

The business case is that you won't be able to retain good engineers if you refuse to rewrite your AS400 COBOL app.

I’ve wondered whether these good engineers are really a net benefit. They crank out something spiffy, move your big systems to it, and then disappear to work on the next hotness, leaving an already burdened tech team to support yet one more spiffy stack that is not quite as reliable or easy to use as we would like.

I think you need to either talk to your system architecture function or get a system architecture function in your organisation.

Managing this stuff is a job, and it requires discipline and organisation. It's one of the few functions of an IT department that is left once you go to cloud (as dealing with Oracle's bullshit is then gone). The younglin's doing development in the business functions have to play by the rules - and the business functions need to agree that there are rules or they will :

a) spend much monies on the issue you describe

b) get cracked open like fresh eggs by any passing hacker who is keen on sports cars

Re: Back to the '70s with Serverless

#138

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

> 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. I dunno, the first company I worked at was very small, under 30 people, sales included, and I was hired on as an SA. If they were using serverless, they would not have needed to hire me. Deployments and system upgrades were very toilsome. The dev…

I don’t think your past experience reflects current practice.

My reality at a 20 person shop with a few devs is much closer to the OP - a few hours setup (we save the cloud config and can remake servers in a few minutes), servers run for months without intervention, uptime is on par with cloud services, deploys take seconds. Managing servers or deploys just are not major problems for us.

Serverless is not a solution to deploy problems - mostly because they’re just not significant problems for us, if anything the dev deploy story is worse than renting VMs. It’s an interesting take on serving requests and I do believe some variant of it might be the future (a variant more like cloudflare workers IMO), but at present there are serious drawbacks and it is not clearly better, particularly when provided by a predatory company like Amazon.

Re: Back to the '70s with Serverless

#139
post #91

Earlier quoted context omitted.

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…

Your examples are poor. LetsEncrypt and certbot automated cert renewals a long time ago. If you’re still having to manually renew your SSL certs, you’ve picked a crappy vendor. Security updates are also as simple as a cron job that runs your favorite package manager update command. You want to run those commands on multiple machines? Use the several different FOSS orchestration platforms that make it easy for you to deploy and configure your distributed services. Sure, these things take some initial set up, but it’s nothing that can’t be accomplished in a few business days for a start-up.

Re: Back to the '70s with Serverless

#140
post #135

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

> virtually infinite auto scaling Ah, the bullshit. When we showed GCS engineers our hadoop workload, their eyes went really big and told us that they don't have that kind of capacity in a single AZ.

Then you are working at hyperscale yourselves already, and there are maybe 50 organisations like you out there.

Maybe.

Right now I don't think that there is a single telco that has the scale to break GCP, or a single manufacturing company (exempt Tesla) or a single energy company. Or bank.

I agree that pharma, social media and streaming may do this. But since Netflix is on AWS I am doubtful of the last.

Post reply on HN