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

Cloud Programming Simplified: A Berkeley View on Serverless Computing

rise.cs.berkeley.edu

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#31

Post by scarface74 »

mozey wrote: post #15
meekins wrote: post #14

Earlier quoted context omitted.

API Gateway becomes your HTTP server, your routing layer defined in Flask/Sinatra/Express & co is implemented in API GW integration configuration and handling routed requests is implemented as Lambdas that process events from API GW.

With AWS Lambda I try to avoid using API Gateway as it seems to me that is exactly where the lock-in occurs. Instead I have one catch-all route on API GW and I keep my routing layer in the app. This also makes it easier to run the app on dev without recreating the entire AWS environment

If you work for any size corporation, they aren’t going to just switch their infrastructure because a developer said that they pinky promise the migration will be easy.

You’re always for all practical purposes locked into your infrastructure once your business grows.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#32

Post by scarface74 »

TomMarius wrote: post #23
rlyshw wrote: post #9

>[serverless computing] closely parallels past advances in programmer productivity, such as the transition from assembly language to high-level programming languages Is this serious? The author seems to imply that we can just abstract away the entire internet in the same way we abstracted away copper wires.

But we did, didn't we? How is modern serverless different from shared LAMP hostings of the past?

Shared lamp hosting didn’t give you the security, scalability or isolation that lambda gives you.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#33

Post by scarface74 »

dman wrote: post #6
crazyforbytes wrote: post #2

Does anyone else not feel so good about a future of computing where everything but the application layer is rented from Jeff Bezos?

I agree with you on this, it is a moral dilemna I think about every day. Programming was one of the few professions where the practitioner owned/had access to their tools in their own spare time. Across history and professions this is a rare property, and I fear that we might lose this in the next 10-20 years. Disclaimer: Views expressed are my own and do not reflect any positions held by my employer.

What I have access to with AWS just using their always free tier and their cheap offerings is more than I ever could have dreamed of 5 years ago, let alone as a hobbyist in my bedroom doing 65C02 assembly in the 80s.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#34

Post by Cthulhu_ »

agentultra wrote: post #5

It’s also great for vendor lock in and rent extraction. At least in its current iterations. I’m fairly certain Amazon isn’t going to make it easy to run your “serverless” applications on anything but their infrastructure. What would be more interesting would be languages and runtimes that run on the next network that is distributed, peer-to-peer, and able to be trusted. And easier to program for than they are today i…

How is a .js file with a basic implementation of

  exports.handler = (event) => ({
    statusCode: 200,
    body: "Hello world: " + event.body
  })
vendor lock-in? You can hang this in an Express server yourself at any time. You can spin up your own three billion nodeJS servers yourself with this. The only thing Amazon does is hardware / instance management, load balancing and of course billing, which I don't see as vendor lock-in.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#35

Post by Cthulhu_ »

redisman wrote: post #8
coderintherye wrote: post #4

>We expect serverless computing to become simpler to program securely than serverful computing, benefiting from the high level of programming abstraction and the fine-grained isolation of cloud functions In my view, that's the really key bit. Securing systems is an endless task, even (or especially) if they are cloud hosted.

Right now serverless is definitely not simpler than a monolith. It's "simple" if you squint but any real workloads have you dealing with high concurrency for almost all tasks that a single monolith could handle with a single instance.

You are right and I'm glad you're mentioning it, and the general skepticism about serverless; it's not a golden hammer, its applications are limited, and not every problem should be (can be?) solved with a serverless architecture. The same goes for microservices, which is another gold hammer that people picked up and started to apply to a lot of problems - I've seen a few projects where microservices was the initial architecture, while all of those would've been better off with a monolith for the first two years of operation (before any significant load) to figure out the actual problem to be solved.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#36

Post by Cthulhu_ »

crazyforbytes wrote: post #2

Does anyone else not feel so good about a future of computing where everything but the application layer is rented from Jeff Bezos?

I feel fine; one of the main selling points of cloud computing (as will be imprinted on you if you ever do an AWS course, sigh) is that before, if you wanted to launch a product, you had to invest in a huge amount of hardware first - just look at the first few years of Twitter where they were struggling to scale up. I mean yeah you could (and can) get managed hosting, rent some servers still at a lot of providers, often for cheaper than at Amazon, but scaling those out is not easy at all.

Nowadays? If Twitter launched today they would have had no trouble scaling up from one user to a hundred million within weeks. AWS is a major (MAJOR) factor in the startup boom, and allows for crazy levels of scaling for new startups that attract a lot of users. If you set up your stuff right before launch, getting slashdotted (or the HN variant) is a thing of the past. The only limit to scaling now is your credit limit.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#37

Post by mitjam »

scarface74 wrote: post #29
meekins wrote: post #17

Earlier quoted context omitted.

The interface between Lambda and your business logic is usually very thin so in case of simple REST APIs migrating from platform (as long as the target platform has a compatible language runtime) to another or to be executed in a web app framework is rather easy. Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...

Cognito is just a standard authorization service that supports Oath 2.0, SAML 2.0, and OpenID Connect. It is a drop in replacement for dozens of other authentication providers.

Migrating away from Cognito is hard and involves end user participation as you can not export password hashes.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#38

Post by scarface74 »

mitjam wrote: post #37
scarface74 wrote: post #29

Earlier quoted context omitted.

Cognito is just a standard authorization service that supports Oath 2.0, SAML 2.0, and OpenID Connect. It is a drop in replacement for dozens of other authentication providers.

Migrating away from Cognito is hard and involves end user participation as you can not export password hashes.

It’s just the opposite of migrating users to Cognito.

If you are storing the passwords in Cognito and not using federated login, you should be able to insert a lambda trigger that captures the user’s password then authenticates the user with Cognito via code. Once the user is authenticated, store the password in your new store.

Yes that would be a slow process but it isn’t like you couldn’t move everything else off of AWS first and let that be a slow migration over time.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#39

Post by silverlake »

agentultra wrote: post #5

It’s also great for vendor lock in and rent extraction. At least in its current iterations. I’m fairly certain Amazon isn’t going to make it easy to run your “serverless” applications on anything but their infrastructure. What would be more interesting would be languages and runtimes that run on the next network that is distributed, peer-to-peer, and able to be trusted. And easier to program for than they are today i…

It's in the paper as the second fallacy. They recommend something like a POSIX standard for Backend-as-a-Service components.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#40

Post by zulrah »

agentultra wrote: post #5

It’s also great for vendor lock in and rent extraction. At least in its current iterations. I’m fairly certain Amazon isn’t going to make it easy to run your “serverless” applications on anything but their infrastructure. What would be more interesting would be languages and runtimes that run on the next network that is distributed, peer-to-peer, and able to be trusted. And easier to program for than they are today i…

Have you seen Kelsey's Hightower demo where he used s3 event as a trigger for Google Cloud Function? You can already use serverless providers that abstract your function from the provider, but of course in that case you're locked to that specific vendor.

Also, no licence stops you from migrating from Lambda at any moment. Other Companies have you to pay enormous licencing fees and lock you for a one year contract or even longer.

Post reply on HN