Serverless is much more than an abstraction over compute run-time. Serverless applications are inherently distributed, easily respond to incoming events, and change the role of cloud automation. This session reflects on how serverless influences our application delivery and takes a peek at recent trends like Event-driven Architectures and Infrastructure from Code.
Cloud automation can do more than reduce the toil of provisioning or configuring compute infrastructure. With application-level services that orchestrate, transform, store, and route events, it can also define your application topology. By describing component granularity, dependencies, data and control flow, and degrees of coupling in executable automation code, you can redefine automation from infrastructure as code to architecture as code. This talk takes AWS CDK to the next level and provides a novel take on automation at the intersection of serverless, integration, abstraction, and design patterns, with a special emphasis on the lines, not just the boxes.
While many customers associate serverless with Lambda, there are actually serverless services at all layers of the stack.
And while Lambda offers many key advantages for our customers, it’s really when all these other components surround Lambda that we start to see much bigger benefits. Messaging, orchestration, storage and compute together are the secret sauce. But In fact, it’s really when all of these components come together that we really start to see big gains.
So, synchronous communication blocks resources in all involved services, worst case for the time the entire processing takes.
Additionally, problems in downstream services can accumulate upstream.
This is why there are mitigation patterns like circuit breaker in the first place.
So, particularly under load, a synchronous integration approach can jeopardize the reliability of the entire application, and it can require excessive horizontal scaling with the respective cost attached.
Next step, they worked on reducing their runtime coupling, or temporary coupling, by switching from sync to async comms. <click>
So why is connecting systems so difficult and so important? The answer quickly becomes apparent once we look at how connected systems behave
This is from 2008 / 2015
This is from 2008 / 2015
This is from 2008 / 2015
Pipes with API destination is synchronous, adjusts concurrency based on the max Invocation Rate
Note: Serverlesspresso has a backpressure function built from DynamoDB as a flag for SFN because Baristas have limited capacity
[Sindhu]
<don’t click – auto>
Above is an example of ride booking app: 3 Lambda functions handle a customer booking: the booking service, payment service, and driver assignment. The coordination across these services is choreographed by passing events through EventBridge.<CLICK>
Such an event-driven architecture is flexible and scalable, but it relies on each Lambda function emitting events like “Payment received”. With Lambda destinations that’s easy to do, but still the Lambda functions have to participate by returning the event data.<CLICK>
Since the business flow is distributed, it difficult to maintain transactional scope, for example in case the payment service goes down or times out no event is published.
To address these challenges, we can refactor this design<CLICK>
We replaced the Choreography with a Step Functions Orchestrator that calls each Lambda function. Now the functions are just passive elements that are called by Step Functions and it’s easier to see the entire flow, track the status of each workflow instance. <CLICK>
But architecture is always about trade-offs, so now things are a bit more tightly coupled with a single point of maintenance. That can be a good thing if you want control, but it can become a bottleneck if services come and go.
With automation playing such a central role, you could go as far as saying that if you remove automation from the cloud, you don’t have much more left than a good-old data center. At AWS, we have very nice data centers, but I haven’t met any customer who’s looking for yet another data center. So, let’s not do that.
Modern automation does more than just deploy an ec2 cluster. <CLICK>
The most common thing that automation does is provision resources. In our trivial example, that might be two VMs, a load balancer and a gateway. But servers don’t do much on their own, so you need to deploy workloads. <CLICK>That’s one step closer but now you have disconnected pieces. To turn this into a functioning application, you need to wire it together.<CLICK>We call that composition: what is connected to what? And last, you’ll might have some slight differences in configuration. <CLICK>You might have a primary server and a secondary, or have different services connected to different databases. So you also want to do that via automation.So, this architecture diagram helps us understand the different aspects that come together when we say "automation".
So how does serverless relate back to our architecture model of cloud automation? Well, the provisioning is all done for you and deployment can be as simple as placing a ZIP file in a bucket.<CLICK>So, the element that’s becoming most prominent for serverless applications is composition - that’s how those loosely coupled components are connected into a working application. Composition defines many essential properties of a serverless application, e.g. its granularity - how small are your pieces? It also defines the dependencies - which components send messages or events to which other components? Do they do so synchronously or asynchronously? You will likely use services like Amazon SQS, Amazon SNS and Amazon EventBridge for those connections.
That’s what I am working on – stay tuned
With tools such as the AWS CDK, you are not only being able to define your infrastructure as code. If you think about serverless applications, things as deployment, composition and configuration are the main drivers for leveraging automation tools. <CLICK> So you can say, this is much more than infrastructure as actual code.