Back to the '70s with Serverless • Hacker News Board

Re: Back to the '70s with Serverless

#81

Post by eightysixfour » Sun, Dec 20, 2020, 5:55 AM UTC

still_grokking wrote: post #36

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…

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.

Depends on how you define product, there are a large number of tech enabled Fortune 500s that do not sell a tech product but have built an integrated internal product for their operations that do need that scale. Airlines for example.

But yes, I agree that most companies jump to this level of complexity too quickly.

Re: Back to the '70s with Serverless

#82

Post by still_grokking » Sun, Dec 20, 2020, 6:00 AM UTC

travbrack wrote: post #66

still_grokking wrote: post #30

Earlier quoted context omitted.

I don't think burning in sum hundreds of billions of Dollars (or even more) because "it's OK being irrational, because emotions" makes sense.

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

I'm not sure I would call people that would rewrite something just because it gets boring otherwise as "engineers". I think the proper term would be "children".

Re: Back to the '70s with Serverless

#83

Post by daniellarusso » Sun, Dec 20, 2020, 6:02 AM UTC

empthought wrote: post #39

jiggawatts wrote: post #32

Earlier quoted context omitted.

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

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.

Re: Back to the '70s with Serverless

#84

Post by winrid » Sun, Dec 20, 2020, 6:02 AM UTC

thethethethe wrote: post #41

mattmanser wrote: post #8

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…

You don't even need serverless for those things. Any of the automated deployment/orchestration systems in the last ten years solve those problem (ansible, terraform, etc).

Re: Back to the '70s with Serverless

#85

Post by still_grokking » Sun, Dec 20, 2020, 6:09 AM UTC

eightysixfour wrote: post #81

still_grokking wrote: post #36

Earlier quoted context omitted.

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.

Depends on how you define product, there are a large number of tech enabled Fortune 500s that do not sell a tech product but have built an integrated internal product for their operations that do need that scale. Airlines for example. But yes, I agree that most companies jump to this level of complexity too quickly.

Airlines? How many billions of flights and passengers do you have to manage daily as an airline? Don't forget, computers are fast.

Also I think airlines do just fine on core system form the 80'ies until now. They also don't tend to have software development teams with "hundreds or thousands" of people to my knowledge. So maybe not a good example.

There is only a hand full of companies globally really in need of all that "serverless" stuff as I see it.

Re: Back to the '70s with Serverless

#86

Post by skohan » Sun, Dec 20, 2020, 6:12 AM UTC

perfectspiral wrote: post #21

thethethethe wrote: post #15

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

I think "scaling from zero" is actually the more interesting part of server-less. With AWS for example, it's super trivial to get a lambda running: no EC2 instance size to choose or elastic IP address to set up. You don't even have to choose a back-end framework, or set up monitoring to make sure your system stays available. You can just start writing code directly in the console the very first hour you start your project if you want, and already have a functioning API.

When you're working on your MVP, you can skip dev ops completely and get your infrastructure cost very close to zero. Then if you actually do end up building a product which is fortunate enough to have to worry about scale, you can work on cost optimization. I think this is a very relevant and valid use case for server-less.

Re: Back to the '70s with Serverless

#87

Post by tluyben2 » Sun, Dec 20, 2020, 6:14 AM UTC

empthought wrote: post #22

mattmanser wrote: post #8

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…

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

You do not notice that either with the right setup. I also rather hire a good SA and pay 10-100x less monthly (for which I can hire an army of devops here in the eu by the way) with the risk of all hardware dying at the same time (which does not happen, not now, not in the 90s when I started hosting).

Sure serverless etc has it's upsides and in that case I do use it, I just encounter close to 0 companies per year that need it or benefit from it. Aws ways benefits.

Re: Back to the '70s with Serverless

#88

Post by skohan » Sun, Dec 20, 2020, 6:19 AM UTC

daxfohl wrote: 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.

Re: Back to the '70s with Serverless

#89

Post by mikepurvis » Sun, Dec 20, 2020, 6:20 AM UTC

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…

"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. You write tool A, and then tool B, and then some kind of script C which calls the two tools and produces a result. Then someone says "dang, so convenient", and sets up a Jenkins/Rundeck/Airflow/whatever job that runs script C against some source of inputs automatically— maybe there's even a parameterized build capability where arbitrary inputs may be submitted to it on demand.

Before you know it, the fact that the original tools and script exist has been forgotten, because everyone's interface to this functionality is a handy webpage. And when someone wants to add more features, they don't even go back and change the script, they end up just adding it directly into the job definition. Before you know it, the full scope of what is being done on "the system" isn't even really available any more to be installed, invoked, and tinkered with locally, not in a meaningful way, anyway.

It's not even necessarily all bad, but when I see this happening in a domain where I have the awareness of the underlying tools (or I may even have written or contributed to them), I do try to help demystify them by writing up docs on how to do the local setup, helping others get going with it, etc.

Re: Back to the '70s with Serverless

#90

Post by zelly » Sun, Dec 20, 2020, 6:25 AM UTC

You can still get "scale to 0" with cgi-bin applications. Yes, it's old (but it works). Yes, it's slow (so is Lambda).

Unlike Lambda, CGI works on any web server and any OS. It's also extremely easy to mock because the input and output is stdin/stdout, not AWS API invocations that cost money every time you run.

What you miss out on is "scale to infinity" (read: your bill goes to infinity too).