[tonyarkles]

I’m asking this from a place of genuine curiosity. Since the whole serverless thing has been gaining momentum, I’ve been mostly working on embedded stuff and haven’t been back to see what the new hotness is over in web land.

What code gets eliminated in serverless? I have historically done most of my http backends using things like Flask or Sinatra or Elixir or Go (with net/http), and I’ve never felt like there’s a whole lot of code to begin with. What am I missing (if you don’t mind elaborating)?

[xrd]

I'm thinking of Firebase. For example, with Firebase, my web clients (web or Android, for example) don't ever talk to my backend directly. I have a serverless firebase function that accepts a trigger when there is an update to the firestore (cloud database) or storage (like AWS S3). I get a JSON object (which is declarative) that I can use to send the file or data on to a new process. This decoupling makes my firebase function really small: it only parses JSON and sends an event, perhaps to another Google service.

Compare this to a large application where you are marshalling objects from the HTTP POST request into temp objects inside your application language. Making that work with all clients, within all server contexts, is a lot of code which I hated to write.

With serverless, I'm never connecting my clients or backends directly. I'm thinking in terms of moving high level objects (JSON, files, events) between systems, and Google provides the glue to wire those together. It takes a mind shift, but when you realize how much glue code you are writing and that you can forget, it makes your application layer really simple.

[biztos]

I've only done a little bit of this stuff, but so far my impression is your code will get more complicated in AWS if you glue in Flask/Sinatra/etc. for the API Gateway, but can still get a lot less complicated if you "think serverless" and run fairly tight functions in AWS Lambda. The system then takes care of auth, request parsing, response formatting, and most of the other stuff you'd do in Flask, plus of course it eliminates the actual web-server layer.

The downside is that you then need to call them via Lambda instead of using some kind of REST API -- however at least in my case, this turns out to be the much lesser evil as I'm only using them internally, and have my own code that makes the calls. My "lock in" is that I would have to change that code, but it's trivial.

[meekins]

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.

[mozey]

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

[scarface74]

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.

[meekins]

You can absolutely do that. Then you just need to do more custom work to enable route level observability and metrics.