Transitioning from SOA to Serverless-as-a-Framework

Serverless on AWS can be viewed as more than just a way to create highly available systems which can operate at massive scale with minimal management. In the pre-cloud era, one of the big leaps in software development was Service Oriented Architecture frameworks. These frameworks often allowed for systems to be broken down into components, which were more easily testable, and then connected together at runtime to deliver a flexible set of capabilities to customers based on the customer’s licenses or unique business needs.

What is Service Oriented Architecture?

Service Oriented Architecture is an approach where developers create interfaces which define services. These interfaces are used to disconnect the calling components from the implementation of a specific service. After defining the services, the system is then configured through wiring. Wiring refers to a configuration which associates what services each component needs, as well as where to find the implementation for each service. This separation of responsibilities makes it possible to simplify the code, as each component is boiled down to simple responsibilities. This makes data layers easier to access, but it also allows the flexibility to handle more complexity around specific and unique customer requirements. To learn more about SOA check out this article on "Service Oriented Architecture".

An example of this is where one customer (Customer A) requires a custom report that another customer does not need (Customer B). In this example, a custom component is created in the software to handle Customer A’s needs, and a configuration is created to wire Customer A’s component into the system when they send data through. Customer B, on the other hand, is configured to not use this new component through configuring the framework to not add the new component into the execution model path during the wiring phase.

Can Serverless Take the Place of the Framework?

The interesting aspect of serverless systems is that the infrastructure definition and connecting components take on a similar role to the SOA framework.

The AWS Lambda function is configured to point to its integration points through the environment variables section at the time of deployment, which then allows the deployment to wire together different components and services to create the solution environment the customer operates in.

While this example is very basic, more complex SOA concepts can easily start making their way into these systems. The concept of using Amazon Simple Notification Service (SNS) for integration points allows for the distribution of responsibilities. Let’s take the previous example of two customers who need different reports. In that case, Amazon SNS starts fulfilling a key role in the wiring and execution process.

In the example above, we have both the standard report and the custom report being generated by two different AWS Lambda functions. Amazon SNS subscriptions allow tailoring criteria for which events each AWS Lambda function receives based on data in the message. The API Lambda has no knowledge of which report should be generated, and the report lambdas don’t require any special logic as to when to generate the reports or not. The result is that this complexity falls into the Infrastructure as Code (IaC) definition as the configuration framework.

Added Bonuses of Serverless-as-an-SOA Framework

One of the benefits of using serverless components as your framework is that serverless components often have more stability baked into them. Amazon SNS topics have the ability to perform limited retried but are also a functional way to ensure stability in the case of reaching concurrency limits. Amazon Simple Queue Service (SQS) can add benefits around ordered processing of customer data with FIFO queues, without having to handle that complexity in the code itself. FIFO queues can also protect customers from having their performance impacted by another one of your customers behaving badly, as each customer's data can be handled as unique FIFO tracks, only blocking the track of the badly behaving customers.

Hot Patching

One of the major advantages of more complex SOA systems is the concept of not having to take the full system down in order to patch or replace a specific component in the SOA system. In a serverless system, this is provided by default. Serverless systems will deploy new updates as a new version of the AWS Lambda function. This new version will exist side by side with the old version until traffic is switched to the new version. This allows the system to receive updates live, with little to no interruption. In addition to that, the ability to do a canary deployment with AWS Lambda functions gives serverless systems an advantage over some SOA frameworks, as part of the production traffic can be sent to the updated AWS Lambda function, which is monitored for errors and slowly gets more traffic over time as it proves stable.

Conclusion

When transitioning from SOA to serverless-as-a-framework you can keep most of the same patterns and concepts, but you will leverage a slightly different set of tools and patterns. One of the biggest challenges to this transition is from synchronous invocation patterns largely seen in SOA to asynchronous patterns seen in modern serverless applications. Even so, the tenants of SOA fit perfectly into the serverless mindset. Concepts like separating capabilities, allowing isolation and independent scaling and distribution of components independently can be directly translated.