Event-driven integration between cloud-native applications and legacy systems of record
The fast-evolving serverless architecture paradigm has been successfully adopted by various use case domains since its inception because of its easy deployment and management effort, for example. This article applies serverless architecture to the event-driven integration pattern between cloud-native application and legacy systems of record, which presents an interesting opportunity for cost optimization, efficiency, and faster time to market.
From the perspectives of enterprise architecture and cloud architecture, this article introduces an architecture pattern for an event-driven integration approach that is applied to an example use in the healthcare industry. It also discusses anti-patterns and points to sample code to jump-start using this approach.
What to expect from serverless computing providers
As you are considering applying a serverless architecture to an integration between legacy apps and legacy systems of record, review the following capabilities of serverless providers:
- You can write and manage function code without worrying about underlying infrastructure and platform provisioning.
- Serverless platforms manage operational aspects such as deployment, autoscaling configuration, and availability.
- You have different runtime choices.
- Serverless providers include identity and access management for access controls for serverless functions.
- You can choose from multiple modes of invocation, for example, event triggers, APIs, and messaging.
- You can use environment variables, logging, and monitoring.
- Pricing is based on function usage, and there are no separate costs for infrastructure as a service (IaaS) or platform as a service (PaaS).
- Extended environment support includes databases, storage, and integration with other applications and services.
Characteristics of services that qualify for serverless computing
It is extremely important to evaluate application characteristics and ensure that it is aligned to Serverless architecture pattern. Following is the current view of what characteristics we look for in applications to make them ideal candidates for serverless implementation. We also list some of the anti-patterns that are not suitable for a serverless architecture.
Applications that qualify for a serverless architecture include the following characteristics:
- Short-running stateless functions (seconds or minutes)
- Seasonal workloads with varying off-peak and peaks
- Production volumetric data that shows too much idle time
- Event-based processing or asynchronous request processing for implementing use cases
- Needs to simplify operations so that server maintenance is no longer a responsibility of a function provider organization (for example, the ability to automatic scaling without the need to configure the underlying PaaS)
- Microservices that can be built as functions that are stateless
Anti-patterns for serverless computing
The following examples are reasons not to use a serverless architecuture with your applications:
- An over-engineered design uses serverless functions by breaking down components to very fine-grained tasks that are not meaningful business functions.
- A function requires a stateful session to implement the use case or requirements.
- The serverless application architecture is defined as vendor dependent (and there is a potential for vendor lock-in, particularly involving platform capabilities like authentication, scaling, monitoring, or configuration management).
Emerging use cases for functions as a service (FaaS)
The intent of this section is not to provide an exhaustive list of use cases. However, each of the following use cases is a fast-emerging pattern for using serverless architecture in application design:
- The DevOps pipeline is emerging as one of the top candidates for adoption of serverless computing (for example, functions that address operational issues by taking corrective actions in response to an operational event). Development and test environments using serverless functions have made significant innovations toward optimal consumption of resources. Examples include functions that bring down development and test resources when no users are logged in and that bring relevant resources up when a user logs in (based on user profile and preferences).
- Applications act on events triggered by internal and external services or sources. Tasks are scheduled according to a specific time or event, such as trigger fraud analytics in response to a suspicious activity.
- An anomaly detected from sensor input triggers performing analytics.
- A database change triggers running application logic (for example, to enable change data capture on select data sets).
- Business events cause analytics to be performed and images to be processed. For example, as soon as image is generated, medical imaging analytics generate thumbnails for an image upload.