#serverless
22 posts

How to test serverless apps

Most of what goes wrong in serverless architecture lie in the configuration of functions: event sources, timeouts, memory, IAM permissions, etc. With functions being stateless, the number of integration points also increases, so you need more integration tests than unit or end-to-end testing.
Read more

How to test serverless apps

  • Most of what goes wrong in serverless architecture lie in the configuration of functions: event sources, timeouts, memory, IAM permissions, etc. With functions being stateless, the number of integration points also increases, so you need more integration tests than unit or end-to-end testing.
  • The first stage of testing should be local tests, for which you can: run the Node.js function inside a wrapper. Invoke functions locally using tools such as Serverless framework or AWS SAM local. Use docker-lambda to simulate an AWS Lambda environment locally. Use local-stack to simulate AWS services locally. However, none of these simulate IAM permissions or API authentication.
  • The second stage is unit tests. If you have a complex piece of business logic, you should encapsulate it into a module and test it as a unit.
  • Use integration testing to test code against external services you depend on, such as DynamoDB or S3. Run these tests against real DynamoDB tables or S3 buckets, and not mocks and stubs. Keep the same assumptions as of the code.
  • Once the local tests have checked your code, move to acceptance testing: whether functions have the right permissions, timeout settings, memory, API Gateway event sourcing, etc. Do this after deploying.
  • Finally, if your serverless application is used by a UI client directly or indirectly, make sure your changes are compatible with the client - you can have a QA team test this manually or use an automated test framework
  • Once deployed, you should still use robust monitoring and error reporting tools for issues developing in production.

Full post here, 6 mins read

Severe truth about serverless security and ways to mitigate major risks

Cloud providers may secure your databases, operating systems, virtual machines, the network, and other cloud components, but you must still protect your application layer against cyber attacks.
Read more

Severe truth about serverless security and ways to mitigate major risks

  • Cloud providers may secure your databases, operating systems, virtual machines, the network, and other cloud components, but you must still protect your application layer (code, business logic, data and cloud service configurations) against cyber attacks.
  • Traditional web application firewalls only protect functions called through an API gateway. So, apply perimeter security to each function, incorporate whitelist validation, monitor updates to functions, and add runtime defense solutions.
  • Be wary of third-party dependencies. Derive components from reliable official sources via secure links. For Node.js applications, use package locks or NPM shrinkwrap to restrict updates to code until you review them. Identify and fix vulnerabilities with automated dependency scanners.
  • Ensure all credentials that invoke third-party services or cross-account integrations are temporary or encrypted and use a cryptographic key management solution. Set strict constraints on input/output messages passing through the API gateway.
  • Address the downside of autoscaling, DoW (denial of wallet) attacks: set budget limits with alarms, limit the number of API requests in a given time window, use DDOS protection tools, and try to make API gateways internal and private.

Full post here, 7 mins read

Serverless pitfalls: issues with running a startup on AWS Lambda

Hosting your backend behind an API gateway can result in latency issues. If you want<50ms response times, you need dedicated infrastructure.
Read more

Serverless pitfalls: issues with running a startup on AWS Lambda

  • Functions with less RAM have slower CPU speed. Take both CPU and RAM into account (as well as the related costs: you save no money once execution time drops below 100ms) when allocating resources to Lambda functions.
  • Hosting your backend behind an API gateway can result in latency issues. If you want <50ms response times, you need dedicated infrastructure.
  • Lambdas in a VPC cannot connect to outside services like S3 unless you install a NAT gateway, with the associated charges. It’s best to run either completely inside or outside a VPC, even if it means less security and more latency and bandwidth costs.
  • Due to their distributed queues, AWS can execute Lambdas more than once per request. So be aware of and work around their idempotency.
  • You’ll find it hard to identify and debug functions that hang or get deadlocked because they automatically disappear over the limit. You’ll need to look to Cloudwatch for them.
  • Executing a Lambda from another Lambda is slow. Either launch a task specifically to launch a large number of other tasks or use threads to launch multiple tasks simultaneously.
  • To work around the dreaded cold start, you can move front-end requests facing the end user off Lambda and try to containerize.

Full post here, 10 mins read

The best ways to test your serverless applications

For the serverless functions you write, test for each of the following risks: configuration (databases, tables, access rights), technical workflow (parsing and using incoming requests, handling of successful responses and errors), business logic and integration.
Read more

The best ways to test your serverless applications

  • For the serverless functions you write, test for each of the following risks: configuration (databases, tables, access rights), technical workflow (parsing and using incoming requests, handling of successful responses and errors), business logic and integration (reading incoming request structures, storage order in databases).
  • Break up functions into hexagonal architecture (ports and adapters) with separation of concerns through layers of responsibility.
  • For unit tests, use a local adapter or mock as an adapter to test the function business layer in isolation.
  • Use adapters to simulate to test integration with third-party end services. Save memory and time by testing not for full integration but file storage integration with the in-memory adapter.
  • For proper monitoring of integrations, use back-end tools such as IOpipe, Thundra, Dashbird, Epsagon, etc., and front-end tools such as Sentry or Rollbar. You can also use an open-source error tracking app such as Desole that you install in your AWS account.

Full post here, 10 mins read

The good and bad of serverless

The good It’s truly scalable & saves you from the pains of managing servers manually. Serverless applications are a notch above Virtual Private Servers - you only pay for what you need.
Read more

The good and bad of serverless

The good

  • It’s truly scalable & saves you from the pains of managing servers manually.
  • Serverless applications are a notch above Virtual Private Servers - you only pay for what you need.
  • Developers on your team don’t have to deal with the technicalities of setting up scaling policies or configuring load balancers, VPCs, server provisioning, etc.

The bad

  • Cold starts when a function has been idle. To solve it, ping your functions periodically to ensure they’re always warm or set up a single function to handle all API calls in order to ensure that cold-starts only happen once.
  • The need for applications to be truly stateless. You must design your application to be ready to serve a request from a cold, dead state.
  • Not ideal for long-running jobs. Re-examine whether the time limit hinders your ability to process all the data or try using Lambda recursively.

Full post here, 9 mins read