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
Top comments (1)
Hi, nice post! You don't really "need to learn distributed message delivery methods and the behavior of distributed transactions", unless you're into microservices.
Although this architectural pattern is common and fits well in serverless computing, it's not a must. If you have a monolithic function, for example, distributed transaction isn't needed.
Using features like Lambda Layers, it's even possible to avoid distributed msgs or transactions while still enjoying some benefits similar to what microservices deliver.