Serverless Best Practices
medium.com
Serverless Best Practices
1–10 of 104 posts
Re: Serverless Best Practices
#2I still don’t understand how you do a PostgreSQL insert on a serverless system—please help! Also, this statement is patently silly:
> The biggest point to make here is that serverless architecture may well require you to rethink your data layer. That’s not the fault of serverless.
Well, it is the fault of serverless. It’s a shortcoming. Own it. The trade off may we be worthwhile, I just can’t tell yet. I’m trying to wrap my mind around serverless as regards database-backed apps, but obviously it would be preferable to be able to use the RDBMS of my choice.
Re: Serverless Best Practices
#3I still don’t understand how you do a PostgreSQL insert on a serverless system—please help! Also, this statement is patently silly: > The biggest point to make here is that serverless architecture may well require you to rethink your data layer. That’s not the fault of serverless. Well, it is the fault of serverless. It’s a shortcoming. Own it. The trade off may we be worthwhile, I just can’t tell yet. I’m trying to…
Moving away from RDBMS just wasn't an option for us. But AWS serverless provided a couple benefits:
1. Aurora Serverless RDBMS (In pilot)
2. Lambda function property caching (for which we cache connections)Re: Serverless Best Practices
#4I still don’t understand how you do a PostgreSQL insert on a serverless system—please help! Also, this statement is patently silly: > The biggest point to make here is that serverless architecture may well require you to rethink your data layer. That’s not the fault of serverless. Well, it is the fault of serverless. It’s a shortcoming. Own it. The trade off may we be worthwhile, I just can’t tell yet. I’m trying to…
I agree with this. Having a traditionally relational store can be a huge help: lots of people know it well, the disadvantages are well known, and everything is insanely mature. I dislike how the article tries to say that isn’t serveless’s fault when it is just a trade off.
Re: Serverless Best Practices
#5Big ups for calling out how bad an idea connecting to the database is from a serverless context. I do a lot with serverless on AWS Lambda. Since part of that involves an ETL to write to a database, I also run a server that exposes a service for writing data via RPC. The server provides a connection pool to the database and appropriately encapsulates all the complex functionality we have for incoming data behind a well-defined interface.
If you really insist on calling your entire stack serverless, do what we do and run these servers as ECS tasks via Fargate. That is plausibly serverless, albeit long-running. You get all the perks of a serverless environment with all the perks of something like beanstalk (without having to patch a server!). The drawback in this scenario is that running ECS tasks via Fargate don't provide as much flexibility in cost.
Re: Serverless Best Practices
#6Big ups for calling out how bad an idea connecting to the database is from a serverless context. I do a lot with serverless on AWS Lambda. Since part of that involves an ETL to write to a database, I also run a server that exposes a service for writing data via RPC. The server provides a connection pool to the database and appropriately encapsulates all the complex functionality we have for incoming data behind a wel…
Connecting a DB might be a bad idea only currently, until cloud providers implement some sort of RPC SQL layer.
We are successfully running Lambda functions connecting to AWS Aurora MySQL using IAM authentication. It has some quirks but after figuring it out, works well.
Just run a connection pool with only 1 connection and expect some additional latency on cold start, though it's negligible compared to loading libraries, runtime, etc.
Re: Serverless Best Practices
#7I still don’t understand how you do a PostgreSQL insert on a serverless system—please help! Also, this statement is patently silly: > The biggest point to make here is that serverless architecture may well require you to rethink your data layer. That’s not the fault of serverless. Well, it is the fault of serverless. It’s a shortcoming. Own it. The trade off may we be worthwhile, I just can’t tell yet. I’m trying to…
[deleted]
Re: Serverless Best Practices
#8Big ups for calling out how bad an idea connecting to the database is from a serverless context. I do a lot with serverless on AWS Lambda. Since part of that involves an ETL to write to a database, I also run a server that exposes a service for writing data via RPC. The server provides a connection pool to the database and appropriately encapsulates all the complex functionality we have for incoming data behind a wel…
I use a specific Lambda function that acts like a sink. It receives messages via SNS from a myriad of other services and its only job is to push these messages to the main applications API. There the actual inserts and updates are done. The main API lives on Heroku.
Re: Serverless Best Practices
#9I would rather disagree with these practices. Some of them are subjective and some will likely be outdated soon.
> Each function should do only one thing. The problem with one/a few functions running your entire app, is that when you scale you end up scaling your entire application.
Sure, but is that a problem in general? Same thing can be said about a monolith vs microservices, and there is always a trade-off. A function with a larger code-base makes the code easier to navigate; may be easier to deploy. First reason about / compare cold-start times before making the decision to break the function.
> Functions don’t call other functions
Is the cost of calling the other function negligible (e.g. the functions are called rarely)? If yes, feel free to do it.
> Use as few libraries in your functions as possible (preferably zero)
Security risk is another discussion, not related to serverless. Worry instead about the cold-start time. If it's short enough for your use case - do use libraries. Should be no problem for Go, Node is usually OK. Java - native compilation is slowly approaching.
> Avoid using connection based services e.g. RDBMS
If adding another library is not a problem in your case, then why not? It's not too difficult to create a pool with a single connection. As for security, there are some new options like AWS Aurora IAM authentication. No VPC needed.
Re: Serverless Best Practices
#10He mentions DynamoDB for the data layer instead of regular RDBMS. I have tried to use DynamoDB several times but have been disappointed with it. I am not saying traditional RDBMSs solve the problem that DynamoDB has, but even DynamoDB is a poor fit for systems with rapidly changing load patterns. Some things that have been big pain points while using DynamoDB:
- It has autoscaling built in now but even that leads a lot to be desired, autoscaling is slow and your lambda functions will error out for significant amount of time(I have seen it happen upto 5 minutes) for 5X spikes until it scales up the IOPS. This fills up the queues quite fast and can lead to patterns where your spike increases because of failure retries. You can control this somewhat by limiting lambda invocations though. - Limited number of scale downs allowed. - Scale down doesn't completely reduce the throughput limits. I have seen situations where the write load went to 0 on certain times but scale down reduced it to something like 400 IOPS which can be a huge cost drain.
I am still looking for a DB which has done this well. Essentially what I want is compute layer separated from the storage layer in the database well enough so that both can be scaled independently and the compute layer can react to quick changes in load patterns. Does anyone here have any recommendations?