Considerations When Building With Serverless
The increasing abstraction of a serverless solution offers organizations the opportunity to update their operating model, and requires adopters to update approaches, roles and tools to manage these new deployments. At this stage of the adoption cycle, we find that organizations are interested in discussing how serverless has impacted the areas of roles, development processes, operations and networking, observability, security and event loops.
Team roles evolve when moving to serverless: with much less infrastructure to manage, the balance of time budgets shift toward additional feature developments, and shared Site Reliability Engineer (SRE) responsibilities. The SRE role expands DevOps team structures to also embrace coding application-level improvements and bug fixes during shifts and sprints. This process becomes a virtuous cycle: SRE activities act as a flywheel for long-term reliability improvements in code, and reduce the operational support required for a well-instrumented and automated workload.
Testing code in a serverless solution also requires changes in approach. The Function code may be simple, but the interactions between many functions, services, and events in a highly distributed stateless system are complex. Best practices are for functions to perform a single purpose and to be written as a few hundred lines of code, so unit testing becomes relatively simple. Outside of the Function, there are combinations of Events, data, workflows and service interactions to be tested. The emphasis of serverless testing shifts from code units to end-to-end calls for chains of events across a set of distributed services.
Debugging in serverless architectures has been removed, and replaced with events and triggers in event-driven architectures. This continuing abstraction removes access to that layer, and invalidates many tools used today. Mode2 recommends that organizations consider how to access data currently residing in VPC-based deployments, and how to optimize service calls for serverless workloads.
Networking in serverless is abstracted by the cloud into events and triggers, removing any access for users beyond which is provided in environment variables. Functions run in multi-tenanted containers, which incur a high overhead to bind to private network interface. Event-driven architectures have a big impact on networking, and we recommend Cloud managers consider how to access data currently residing in VPC-based deployments, and how to optimize architectures for serverless workloads.
Observability in serverless solutions is the process of creating detailed insights into the operational health and end-to-end processes, and becomes increasingly important in serverless operations. Public cloud logging is eventually consistent, with delays of seconds to several minutes for access to the operational data required to understand and fix issues. Functions run in highly restricted environments with common performance tools removed, so adopters must consider Function-specific monitoring solutions to provide operational insights.
Security is also updated by the move from networks to events. Existing security tools like NIDs and WAFs rely on inspecting networks and packets, which are not present in serverless. Functions are typically daisy chained together via other serverless services, which raises questions such as, “how can the combinations of events and services be managed”? and, “how can execution paths that are not permitted be blocked”? Best practice is to apply least privilege access policies to each Function; these policies must be managed and updated as new service calls are added to code releases. Mode2 recommends a proof of concept to evaluate the simplicity available from new partner tooling.
Event Loops are when developers accidentally create infinite loops between invocation events, where triggers cause code to continuously execute. A common example is when event sourcing from a datastore: a Function writes to the table, which triggers a stream to emit a new event, which triggers the initial Function to run and infinitely loop [ 6 ]. Serverless adopters must actively test for event loops, activate billing alarms, and establish a circuit breaker for a deployment to buy time to debug and release code fixes.