Serverless: traits, best practices & security risks

Arpit Mohan - Nov 28 '19 - - Dev Community

TL;DR style notes from articles I read today.

The traits of serverless architecture

  • The initial learning curve is low and hence there is low barrier-to-entry. It lets you on-board quickly without needing to develop server management skills.
  • Being hostless, it reduces operational overhead on server maintenance. However, you need to learn different monitoring metrics, non-traditional security issues and the specific limitations of each service. 
  • Serverless architecture is stateless and helps you scale horizontally. But it makes it hard to use stateful technology such as HTTP sessions or WebSockets.
  • You need to learn distributed message delivery methods and the behavior of distributed transactions.
  • High availability is offset by less consistency, and each serverless service has its own consistency model.


Full post here, 11 mins read


Serverless best practices

  • Make each function do only one thing. Avoid switch statements that make for large, complex functions that don’t scale well.
  • Don’t let functions call other functions.
  • Learn to use messages and queues to keep functions asynchronous.
  • Use as few libraries as possible (ideally none), to avoid slowing down cold starts and to avoid adding security risks.
  • One function per route (using HTTP). Avoid the single function proxy as it does not scale well and cannot isolate issues.
  • Treat data as flows and not ‘lakes’ at rest. Avoid querying from a lake; you need to rethink your data layer to avoid scaling issues and rigidity of data structures.

Full post here, 7 mins read


Serverless security risks

  • Event data injections are really hard to identify & block in serverless architecture.
  • Broken authentication is a big risk. There are hundreds of distinct functions, triggers & events that you must provide with the right access control and protection.
  • High degree of settings customization offered in serverless can lead to insecure deployment configurations. Make functions stateless at the design stages to avoid exposing sensitive data.
  • Over privileged functions are huge security risks.
  • Poor function monitoring and logging. Collect real-time logs from serverless functions and services, and push them to a remote SIEM system.
  • Third-party dependencies on web services (through API calls), software packages and open-source libraries. 


Full post here, 4 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