Comment by bob1029 | Hacker News Reader

Comment by bob1029 | Hacker News Reader

HTTP triggered cloud functions are my new favorite thing. They can evaporate complexity if you dance around the various vendors carefully enough. This is the only cloud-native abstraction that feels "end game" to me. I still haven't been able to deploy a cloud function and get the "runner" into a state where I'd have to contact support or issue arcane console commands. I've done well over 2000 deploys by now for just one app alone with a 100% success rate.

Performance is fantastic (using isolated app service plans in Azure), and I am completely over the ideological principals against per-request billing. Absolutely, you can do it cheaper if you own the literal real estate the servers are running inside of. Paying for flat colo fees makes per-request costs look ludicrous on the surface. But, achieving all of the other attributes of simple HTTP triggered functions in a DIY context is very challenging without also spinning up a billion dollar corporation and hiring 1k more people. Compliance, audits, etc are where it gets real super fast.

The "what about lock-in?" argument doesn't work for me anymore. HTTP triggers are a pretty natural interface to code against: "I've got a HTTP request for you to review, give me some HTTP response please". The only stuff that is vendor-specific are the actual trigger method signatures and specific contexts beyond HTTP, such as OIDC or SAML claims. You'd really have to go out of your way to design an HTTP trigger web app/API solution that is impossible to refactor for another vendor within a week or so.

If your business is a personal blog, then yeah I get it. It's more fun to buy a VM in Hetzner and get all artisanal about it. Also, if you are operating in a totally unregulated industry, perhaps you can make some stronger arguments against completely outsourcing the servers in favor of splitting hairs on margin vs complexity.

> But, achieving all of the other attributes of simple HTTP triggered functions in a DIY context is very challenging without also spinning up a billion dollar corporation and hiring 1k more people.

I literally rolled my eyes reading that. How do you think we did before cloud computing?

I am currently in charge of multiple teams scaling and deploying innovative applications for a large industrial company. We are using Azure for everything. Our cloud costs are insane for our number of users. I used to manage applications with ten times more user for one hundredth of the cost and less complexity. It’s billed to another part of the company which is responsible for this dubious choice (I really hope someone is getting nice business trips paid by MS so it’s not a complete waste) so I don’t care but how people can blindly put faith in the cloud is beside me.

…And you’re only one mistake away from the spam/abuse detection bot from locking you out of your account and shutting off your business for 12-72 hours.

For all the bad things I have to say about the cost, it’s still Microsoft. We have a direct line to them and they are here when you need them.

He said Microsoft, not Google.

For all of Microsoft's faults, you can get a person on the phone when you pay money.

There is a reason Microsoft kicks Google's ass all over the room in the enterprise space.

Interesting. When you say pay money do you mean as in paying for Azure resources, or paying EXTRA for somebody to pick up the phone?

He said Microsoft. Not Amazon.

I work in an extremely highly regulated industry and I don't understand your last sentence. It is in our best interest to run all our own hardware. We can't even take pictures in the office, there's an absolute 0% chance we're trusting a cloud provider with anything.

> extremely highly regulated industry

Which one? We are using this stack in fintech, and are subject to PCI-DSS, SOX, AML, SOC2, etc. Many of our customers (small US banks & credit unions) are very interested in this kind of cookie-cutter, cloud-native stack in 2023.

> We can't even take pictures in the office, there's an absolute 0% chance we're trusting a cloud provider with anything.

Sounds like you work for an F100. Our IT budget is 5 figures and we are doing business with clients who have 6 figure IT budgets at the high end. Forcing an on-prem architecture would make our solution less secure in most situations, especially for those customers who do not have the confidence to run a complex SAAS solution on their premises. Many of our customers actively understand this reality and are very open to the idea of offloading complexity to the cloud.

Ah, yes, also fintech, but different scale. The magnitude of our IT spend is very different.

> Forcing an on-prem architecture would make our solution less secure in most situations, especially for those customers who do not have the confidence to run a complex SAAS solution on their premises.

Yeah. I spent a couple of years at a billion-$ company in the telco industry which was subject to all sorts of US federal and foreign regulations (because they operated in 20+ countries.) They ran almost everything onprem, but seeing how that was managed, cloud would have 1000% more secure for them. At one point, the entire senior staff of the IT department was fired because of a security breach that was pretty clearly due to their poor decisions.

Companies do exist where their onprem operations do seem very secure, but you need really big budgets and good management to do that properly. Most places are not like that, even in the highly regulated spaces.

Sounds very similar to Optus breach in Australia.

This was a US company. Another fun thing that happened while I was there is that they had to throw out a major codebase and start from scratch because of security compromises, i.e. people working on it that shouldn't have been allowed to.

I suppose in the end they achieve a kind of security with this behavior, but it would be a lot better to avoid such incidents in the first place - which would be perfectly possible, with good decision-making.

I'd bet pharma or defense

Function is an ok place to host a simple api. But don't you require more things for your apps to be useful, like databases which add cost?

Yes the functions use Azure SQL Hyperscale for persistence.

> which add cost

We aren't interested in free. You get what you pay for.

>You get what you pay for.

I would say it's a somewhat weak correlation that breaks down completely if you consider a wider range of architectures. Back when Google was a startup "you get what you pay for" is what people running Oracle on Solaris would tell you.

And there was a sense in which it was true. There was no more reliable and feature rich way of scaling up. But starting something like Google on top of this egregiously expensive platform would have been completely uneconomical. It just wouldn't have happened.

And I think it's the same thing today. There are good reasons for using those egregiously expensive offerings from the largest incumbants but if you are starting something where servers are a significant cost factor then you are well advised to look at other options that are orders of magnitude cheaper, even accounting for labour.

> HTTP triggered cloud functions are my new favorite thing.

What exactly are you talking about? Request handlers in HTTP servers? Function-as-a-service cloud computing services? Plain old RPC?

What do your functions do? If some script kiddie comes along and decides to query you 10 times per minute, how long until the function becomes more expensive than a VPS?

They are authenticated via AAD and effectively serve various SSR web applications. You can't actually invoke our functions without passing authentication first.

I see. Where does authentication and authorization happen?

Authentication occurs in the IdP (AAD). Authorization occurs within our application based upon claims returned by the IdP. We don't rely on any AD-specific mechanisms to authorize users (i.e. security groups). We associate application-specific roles with the user principal name in our database.

This has inspired me, I never thought of serving static sites on lambda but it makes a lot of sense. Cheers!

But why would one need any backend logic to fulfill that? Just upload your static files to S3, enable static website hosting and youre done. Takes you a few minutes. Haven't worked with one of the other vendors but I'd assume it's equally trivial ;)

Here's the guide: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Hostin...

Sure, in this case I would just use GitHub pages. Hosting a site on lambda is just something to try lol

Even better if the lambda is coded in PHP /s

Reply on news.ycombinator.com