What is Serverless Espresso?
Serverless Espresso is a pop-up coffee shop that allows you to order coffee from your phone. It started 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 this year.
It is worth covering because it’s fascinating. AWS has a Barista set up in the Expo Hall at the AWS Summit. You simply walk up to a QR code with a screen in the background. You scan the QR code and enter your email address. And 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-run events. And AWS has been using Serverless Espresso to explain serverless event-driven architecture.
Event-driven architecture is a complex concept
Werner Vogels highlighted EDA in his keynote. Event-driven architecture can be challenging for people to wrap their heads around conceptually. So AWS is making it real by ordering coffee and showing how to tie a coffee process to an event-driven coffee ordering system. It demystifies and removes some of the thinking that event-driven architecture sounds hard. By doing this, AWS is making EDA more approachable.
It’s also the best cup of coffee 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 many others have been working on it.
After I saw it for the first time, I could see they put it together correctly when writing it. So it’s a well-architected, well-designed service event application, which is fantastic.
Serverless Espresso stitches great tech together
EDA 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 bear a lot of great technology that we are advocating for in a practical and easily consumable way.
And the Serverless Espresso workshop is perfect 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 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.
You can track Serverless Espresso. When you put in your order, that’s a service, which pops an event for something ordered on to 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.
From the perspective of the term ‘existence proof,’ Serverless Espresso is a real-time front-end application with an applet or an app hosting a QR code. You’re on your phone doing real-time transactions.
There are many myths about serverless, like batch-based or spike-based workloads. Serverless Espresso is a real-time application that can scale up and do everything. It’s very cheap to run with proper events like coffee ordered, etc. They are actual events and not just messages.
AWS going into detail in their Serverless Espresso workshop. When AWS fires up Serverless Espresso, it costs $1 to set up the workshop and run 1000 requests. In the last year, AWS has been good at lowering the barrier to entry to these technologies. And many of these workshops are great ways for people to self-start and self-serve. So there’s this one. And there are lots of other workshops that are that are equally as good for getting started with these technologies.
AWS is dispelling two Serverless myths
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 tough because we needed more support. So, we had complex 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 serverless is just writing code and functions. It’s 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 a full event of architecture than it would have been years ago. The technical challenge is better than you think it is.
EDA is a modern application or an app that replaces the old traditional framework you would have had to pull in. So, it aggregates and integrates various managed services to assemble a modern-day application we discussed in previous episodes.
Enterprise Service Bus versus Event-Driven Architecture
In the past, standing up an enterprise service bus needed a lot of money and time, even with some of the old IBM stack we’ve used. Now you can do this yourself. It’s inexpensive, allowing you to experiment rapidly, get good feedback and learn quickly. And you can give it to your teams without fearing it costing a fortune.
In the past, we remember our five-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 daunting. Let’s look at the challenges of standing up event-driven architecture.
The Socio-Technical Challenge
A lot of the challenges in event-driven architecture are socio-technical. Do you do good domain-driven design? What are your boundaries? Are your teams aligned with that bounded context and those domains? Who owns them?
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. Do you need to tease out who the actual users are? And what are their needs? What types of events 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 brainstorming, to tease those things. You can find an excellent presentation from Martin Fowler from a previous AWS re: Invent about three events. Gregor Hohpe did that as well on EDA day.
Engineering rigor and discipline on how to event
Once you’ve defined your domains and have better consistency, you need engineering rigor and discipline around how-to events. More importantly, the tooling around how are to event, like transactionality, correlations, and item potency. They’re all problems you can solve
What we like about Serverless Espresso is the simple interactions. You order, it goes to the barista who makes the coffee, and he gives it back to you. There’s one interaction. Usually, when ordering a coffee, you talk to a server, the server talks to the barista, and the barista talks to someone about milk, etc.
There can be six or seven people in that flow. It confuses. 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 that needs to happen.
Who is the customer, and what business flow are we trying to build? And let’s have a good debate on how we will 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 EDA has solved the underlying stuff apart from making it behave.
Position teams high up the value chain
You need to position your teams high up the value chain. And suppose they’re chasing their tail with a low level of technology, trying to stitch stuff together. In that case, they can’t be talking about higher-order things or 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 unique capability or offering.
You remove many undifferentiated things by adopting the technologies that Serverless Espresso Lab advocates. 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?
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 primarily 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.