3 wonderful workshops that will make your serverless architecture agile
Successfully building a serverless system as a team is far from easy. So, here are 3 DDD workshops for everyone to do collective and incremental architecture.
Note: This post was originally published on the Serverless Mindset. A follow up ‘review’ post will soon be published!
It’s actually harder to do serverless development with two engineers than it is with one engineer. And [the problem] scales up (Nathan Taggart[^1])
Rise and fall of a serverless project
Imagine you’ve just started your new serverless project. Every commit you make is automatically pushed to production for you! It feels so productive. It’s such a change compared to your previous job!
Fast forward a few months, the team has grown, and everybody is pushing to production. For better or worse, new lambdas appear every day, making it difficult to keep track of all dependencies. Improved developer autonomy is turning into anarchy!
Fast forward yet a few more months. The system has become so tangled that it is now impossible to deploy lambdas independently. Everything must be updated at once. You have built a monolith that is distributed on the cloud! Management has set up strict governance on the creation and deployment of lambdas. Your previous job did not look so bad in the end!
Let’s see how to avoid this horror story!
The middle way
The promise of serverless is to free development teams from most infrastructure work. Serverless systems are also meant to be scalable, cheap to run, and quick to update.
Unfortunately, as a team, things get a bit more complicated. Without enough coordination, it is easy to end up with a distributed monolith. With too much coordination, we end up with centralized, top-down, command-and-control management. Both extremes kill the serverless promises!
Wouldn’t it be great if you could leverage your team’s collective intelligence to build clean serverless systems?
Here are three workshops that will unlock agile architecture for your serverless system. And… one last thing, these workshops will also make work calmer and more effective!
Big-Picture Event Storming
Big-Picture Event Storming is a whole-team workshop whose purpose is to visualize everything! It’s about sticking all the domain events of the system on a giant design board. It’s Domain-Driven Design in practice! It transfers tremendous knowledge between the domain experts and the developers.
An architecture accelerator
Event Storming can achieve over a few days what would take months with traditional architecture. The idea is not to get a perfect up-front architecture. Instead, it’s to design just enough for everyone to pull in the same direction.
Big-Picture Event Storming usually lasts between 1 to 3 days, and it scales well so that everyone can join. It works best when everyone is in the same room. However, it can work remotely with good preparation and adaptation. I wrote a guide about how to facilitate your first Big Picture Event Storming. If you don’t feel like running one yourself, you can also ask a technical agile coach or a DDD expert for help. Yet, facilitating an Event Storming is a lot simpler than it looks, and it’s a skill worth learning!
The first outcomes of Event Storming are:
- Greater alignment so that everyone pulls in the same direction.
- Better collaboration between the different profiles.
- Agreed upon vocabulary that everyone can use when communicating and in the code!
Bounded Contexts
One crucial outcome of the Big Picture Event Storming is identifying Bounded Contexts. Domain-Driven-Design Bounded Contexts are the main functional areas of the system. Bounded Contexts provide excellent clues about splitting the code into coherent and independent sub-systems. Long-term, it makes the entire codebase easier to maintain and evolve.
Identifying the Bounded Contexts opens many opportunities when building a serverless system:
- When built around Bounded Contexts, teams are more autonomous and require less synchronization. (You can learn more on this topic in Team Topologies).
- People have figured out that Bounded Contexts also make great candidates for microservices. (Remember How Microservices Can Help Your Team.
- Serverless is an opportunity for Nanoservices: Make Your Code More Maintainable by Going More Granular. Yet, Bounded Contexts might still be opportunities for code reuse between services.
- Bounded Contexts can help you focus your efforts on what is key to your business! You can agree on which bounded contexts are your business core on which you should focus. (Check Nick Tune’s Visualizing Socio-technical architecture with DDD and Team Topologies.)
- You can even start defining APIs and protocols around your context services. (If you want to learn more about this, check out Nick Tune’s Business Model Canvas.)
- Bounded Contexts are also helpful if you are working on improving an existing system! The key is for everyone to align on a target architecture using Bounded Context. This alignment will influence the countless design decisions developers make every day.
Scope
Finally, the map of domain events is also a great way to negotiate the scope of the next increment to build. Just select events all along the chronology to draw your walking skeleton.
Design-Level Event Storming
Many ‘non-serverless’ teams stick to Big Picture. Once the bounded contexts are identified, it’s possible to adjust while coding. Yet, Design-Level Event Storming is very useful for distributed and event-driven systems.
That’s why Design Level Event Storming shines for serverless!
Design-Level Event Storming comes after Big-Picture:
- It’s a way to ‘zoom-in’ a core bounded context.
- It lets participants look into finer-grain Domain-Driven Design elements.
Design-Level Event Storming is an excellent activity to find the Aggregates in the system. DDD Aggregates are grapes of objects that enforce the atomicity and integrity of changes. They actually make perfect candidates for service APIs.
In serverless systems, Aggregates make good candidates for lambdas. In How Serverless influences Design, Gojko suggests splitting serverless Aggregates even further. He relies on 2 reasons:
- Cost: the smaller the lambda, the more granular, the less it runs, the less it costs!
- Code independence: if the lambda is small enough, it becomes easy to rewrite if needed!
During an Event Storming: everyone is in the room, and all the input and output events are on the board! There is no better time to split the Aggregates!
Here is the essence of Event Storming: Visualize everything on a board. It’s a powerful way to ensure everyone sees all services and how they interact. As a result, it’s one of the most effective tools to avoid building a distributed monolith.
If you have facilitated a Big-Picture Event Storming, drilling down to Design-Level is not too different. Here is a facilitation guide for getting you through your first Design-Level Event Storming.
Example Mapping
The promise of serverless is that the cloud provider will take care of all the plumbing for you. This means that your lambdas should contain almost only domain-oriented code. Example Mapping is a neat activity to clarify the lambda’s business rules.
Example Mapping only takes 20 minutes, so you can run it very often. For example:
- When starting a new user story.
- Or after a Design-Level Event-Storming, to clarify what happens inside an aggregate.
Example Mapping is a structured conversation between Developers and Domain experts. Other specific profiles (ex: quality engineer) can also join depending on the need. It uses colored cards to take shared notes during the conversation:
- Yellow for the user story title.
- Blue for business or domain rules.
- Green for test cases that illustrate the rules.
- And finally, Red for pending questions.
Example Mapping is also an entry point to Behaviour Driven Development. These note cards are easy to translate to executable tests and living documentation. Living Documentation is particularly useful for serverless (Don’t Test the Cloud Service, Test Your Business Logic Instead. If your lambdas are small enough, it becomes easier to rewrite than refactor them! Living Documentation tests will make this rewrite safe and fast:
- They are written in a language that is independent of design or technology.
- They are very stable in time because they rely on the domain only.
Example Mapping is straightforward to learn and simple to put in place. You don’t even need to ask for permission:
- Practice with a few colleagues.
- And just take and share notes during an impromptu call with a domain expert.
Finally, Example-Mapping is also remote-friendly. This post contains a spreadsheet template to replace cards during a video call.
Don’t wait!
Are you involved with building a serverless system? Whether you are just starting or already deep in, you should run a Big-Picture Event Storming! It’s a starting point that will lead you to Design-Level Event Storming and Example Mapping. These workshops will result in:
- Alignment between everyone.
- Just-enough architecture to keep your system healthy and to avoid centralized decision-making.
What about you? Do you know other workshops that are useful for agile serverless architecture?
Do you want to learn more about Event Storming? Check out our writing-in-progress book: 1h Event Storming book.
Leave a comment