AWS Lambda: a few years of advancement and we are back to stored procedures

This is just a product of bad design

A better approach would be to decouple all your business logic and provide an interface to it.

e.g.

    MyBusinessLogic
        doSomeBusiness

    MyLambdaRequestHandler
        - handleRequest
          - call myBusinessLogic.doSomeBusiness

It's pretty well established that Amazon's usual approach is to provide a "toolbox" of services that can used to build any number of app architecture permutations, without all the typical fluff and polish expected by large business customers. I for one, as an engineer, appreciate this model since it's much more accessible and lightweight.

One way to avoid that is to use web frameworks based on AWS Lambda, such as Zappa - https://github.com/Miserlou/Zappa

It seems to me (from reading HN) like most people are avoiding using App Engine because Google tortured and killed their pet, err, I mean cancelled Google Reader three years ago.

(And I guess, the inference is that because Google killed a tiny unprofitable service once in the past, you can not realistically depend on them to continue to provide services they are actually putting real money into because it is of strategical interest. Yeah, that makes total brogrammer sense, let's go with that line of thinking.)

I worked with Lambda a lot, piping the JSON input into Go programs and I cannot be more happy with something.

I work with Go just like I am used to, testing, compiling, CI and everything and then, I have a shell script that deploys it to Lambda (uploads the zip).

For what I need, lambda is absolutely great!

> In traditional PaaS world the code is the indisputable protagonist (oh, damn, and you also happen to need a persistent data service to store those transactions BTW). > With Lambda the data is the indisputable protagonist (oh and you also happen to attach code to it to build some logic around data). > A few years of advancement and we are back to stored procedures.

I don't agree at all. Lambda is code. It's code that is invoked upon receiving certain kinds of data, but in no way is the Lambda code subservient to the data, or (unlike stored procedures) even colocated with it. Lambda still needs persistent data services to play with persistent data -- there's nothing magic about it.

> There also have been a lot of discussions as of late re the risk of being locked-in by abusing Serverless architectures (like Lambda). > There is some truth to it. This, however, isn’t due (too much) by how you write the code from a syntax perspective: while coding my Python program I noticed that when the function is run in the context of Lambda, the platform expects to pass a couple of parameters to the function (“event” and “context”). I had to tweak my original code to include those two inputs (even though I make no use of them in my program).

The author describes having to write a controller method. This is not surprising, considering he was trying to make a web service.

> So, IMO, the lock-in will not be a function of how different the syntax in your code will be Vs. running it on a platform you control (probably minimally different) but rather in how scattered and interleaved with other services your code will be (at scale).

This is the most cogent point in the article. API Gateway + AWS Lambda can be used to create micro-microservices. Serverless Framework tries to wrangle this potential complexity by allowing users to group related lambdas/endpoints as a whole, but there is still the opportunity to create a real rat's nest of logic if we're not careful.

> P.S. Yes, I know that it’s called “Serverless” but it doesn’t mean “there are no servers involved”. Are we really discussing this?

Yeah, obviously servers are involved. But the fact that I don't have to care about those servers nearly as much (in terms of maintenance or in terms of up-front cost -- both are big wins for most customers) is worth discussing.

Is it the right architecture for everything? Hell no. System architects are in higher demand than ever because there are so many freaking ways to build technology products these days, and it's their job to figure out what tech is right for the job.

But the critical point is that Lambda is distributed and massively scalable, and stored procedures weren't.

Remember that company, Sun? The one that invented Java? When it was still alive, it has an unofficial motto, "the net is the computer". Nobody understood it then; now we know.

All computing science achievements will now be reproduced in distributed environment. OS? Check (AWS/DCOS/Kubernetes). Filesystems? Check (IPFS). IPC? Check (REST/Websocket). Perhaps even "drivers" will be a new thing (for IoT devices).

They give you decent primitives: immutable versions, aliases, easy logging. But everything else you have to build yourself: You have to figure out a development loop, deploys, configuration management. There is nothing built-in to help coordinate lambda deploys across regions.

I expect that you'll see this built out more this year.

Is this sentence was written in double speak or did I just have a stroke?

There's nothing fundamentally wrong with stored procedures, per se. What was wrong with SQL RDBMS stored procedures was that:

1. each DBMS had its own stored-procedure programming language—and so application frameworks that wanted to provide compatibility with the generic idea of a "relational database" couldn't really use them unless they had devs on their staff familiar with each-and-every DB†;

2. there was—and basically still is—no concept of an RDBMS stored-procedure "view" or "schema"—i.e., API versioning for stored procedures, where a client can request to communicate with the set of stored procedures it was compiled to support, rather than the single version the database is holding onto today;

3. one major RDBMS (MySQL) never supported stored procedures at all, so many devs learned an ossified set of "web development best-practices" without ever being exposed to the idea of stored procedures as an option.

All of these issues are fixable. #3 is just a historical artifact of MySQL's laziness; #1 is likewise an artifact of the proprietary, "enterprise lock-in" nature of the first instances of stored procedures (Microsoft's and Oracle's), evenly fracturing the ecosystem away from adopting either. Neither is likely to repeat.

#2 is more pernicious, and to this day seems ill-addressed.

One place I've seen at least an attempt to resolve it is in the design of Redis's Lua queries, where the "solution" is to refer to the stored procedures by content-hash, with the database having an always-possible error case that requires clients to be able to fall back to inserting the stored procedure again (thus necessitating that all clients track their own copies of any stored procedures they want to call.)

Such a solution could be ported to other RDBMSes; I could imagine Postgres, for example, having a "database view" concept††, where real databases only contain raw tables and indexes, and all the view definitions, triggers, stored procedures, constraints, and even typedefs are held in some record/spec/document that can be both manipulated as data, and connected to as a database. This is sort of equivalent to the CouchDB 'design document' concept.

---

† Sadly, it's really just a syntax problem. If you had several DBMSes that all had the same syntax but different extenional semantics, it'd be very easy to write a single code-generator into your application framework that would spit out appropriate code to take advantage of the extensions available. That's how regular ORM SQL-generation works, after all. But when you have disparate syntaxes, suddenly you need disparate code-generators, which get out of sync and lose features (or an LLVM-like intermediate-representation that you can do the semantic-optimization steps to before finally doing the codegen step, but I can't imagine that'd be cheap enough to slot into a webapp's hot loop.)

†† To go all the way with such a concept, the real 'data' of the database—the tables and the indexes—can become floating objects, not contained "in" anything or defined anywhere, merely existing because of a ref-count from various vDB schemas. You wouldn't explicitly define tables; instead, you'd define your views (relational projections) and then assert identity relationships between some of the columns of those projections, causing one "table" to exist holding the underlying data for both views. This is, AFAIK, what https://en.wikipedia.org/wiki/Dabble_DB was working toward.