Lessons from developers who went serverless

Arpit Mohan - Nov 26 '19 - - Dev Community

TL;DR style notes from articles I read today.

Lessons learned — a year of going “fully serverless” in production

  • API server on serverless leads to automatic scalability, high availability and reduces costs dramatically.
  • Deploying a Lambda function has a 52Mb limitation. Mitigate this by including only the required dependencies and trimming their size by excluding unused files.
  • For background jobs such as file processing, keep a set of dedicated Lambda functions that are not part of the API server.
  • A good approach to logging is to stream the Lambda logs into a dedicated Lambda that is responsible for sending it to the 3rd party logging service. 
  • When it comes to environment variables, don’t commit your secrets to source control.

Full post here, 6 mins read


6 things I’ve learned in my first 6 months using serverless

  • Ditch Python, switch over to Node. It makes everything much more maintainable and logical.
  • The middle layer has to go. It acts as a web server on Lambda, which is both wrong and terrible.
  • Try Vue when dealing with messy code. Vue compiles all your goodness into an index.html and bundle.js files, primed for uploading to S3.
  • Learn to love DynamoDB. When you get it right, the NoSQL database provides blistering performance, massive scale, and practically no administrative overheads.
  • Serverless Frameworks are awesome. A simple sls deploy wields enormous power, bundling up your code and shipping it directly to AWS Lambda.
  • Authorization is king and JWT makes all other types of auth look overcomplicated.

Full post here, 10 mins read


5 tips for building apps with the Serverless framework and AWS Lambda

  • Serverless works well with a microservice-style architecture. You should limit the scope of services and functions you use.
  • Lambda functions shouldn’t persist any data or session information in the environment beyond the lifetime of a single request.
  • However, Lambda might reuse your function instances to make performance optimizations. So, you should optimise for your functions for reuse.
  • Cold starts are a problem with AWS Lambda. Reduce latency by keeping containers warm.
  • Use dependency injection to make your functions easily testable. Write integration tests, both locally and on deployments.

Full post here, 6 mins read


Get these TL;DR style notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player