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

Re: Back to the '70s with Serverless

#141

Post by vntok » Sun, Dec 20, 2020, 8:59 AM UTC

FpUser wrote: post #43

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…

>"Invariably, their response has been to tell me that I just don't get it" I cured this one when my native server running on not so expensive multicore CPU with enough RAM left their cloudy setup in a dust performing more than a 100 times faster and still having huge potential reserve in vertical scalability. They were just astonished at what a single piece of modern hardware in combination with the native code could…

Congratulations, from now on you are on call 24/7 in case anything happens to that machine. It is now your own pet. When RAM fails in unpredictable random ways, you'll spend hours reading the syslogs. When your SSDs fail, you'll spend hours ordering new ones, setting raid up and migrating the backups you've had to provision, automate, supervise and secure yourself.

When the server gets even remotely suspected of having been hacked into, you must trash it overnight and never use any of it again.

Re: Back to the '70s with Serverless

#142

Post by vntok » Sun, Dec 20, 2020, 9:03 AM UTC

sgt101 wrote: post #140

pmlnr wrote: post #135

Earlier quoted context omitted.

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

Total & Aramco come to mind.

Re: Back to the '70s with Serverless

#143

Post by kfk » Sun, Dec 20, 2020, 9:08 AM UTC

Coming at this from data & analytics, my hope with serverless is to drive some management focus into the underlying data structures that support our applications. In Enterprise world when software grows the hard thing to do is integrations and data management. Take some of the major offenders in these 2 categories - SAP and Salesforce - the challenge is how to make these systems talk to other systems AND get some meaningful analytics out of them. SAP can't even talk to itself sometimes due to incompatible deployments across subsidiaries (this happens a lot when companies do m&a). I don't quite like serverless either but there is an area, databases, where it's going well and it might push companies to take better care of their data. Having 1 scalable Aurora (Postgres) database in AWS serving multiple microservice applications is a data analytics dream - entities, tables, users would be all automatically integrated by default. Running databases is super hard, so maybe removing friction with serverless can push companies to reconsider the absurdity of spending millions for crap like SAP and Salesforce whose main goal is to lock your data in their systems.

Re: Back to the '70s with Serverless

#144

Post by grey-area » Sun, Dec 20, 2020, 9:08 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.

The choice is not only serverless or hosting on bare metal - there are a lot of options in between. You can hire VMs and have the vendor transparently deal with hardware faults for example without downtime. Running your own VMs doesn’t mean running your own hardware.

The original claim is not at all unrealistic, I’ve been running a small shop with about 20 VMs without issues for years, uptime seems to me about comparable with serverless or hosted services from big players who regularly have small outages and there really is very little work involved.

Re: Back to the '70s with Serverless

#145

Post by memetherapy » Sun, Dec 20, 2020, 9:08 AM UTC

One thing that surprised me as a latecomer to software development coming from a visual arts background is how much choice of technology and working practices are purely fashion driven. The thing about fashion is that the way if develops is largely arbitrary. Changes in fashion resemble a drunken walk through possible design space with the drunkard receiving regular shoves from "influencers" who are usually trying to sell you something. Occasionally you have a fashion "revival" where someone takes an idea from the past, gives it a new spin, and then sells it back to newcomers as the next big thing.

This seems especially true in the types of startups and companies many HN readers work at or aspire to join / build - that is ones which are low stake / high reward.

I think when you combine the low stakes nature of the VC driven startup world with its cult of youth and the in group conformity of young people this is what you get.

[1] by low stakes I mean no one will die and you won't be prosecuted if your single page app startup goes tits up. Indeed you're supposed to "fail fast" precisely because the cost of failure is so low. Even if a VC or angel has invested a few million in you, to them that's still low stakes because they exist on an entirely different plane of wealth and you are just one of multiple bets.

[2] We're going to rebel by all dressing the same but not the same as our dad!

Re: Back to the '70s with Serverless

#146

Post by diveanon » Sun, Dec 20, 2020, 9:23 AM UTC

sgt101 wrote: post #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 preoccupat…

An example of this is how lambda millisecond resolution has given me a clear reason to push for code optimization as costs savings initiative.

Previously it was harder to budget for that kind of work, but now there is a clear target and roi.

I think most of the people in this thread don't really see the actual savings these services provide.

I hired 5 new devs last year off of what I saved by moving to lambda from eks / ec2.

Re: Back to the '70s with Serverless

#147

Post by diveanon » Sun, Dec 20, 2020, 9:34 AM UTC

jamesappledev wrote: post #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…

Thank you for providing a more nuanced answer.

I definitely agree that feedback loops, local dev, and testing are the things I hear about people struggling with.

For the most part that is a one time cost that your team can breeze through if you invest some time in initial setup.

If anyone out there is looking for a painless transition take a look at netlify and vercel. If you outgrow them later there is minimal lock in.

I also use pulumi for infrastructure mgmt, and it works extremely well as a lambda dev pipeline that manages complex stacks with ease.

Re: Back to the '70s with Serverless

#148

Post by diveanon » Sun, Dec 20, 2020, 9:35 AM UTC

hnechochamber wrote: post #28

ah yes, the 1970s where you could sit on your laptop at home, go to a cloud providers website, copy paste your code and launch an app in minutes. This guy is trying too hard to sound smart.

I'm probably the same age as this guy, the article definitely made me roll my eyes a few times for this exact reason.

Re: Back to the '70s with Serverless

#149

Post by diveanon » Sun, Dec 20, 2020, 9:40 AM UTC

echelon wrote: post #14

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

If it is overly complicated for you don't use it.

However discounting it altogether because you don't need or understand why that complexity exists is naive.

I hear this a lot in interviews and it's a clear signal that you haven't worked on anything big enough yet.

Re: Back to the '70s with Serverless

#150

Post by chousuke » Sun, Dec 20, 2020, 9:41 AM UTC

vntok wrote: post #141

FpUser wrote: post #43

Earlier quoted context omitted.

>"Invariably, their response has been to tell me that I just don't get it" I cured this one when my native server running on not so expensive multicore CPU with enough RAM left their cloudy setup in a dust performing more than a 100 times faster and still having huge potential reserve in vertical scalability. They were just astonished at what a single piece of modern hardware in combination with the native code could…

Congratulations, from now on you are on call 24/7 in case anything happens to that machine. It is now your own pet. When RAM fails in unpredictable random ways, you'll spend hours reading the syslogs. When your SSDs fail, you'll spend hours ordering new ones, setting raid up and migrating the backups you've had to provision, automate, supervise and secure yourself. When the server gets even remotely suspected of havi…

You talk like using a physical server somehow prevents building a highly available system or from using automation. Why would the hardware be any more of a pet than any random VM in the cloud? You could also just run a hypervisor on the host and get the benefits of virtualization along with full control of hardware.

Sure, if a drive breaks you'd probably want to replace it instead of just replacing the entire machine; it's a thing you don't need to do with VMs, but that doesn't mean it's difficult. It definitely doesn't take "hours".

Managing physical setups is different from managing fleets of cloud instances, but it's not necessarily automatically inferior.