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

271–280 of 310 posts

Re: Back to the '70s with Serverless

#271

Post by t0astbread »

zelly wrote: post #90

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

I think the main selling point of Lambda (and most SaaS) is you don't have to worry about the machine running your code. Personally I haven't used it so correct me if I'm wrong but you don't have to worry about things like monitoring, network administration and security (beyond your code and general opsec).

Re: Back to the '70s with Serverless

#272

Post by mattgreenrocks »

memetherapy wrote: post #145

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…

We don’t teach people a technical aesthetic. So, lacking a strong internal sense of taste, they cargo cult it from the latest FAANG scraps thrown at them. This compounds with the conceptual disaster that is web apps.

The good news is there’s a lot more to software dev than webdev.

Re: Back to the '70s with Serverless

#273

Post by eightysixfour »

still_grokking wrote: post #256
eightysixfour wrote: post #234

Earlier quoted context omitted.

I am intimately familiar with the software and IT organizations of multiple airlines. You are wrong, they have large distributed software development teams building very complex software to run every part of the airline’s operations. Some buy off the shelf, others buy components off the shelf and focus on custom where they feel it gives them an advantage, and others have built the whole thing themselves.

So airlines were one of the first cloud users because they couldn't scale otherwise ? And they're doing "serverless" these days as their IT operations are a good fit for this paradigm? Or could it be that they're small enough to get things managed with off the shelf software and/or something built and run in-house?

Airlines have been running their own data centers and fully understand the costs associated with managing their own infrastructure and many have decided to migrate to the cloud because they have decided it is worth outsourcing that function, it is not a key competency and they cannot keep up with the pace of innovation in the IaaS market. If they look at their IT as a complete system, the extra costs of the cloud are offset in a number of key areas, including increasing their ability to scale.

You mention of the shelf software, what do you think the organizations that build the COTS stuff (like Sabre) in this industry look like? Where do you think it is run? They’re all moving to microservices and cloud hosting too, including serverless where they think it makes sense (and a lot of times when it doesn’t, just like everyone else).

The smart ones (who understand Conway’s Law) are making these moves because they are enablers of smaller, more independent teams which we know are better at delivering software. The really smart ones know they’re paying the price in increased complexity the comes with a distributed system, but are willing to pay it because that cost is lower than the cost of the collaboration necessary to build a monolith of that size.

Logistics companies are one of the most interesting intersections of software and the real world. Most organizations are making a mistake by focusing on scaling their software too early or unnecessarily. Airlines and logistics are not, they have business problems that their existing software cannot solve in areas the COTS options do not fit in their operations.

Re: Back to the '70s with Serverless

#274

Post by mattgreenrocks »

mjw1007 wrote: post #184
memetherapy wrote: post #145

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…

As far as technology goes, I think what we describe as "fashion" is often mostly caused by a desire for safety in numbers, and to a large extent that's rational. If I pick the same language or framework or whatever as everyone else, there's a better chance it won't be abandoned, and when I want to integrate with some other project, someone else will already have done a great deal of the work.

By the same token, people should stop expecting exceptional results if they used the same tools and processes as everyone else.

Re: Back to the '70s with Serverless

#275

Post by qz2 »

alisonkisk wrote: post #269
jacquesm wrote: post #257

Earlier quoted context omitted.

This is absolutely true. But shitty technology tends to have hard upper limits to scalability and shitty security tends to put hard upper limits on the company life span. It's interesting how established companies can have one security issue after another but the customers are so locked in they can't leave and so those companies are not nearly as affected as they should be (Equifax anybody?). But your run-of-the-mill…

What company has been harmed by shitty security on any sort of worrying timescale?

I worked for an online gambling startup that got owned on launch day and the investors pulled out the day after.

Thank fuck I was just a contractor and not a founder or shareholder.

Re: Back to the '70s with Serverless

#276

Post by chubot »

zelly wrote: post #90

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

Yeah, FastCGI is a little closer since it fixes the startup time problem.

It's weird to me that PHP uses FastCGI but Python support for it is really limited. I'm using FastCGI on Dreamhost and it was a pain to get it to work.

https://lobste.rs/s/9o4zsx/back_70s_with_serverless#c_9hxzjs

https://news.ycombinator.com/item?id=24683304

CGI and FastCGI can also be used with containers, although it appears that almost nobody does it.

I think if "bubblewrap" (user space container tool) starts to be installed on shared hosts via Red Hat, we could hack it.

Re: Back to the '70s with Serverless

#277

Post by chubot »

tannhaeuser wrote: post #108

> [XML] lacked all the facilities that apply to writing good code, so principles like “Don’t Repeat Yourself” went overboard and copy/paste programming ensued Technically, XML has entities (text substitution variables) and entity references, along with a evolved infastructure to share declarations and declaration sets via parameter entities. Of course, that doesn't help with tools such as maven which outright forbid…

As to FaaS, I don't see the problem with CGIs

I'm sympathetic to this view point, but a few problems:

(1) Startup time. FastCGI solves that, but it's a more complicated protocol that requires language support, unlike CGI.

(2) Language support and (web) framework support. Python's FastCGI support is kinda crappy; you'll probably see worse in other languages. Although I noticed Rust has some FastCGI bindings, so I guess people are still using it?

(3) Container support. This is probably the biggest one. All the hosting providers that I know of that support CGI or FastCGI don't give you root (for good reason), and they also don't support rootless containers (good reason 10 years ago, maybe not a good reason now)

So if shared hosting starts installing "bubblewrap" rootless containers on their machines, then we could build our own "serverless" FastCGI. But we can't really do it now.

I use FastCGI on Dreamhost, and I just tried it on NearlyFreeSpeech, and neither is quite adequate. It's funny how small a distance there is though.

https://news.ycombinator.com/item?id=25488958

https://lobste.rs/s/9o4zsx/back_70s_with_serverless#c_9hxzjs

Re: Back to the '70s with Serverless

#278

Post by nojvek »

Wow. All the bashing at kubernetes and serverless functions. I’m not sure what the point of the author was other than the complexity aspect.

K8s and containers solve some very painful problems. I’ve seen two multi month migrations to k8s and cloud-y systems from hard metal servers.

Hard metal is nice but it’s hard to guarantee that state between replicas is the same and there is no version discrepancy.

Everyone that moves to cloud is because they want a good balance between compute and storage. They don’t want to deal with figuring out how many servers to rent. Let it scale up and down as needed. When you care about 99.99% reliability you want redundancy and multiple replicas load balanced. You want prod to run what you staged and tested. You want isolation guarantees. You want ephemeral systems that can be recreated from scratch and destroyed easily.

If you’re just a couple of devs and you don’t care about multiple 9s of reliability and everything fits on a single server then yeah the cloud is not worth it. K8s is not worth it. Know thy tools and the problems they solve.

Re: Back to the '70s with Serverless

#279

Post by GrumpyYoungMan »

FpUser wrote: post #160
vntok wrote: post #141

Earlier quoted context omitted.

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…

I always have up to date standby for a fraction of money they spend on cloud. In the last 10 years or so I do not remember RAM failing in an unpredictable ways. When/if my SSD fails It'll take me a whole 10 minutes ordering another one from amazon. Oh and I always have spares lying around. My backups are automated. Anyways nice job advertising cloud and trying to scare people into using it. You happy with it - good f…

> "...I do not remember RAM failing in an unpredictable ways."

I'm about halfway through my career and I have seen something like that happen exactly once; the erratic behavior of the machine had my team scratching our heads for a fair bit until we ran memtest86 on it after running out of ideas. So I would say that it's not impossible, just extraordinarily unlikely.

The rest of your post I entirely agree with.

Re: Back to the '70s with Serverless

#280

Post by 1337shadow »

mlthoughts2018 wrote: post #261
1337shadow wrote: post #164

Earlier quoted context omitted.

I'm sure you will be able to setup proper pipelines on new projects within a 24h time frame and be brilliant at finding root causes by reading the stack trace and associated sources in the blink of an eye when you will be a senior hacker, I'm not worried about that! Anyway, I think your comment proves that once we decide to invest in something, our brain does everything it can to justify that choice, Human nature rea…

I don’t understand your comment. It seems like you think it carries a rhetorical punch to (I guess) suggest that in the cloud version we’d still be slow and make mistakes? The writing is so unclear it’s hard to tell. But if that is what you’re saying, I think you deeply missed the point. Yes of course my team won’t solve bugs instantly just because of cloud tools and of course we will make mistakes implementing bad i…

I don’t understand your comment. It seems like you think "anyone talking about the rip off cloud tools" are "exceedingly arrogant SRE types creating piss poor tooling that barely works, whining and complaining that they can’t support generalizing it, sitting in actual data centers, with a burnout mill with constant turnover on all the other teams". But apart from that, I'm sure you're a lovely person to discuss with ;) Anyway, I was just saying that senior hackers have more options than you seem to have, also that we tend to find excuses to justify our investments once we are locked in them, it's perfectly natural and nothing to be ashamed of.
Post reply on HN