Decision Guidance for Serverless Adoption
This article guides on adoption of Serverless and provides decision guidance for various, architecture and workloads, It shares a list of antipatterns.
Join the DZone community and get the full member experience.Join For Free
This article is a part of a series that looks at serverless from diverse points of view and provides pragmatic guides that help in adopting serverless architecture, tackling practical challenges in serverless, and discussing how serverless enables reactive event-driven architectures. The articles stay clear of a Cloud provider serverless services, only referring to those in examples (AWS being a common reference). The articles in this series are published periodically and can be searched with the tag “openupserverless”.
The Serverless compute model has reached the “Early Adopter” stage in the Hype Curve and moving very fast towards attending the “Early Majority” stage. While the evolution of Serverless has been rapid and phenomenal, enterprises are lacking in strategy in adopting Serverless and leveraging its advancement in technology and architecture for an efficient IT ecosystem. This article attempts to provide simplified decision guidance for Serverless Architecture Adoption while not prescribing specific detailed guidance on the decision matrix of specific FaaS, BaaS, and other serverless services provided by Cloud Service Providers (CSPs) e.g., Serverless Databases, API Gateways or Edge services.
Characteristics of Serverless Candidates
Before we delve into the detailed Serverless adoption guidance, it is important to understand the characteristics of Serverless Candidates that assist in the evaluation process for adoption. The table below provides some technology-neutral traits of application or workload patterns that are an easy fit into serverless. These traits are the building blocks of more complex serverless patterns, solutions, and architectures These characteristics work with a combination and are not exclusive.
Candidate Architectures for Serverless
There as certain architectures as follows that are more suitable for serverless adoption across Applications, Data, Integration, AI, IoT, etc.
- Reactive Systems
- Domain Driven Design based Microservices
- Strangler Transformation
- Big Data
- Databases that include SQL and No SQL DBs e.g., Document DB, Columnar DB, Key Value, RDBMS, Object Store
- Data Processing
- Stream processing
- REST API
- Event Driven
- Event Streams
- BPM Workflows
- IoT Event Processing
- Blockchain processing
- Cross Cutting (Security & Compliances)
- IAM, identity Federation
- Key, Certificate Management, RBAC, Secret Vaults, HSM
- Firewalls, DDoS,
- Regulatory Data Compliance
- IoT Device Security
- Cross Cutting (DevOps)
- Health Dashboard, Cost Management, Account Management
Example Use cases for Serverless Functions
Some of the example use cases for serverless functions are listed below, and the list is not finite but evolving.
- Act on events triggered by internal and external services/sources.
- Schedule tasks according to a specific timetable (periodic), such as taking backups and log analysis.
- Implement API Management for existing services or applications.
- Execute app logic in response to a database change.
- Invoke auto-scalable mobile/API backend services.
- Image processing coupled with Cognitive services for visual recognition.
- Streaming, Image, and Video Manipulation based on targets.
- Perform edge analytics in response to sensor input (IoT).
- Extend and enhance workflows and their data with new functional logic (e.g., send notifications, tag data, add weather data).
- Act as a glue between different services to create a powerful pipeline.
- Implementation of microservices, as well as parallel computing or data processing.
- App requires event-based/asynchronous-based communication to implement use cases.
- Polling use cases, pub-sub kind of realization.
Cases Unfit for Serverless
Also, there are cases where Serverless may not be a suitable option to choose as follows:
- Workloads that need high-performance computing (HPC) with components executed in proximity.
- Processes that have long execution time and require Master/Worker node type of clusters for processing.
- Workloads that require control over the underlying infrastructure components like physical sockets or cores e.g., workload requires licenses that are bound to per-core, per-socket or per-VM.
- Organizations that operate in regulated industries and need compliance with running workloads in dedicated infrastructure instead of multitenant environments.
- Workloads that require complex and/or fine-grained auto-scaling rules with predictive or ML algorithms.
- Tasks are long-running or anticipate long latency (perhaps due to external connections).
- Functions that are complex (non-separable) or take a long time to initialize.
- Requirement mandates stateful sessions to implement the use cases.
- Functions that involve transaction management with DB and, at the same time, have requirements around rapid scaling. DB might become a bottleneck for scaling.
- Compliance requirements mandated by the client (For e.g., if the compliance requires scanning the underlying infrastructure, it is not possible as there are no specific target infrastructures in Serverless).
- Requirements on runtime version for implementation are specific (The reason being we have no control over the serverless runtimes and updates are driven by the vendor).
- Application architecture for serverless is vendor dependent (Potential for vendor lock-in, particularly involving platform capabilities, such as Authentication, Scaling, Monitoring, and Configuration Management).
- Multi-tenancy is not a preferred option when data processed are sensitive in nature.
Simplified Serverless Adoption Decision Guidance Framework
Based on the characteristics, architecture type, and use cases, a simple Serverless Adoption Decision Guidance framework is illustrated below.
There exist various service types by CSPs for serverless implementation, primarily FaaS/BaaS and Serverless Container Platform.
Key Characteristics of Serverless Platform
Some of the key characteristics of Serverless Platform are listed below.
- Simplified Programming Model because the entire application can be described as event triggers for FaaS and BaaS and that the overall "application" can be composed from smaller serverless building blocks.
- Focus on front-end application Logic using short-running, single-purpose, RESTful functions:
- Simple (JSON) Input / Output
- Localized configuration via environment variables
- Polyglot - Choice of the programming language that suits your needs; Combine functions written in different languages.
- Event Driven - Multiple modes of invocation (Automated via Triggers/Messages, Manual from API invocations)
- Simplified Data and Service Integrations – “out-of-box” integrations with Storage (Database, Object Storage, etc.) Messaging, API Management, and other Provider Services
- Towards “NoOps” - Serverless platform manages operational aspects such as provisioning, deployment, auto-scaling configuration, availability, etc.
- Platform-provided Operational Support Services - “Built-in” support for logging and monitoring, Identity and Access Management, etc.
- Pay for only the Compute you use - Pricing is based on functional execution time or # of requests.
Simple Decision Guide for FaaS/BaaS vs Serverless Platform
It is critical to understand choose between FaaS/BaaS services from CSP or use serverless platform that can run containers. A simple decision guidance is provided below.
While Serverless Computing is evolving rapidly bring new services and capabilities beyond the typical set of use cases that adopt it currently, may organizations have significant challenges in Serverless adoption strategy fundamentally. This paper attempts to provide simplified guidance that may assists to expedite Serverless adoption.
Opinions expressed by DZone contributors are their own.