Serverless Espresso: A Case Study of Serverless Event-Driven Architecture

What is Serverless Espresso?

Serverless Espresso is a pop-up coffee shop that allows you to order coffee from your phone. It started off as a Lab. AWS Serverless Developer Advocates put it together. In 2021 it was just a stall in an expo hall. Since then, they have taken it on a world tour. And it was back at AWS re:Invent in 2023.

I think it is worth talking about because it’s really interesting. I’ll just explain what it is first.

In the Expo Hall at the AWS Summit, they have a barista setup. And you walk up to a QR code with a screen in the background. You scan the QR code and enter your email address. Up pops a menu. If you select an americano, espresso, or other type of coffee, it kicks off an event-driven flow. It uses an event-driven service under the hood and pops up on the screen as a number. Then, the Barista takes the number, makes your coffee, and gives it to you.

But what’s happening in the background is a whole load of orchestration and choreography of events. AWS has been using it as a way to explain serverless event-driven architecture.

In the following transcript of the Serverless Craic podcast, The Value Flywheel Effect authors David Anderson, Mark McCann, and Michael O’Reilly break down this case study of effective event-driven architecture in the cloud.

Event-Driven Architecture Is a Hard Concept

Mark McCann
Werner Vogels called it out in his keynote as well. Event-driven architecture can be hard for people to conceptually wrap their heads around. So making it real through ordering coffee. And showing how to tie a coffee process and an event-driven coffee ordering system makes it real. It demystifies it a little bit and removes some of the thinking that event-driven architecture sounds really hard. This makes it more approachable.

Dave Anderson
It’s also the best cup of coffee you can get at AWS re:Invent. And it’s always good to order coffee and chat with the people at the Serverless Espresso stand. James Beswick, Ben Smith, Eric Johnson, Julian Wood, and a whole bunch of them have been working on it.

After I saw it for the first time, I could see that when they wrote it, they put it together properly. So it’s a well-architected, well-designed service event application, which is cool.

Serverless Espresso Stitches Great Tech Together

Mark McCann
It stitches together a lot of stuff that we’ve been advocating for in a way that makes sense by using AWS Step Functions, EventBridge, Lambda, API Gateway, S3, DynamoDB, and Cognito. It brings to bare a lot of great technology that we are advocating for in a way that’s practical and easily consumable.

And the Serverless Espresso workshop is very good for walking you through the steps about why you’re doing what you’re doing. And how do you do that, set up rules and set up everything? It’s a great way to get hands-on with event-driven architectures and serverless in a practical way. So it takes you from zero to five in serverless event-driven architecture.

Dave Anderson
You can track Serverless Espresso. When you put in your order, that’s a service which pops an event for something ordered onto EventBridge and pops it back to the Step Function. And then takes it through an orchestration flow of ‘Are we open?’, ‘Do we have capacity?’, ‘What have we ordered?’, ‘Do we have milk for a latte?’, or whatever.

So it works through all the steps. And there are failure states as well. It’s neat to see the interaction go back and forth.

Look under the Hood with Serverless Espresso Lab

But what’s also cool is that they put the whole thing as a lab, so you can step through it and see exactly how it’s implemented and split up. It’s a free Lab, which is nice.

Michael O’Reilly
From just looking at the Lab, it is good but also from the perspective of the term ‘existence proof’ that we talk about. It’s a real-time front-end application with an applet or an app hosting a QR code. And you’re on your phone doing real-time transactions.

There are lots of myths around serverless, like its batch-based workloads or spike-based workloads. Serverless Espresso is a real-time application that can scale up and do all these things.

Dave Anderson
And it’s very cheap to run with proper events like coffee ordered etc. They are proper events and not just messages.

Mark McCann
They talk about it in the workshop. When Serverless Espresso is fired up, it costs up to $1 to set up the workshop and run 1000 requests. In the last year, AWS has been really good at lowering the barrier to entry to these technologies. And a lot of these workshops are really great ways for people to self-start and self-serve. So there’s this one. And there are lots of other workshops that are equally as good for getting started with these technologies.

AWS is Dispelling Two Serverless Myths

Dave Anderson
There are two myths in this space that AWS is trying to dispel. We first started talking about event-driven architecture 13 years ago. We had the idea of doing something but back then, it was really difficult because we didn’t have a lot of support. So we had hard problems to solve technically because the foundations weren’t there. That is the first myth of being a hard thing to do.

The second myth is that people think of serverless as just writing code and functions. It’s actually more like an event-driven architecture. It’s events firing off activity and not a call stack. So it’s a lot easier to build full events of architecture than it would have been years ago. The technical challenge is not as bad as you think it is.

Michael O’Reilly
I would argue that from looking at the review page, it is a modern application or a modern app. It has replaced the old traditional framework that you would have had to pull in. So it’s an aggregation and integration of various managed services to assemble a modern-day application that we have talked about in previous episodes.

Enterprise Service Bus versus Event-Driven Architecture

Mark McCann
Standing up an enterprise service bus in the past needed a lot of money and time, even with some of the old IBM stack that we’ve used in the past. Now you can do this yourself. It’s really inexpensive, and it allows you to experiment rapidly, get good feedback and learn quickly. And you can give it to your teams without the fear of it costing a fortune.

Dave Anderson
In the past, I remember our 5-year strategy being ESB (enterprise service bus), and we were to spend three years building it. Now you can spin it up in half an hour. The technical challenges are pretty daunting. What are the challenges of standing up event-driven architecture?

The Socio-Technical Challenge

Michael O’Reilly
A lot of the challenges in event-driven architecture are socio-technical. Do you do good domain-driven design? What are your boundaries? What teams are aligned with that bounded context and those domains? Who owns them?

For me, they’re not technology problems anymore. You have to be able to solve the socio-technical side of things. They’re the sticky things that take homework upfront.

Mark McCann
It’s trying to tease out who the actual users are? And what are their needs? What are the types of events that need to flow through this business process and be handled by these demands? What are the events that are flowing through your system? And what key moments matter in your business? Have you captured them appropriately? There are collaborative workshops, like event storming or event brainstorming, to tease those things out.

Michael O’Reilly
There’s a great presentation from a previous AWS re:Invent talking about three types of events. I think it was Martin Fowler.

Dave Anderson
Gregor Hohpe did that as well on EDA day.

Engineering Rigor and Discipline on How to Event

Michael O’Reilly
Once you’ve defined your domains and have better consistency, you need engineering rigour and discipline around how to event. And more importantly, with regard to the tooling around how are to event, like transactionality, correlations, and item potency.

Dave Anderson
They’re all problems you can solve; I think the organizational one is a good one.

What I like about Serverless Espresso is the simple interactions. You order, it goes to the barista who makes the coffee, and they gives it back to you. There’s one interaction. Normally when ordering a coffee, you talk to a waiter, the waiter talks to the barista, and the barista talks to someone about milk etc.

There can be six or seven people in that flow. It causes confusion. In a company, if a business process is owned by six or seven teams, even across two or three departments, it gets messy. If a single team builds for the customer directly and there’s no one else, it’s usually pretty clean. Because you can see everything needs to happen.

It gets complicated if the business processes are split over several teams and departments. You are right, Michael; it is a socio-technical problem.

Understanding the Bounded Context

Mark McCann
It’s about making it visible by baking in event storming to tease it all out. And get a shared language and an understanding of the actual process. Use a better context canvas to understand who the collaborators are in the domain. What events will it listen to, what rules are underlying, and what processes will it do? What events will it emit? That’s the key. Understand the bounded context and what they will produce.

Michael O’Reilly
In regards to the org, if you’re looking at traditional architectures, you have to go to ops and have a team that stands up the core event. The core event stream, or the backbone, takes time and becomes difficult to change.

In the sorts of environments that we’re talking about, you have rapid delivery approaches and a building block-type mentality. When I work with EventBridge, it’s about the value add. What are the disciplines? How do we make this really resilient? What practices keep things up and running harder? We maintain all of that. We’re not talking about the nuances of a stand-up like Kafka. Or our partitions and zookeepers. And what team do I talk to, to get that provisioned? You lose focus on building resiliency.

Clarity of Purpose and the Value Flywheel Effect

Dave Anderson
That’s taken off the table by using this approach. Serverless Espresso Lab is good because the opinions are out there, and you add on your bit, which is your business process flow. It goes back to our book, The Value Flywheel Effect. And the first phase of the value flywheel is clarity of purpose.

Who is the customer, and what is the business flow that we’re trying to build? And let’s have a good debate on how we are going to do that. When you get to the technical side, that opinion is already there. And you can focus on getting the orchestration correct. Because you know that a lot of that underlying stuff is pretty much solved apart from making it behave.

Position teams high up the value chain

Mark McCann
You need to position your teams high up the value chain. And if they’re chasing their tail with low level of technology, trying to stitch stuff together, they can’t be talking about higher-order stuff. Or talking about the well-architected nature of it. Or talking about business value and working with the business to tease out new innovative capabilities or services. And extending the event-driven architecture with a new capability or offering.

You remove a lot of undifferentiated stuff by adopting the technologies that Serverless Espresso Lab is advocating. So you’re focused on the actual value, the business process, and how I can make this better. How can I make this more scalable? And how can I add more business value?

Dave Anderson
If you’re a senior engineer and your value stream team is trying to scale a bunch of EC2s, then you’re barking up the wrong tree.

So that’s the craic! Look at the Serverless Espresso Lab on workshop.serverlesscoffee.com. Or search for Serverless Espresso. And big kudos to the AWS Serverless Developer Advocate team. They’re mostly on serverlessland.com. Thanks for listening.

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on Twitter @ServerlessEdge

Transcribed by https://otter.ai

*This post was originally published on The Serverless Edge.

- About The Authors

David Anderson

David Anderson has been at the leading edge of the technology industry for twenty-five years. He formed The Serverless Edge, and continues to work with clients and partners to prove out the thinking in his book, The Value Flywheel Effect. He is also a member of the Wardley Mapping community.

Follow David on Social Media

• 
• 

Mark McCann

Mark McCann is a Cloud Architect and leader focused on enabling organizations and their teams to rapidly deliver business value through well-architected, sustainable, serverless-first solutions. He was heavily involved with Liberty Mutual's journey to the cloud, leverages Wardley Mapping, and writes for the The Serverless Edge.

Follow Mark on Social Media

• 
• 

Michael O’Reilly

Michael O'Reilly is a Software-Architect who specializes in arming organizations with the ability to develop ideas into world-class products by leveraging the capabilities of the modern cloud.

Follow Michael on Social Media

• 
•