We've been talking about AWS re:Invent over the last few episodes. But one thing that we haven't talked about is Serverless Espresso.
Serverless Espresso is a pop up coffee shop that allows you to order coffee from your phone. 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. So you scan the QR code and enter in 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 in the screen as a number. And 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 as they've been using it as a way to explain serverless event driven architecture. 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 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.
There are two myths in this space that AWS are 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 event of architecture than it would have been years ago. The technical challenge is not as bad as you think it is.
What I 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. 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.
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 which 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.
Look at the Serverless Espresso Lab on workshop.serverlesscoffee.com. Or search for Serverless Espresso. And big kudos to the AWS Serverless Develo
Welcome to the next edition of Serverless Craic with Dave Anderson, Author and Contributor at The Serverless Edge and Technical Fellow at Bazaarvoice.
Mark McCann:
Mark McCann, Architect at Globalisation Partners and Author and Contributor at The Serverless Edge.
Michael O'Reilly:
Michael O'Reilly, Software Architect with GP and Contributor at The Serverless Edge.
Dave Anderson:
We've been talking about AWS re:Invent over the last few episodes. But one thing that we haven't talked about 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 this year. 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. So you scan the QR code and enter in 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 in the screen as a number. And 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 as they've been using it as a way to explain serverless event driven
Mark McCann:
Werner Vogels called it out in his keynote as architecture. 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 to 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.
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. 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 Espresson is a real time application that can 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 have 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's lots of other workshops that are that are equally as good for getting started with these technologies.
Dave Anderson:
There are two myths in this space that AWS are 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. Thatis 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 event 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 maanged services to assemble a modern day application that we have talked about in previous episodes,
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 evemt driven architecture?
Michael O'Reilly:
A lot of the challenges in event driven architectures are socio technical. Do you do good domain driven design? What are your boundaries? What teams are aligned with those 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 up front.
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 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. Well, that's
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.
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 reagrds 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 organisational 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 he 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 is split over several teams and departments. you are right, Michael, it is a socio technical problem.
Mark McCann:
It's about making it visible, by baking in event storming to tease it all out. And get a shared language and a understanding of the actual process. Use a better context canvas to undestand 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
Michael O'Reilly:
In regards to the org, if you're looking at produce. 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.
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 which 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
Mark McCann:
You need to position your teams high up the making it behave. 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. Follow us@ServerlessEdge on Twitter and on TheServerlessEdge.com blog. And subscribe to the Serverless Craic YouTube channel as well. Thank you very much!