Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Back to the '70s with Serverless

evrl.com

Post reply on HN
Print view View original

11–20 of 310 posts

Re: Back to the '70s with Serverless

#11

Post by tyre »

cs702 wrote: 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 think what’s important to remember is that these kinds of “truth” are not the full story.

Yes, a technology probably won’t live up to its marketing.

Yes, what works is probably good enough.

Yes, changing has switching costs and sacrifices institutional knowledge.

Yes, we’ve seen these technologies before and switched away from them from various reasons.

That’s all fine and sometimes frustrating as an engineer. But it’s not the only reason decisions are made.

Sometimes pitching your exec team on The New Hotness gives cover for changes that actually do need to happen.

Sometimes adopting The New Hotness is marketing to recruit engineers who want to try something new.

Sometimes adopting The New Hotness is because some people are bored and uninspired in their jobs and just want to believe in something good again.

The success of things like MongoDB and blockchain are not because they are better or even very good at most things people use them for. They’ll never live up to the hype. But people need things to get excited about. It’s psychological. Attacking them purely on technical points can lead one to miss the actual point.

Re: Back to the '70s with Serverless

#12

Post by eightysixfour »

While 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 together to support a business there is some types of complexity that are inescapable. So the question is “where do you want the interfaces between people and teams?”

SOA and microservices push that interface to the API layer which drastically increases the complexity of the code, but is a logical place to put the complexity if you consider the organization, people, and code a single system.

Re: Back to the '70s with Serverless

#13

Post by waheoo »

mattmanser wrote: post #8
cs702 wrote: 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…

Makes me think of those old "Webscale" skits on YouTube.

Re: Back to the '70s with Serverless

#14

Post by echelon »

"Cloud is the new mainframe"

This is the message we've needed.

Cloud is an expensive, overly complicated, lock-in boondoggle.

Open source needs to rally hard to prevent cloud providers from running their tech.

Re: Back to the '70s with Serverless

#15

Post by thethethethe »

> 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, virtually infinite auto scaling, automated deploys, arbitrary runtimes, ability to spin up code in multiple regions around the world with zero operational overhead, the list goes on...

These are non-trivial things. You’d have to pay engineers to build the same systems provided by serverless if you want smooth deployments and high availability. Also, imagine if you wanted to start operations outside of the continental United States. You’d need to find a data center provider, buy machines, pay someone to install them (and hope they do it correctly), and then, when ever you have a technical problem, you need to email the datacenter team to have someone plug in a KVM with 5 seconds of lag so your engineers can debug, and then you have to pay admins to constantly maintain the servers, and consistently pay for their rack space even if they aren’t being fully utilized. None of this is a problem on a fully managed serverless platform.

This article is just click bait capitalizing on FUD in the software community. Serverless will be a part of the future of software infra whether luddites are mad about it or not

Disclaimer: I work on serverless products so I am biased

Re: Back to the '70s with Serverless

#16

Post by v4nd0ck »

This is stupid. If you don’t recognize the benefits of serverless of the capabilities of this you shouldn’t be writing about it. Go back to retirement if you remember the 70s. Maybe you would have laughed people out the door in 2000 but that doesn’t mean you by any means are right. Serverless doesn’t add complexity but provides a service that manages everything for you without having to manage scaling manually. This provides ease of use across teams and also consistency which is not found in self managed servers across any size of organization.

Re: Back to the '70s with Serverless

#17

Post by daxfohl »

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 calling that a win because our integration test coverage is higher.

Re: Back to the '70s with Serverless

#18

Post by l0b0 »

> XML, however, was universally rejected in favour of things like JSON, Yaml, HCL, Toml - all free of structure, with zero indication whether a computer would find your prose gibberish or the next Shakespeare play until you actually pushed your code to some test cluster.

There are a few fundamental differences between these languages, but it's just plain wrong to say that any of them are not "structured." Did OP mean "schema-less" instead? Because the only fundamental difference at that level is that XML has a built-in mechanism for metadata referring to a file's own schema, while in JSON (and I believe the others, even though I've used them less) the schema is not linked from within the file itself. You can still verify the schema of these languages, though, just as you could with XML. And once you've verified the schema, local code can do stricter validation to make sure things hang together properly, that values are within limits, and so on. After that, I expect modern tools like Terraform and CDK to check with the target platform that the scheduled change can be applied before trying to change anything.

That said, OP has several valid points:

- Many projects try to make a microservices architecture long before it's needed, even in projects where it might never be needed. I suspect some people think microservices are actually easier to maintain, since they are smaller pieces, but only extremely trivial or shoddy microservices will be easier to maintain than a corresponding monolith, because many things which are well-understood in a local setting are much harder to do in a highly distributed setting, simply because the infrastructure is now a bazillion separately managed pieces.

- The feedback loop can be abysmal. Without any easy alternatives to do "local cloud" deployments, having to wait for several minutes for feedback about a tiny change is frustrating in the extreme.

Re: Back to the '70s with Serverless

#19

Post by xupybd »

eightysixfour wrote: post #12

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

I think you're correct but I also think the article is correct.

At scale there are levels of inescapable complexity. There are a lot of tools that help manage this complexity. However too many in smaller teams emulate bigger companies and inject wasted complexity by using tools that solve problems they don't have.

Re: Back to the '70s with Serverless

#20

Post by GartzenDeHaes »

tybit wrote: post #2

So in the 70s you could pay per request billed to millisecond precision? Wow times haven’t changed at all. He has some good points on poor configuration languages and bad architecture, but it’s lost in the rant.

Mainframes were (and still are) billed by fractional second of CPU usage, total storage, bandwidth between storage and compute, bandwidth off box, total number of jobs scheduled, and per-use fees for third party tools such as sort, RPC servers, and such. So times literally have not changed in this regard.
Post reply on HN