We’ll run a microservices workshop on Oct. 13th. I thought that it might be interesting to provide some background on the why and how.
The core problem in moving to microservices is figuring out system- and transactional boundaries. This is because without that the result will be bug prone and expensive/time consuming to maintain and enhance due to side effects and project coordination overhead.
We experimented a lot with teaching this in meetup- and workshop settings in recent years. As a result, we have boiled it down to three learning objectives which we’ll tackle in turn:
– Understand: The tools we’ll use to solve the problem (CQRS and Event Sourcing – Greg Young has kindly agreed to facilitate the intro and a Q&A) and the business problem we are going to solve (through event storming). The example business problem will be realistic and substantial enough to include an integration with legacy code and other assorted complications.
– Divide. We’ll use our understanding of the tools and the business problem to learn where one service ends and another one begins. This allows us to break the problem down in a meaningful way so that we can have several groups of participants, each building a separate microservice. We then project plan (Kanban boards and all) and coordinate the delivery work for the next step:
– Conquer. Table groups work together to to deliver a REST API (in NodeJS) for the service they have specified in the previous step. Getting this far would normally be a stretch in a one day workshop, so we’ll use an alpha version of Adaptech’s event sourcing platform to give us a hand. We tried this on previous occasions and it does make it possible to get good results in that time frame. The resulting source code will be made available to participants for further study after the workshop.
|09:00 – 10:30||Introduction to CQRS, Event Sourcing & Microservices (Greg Young)||Understand|
|10:30 – 11:00||Understanding business requirements through Event Storming||Understand|
|11:00 – 12:00||Using Strategic Domain Driven Design to establish microservice boundaries and plan legacy integrations.||Divide|
|12:30 – 13:00||Project managing microservice projects||Divide|
|13:00 – 17:00||Hands-on microservice construction. (Activities & exercises, code)||Conquer|
Format & Motivation
We shaped the workshop curriculum so it takes into account some of the evolutionary wiring which determines how humans learn:
– Relevancy. We are naturally wired to tune out the irrelevant. The approaching sabretooth matters more than the pretty shapes of the clouds above. This is why we tend to poll the audience and/or do introductions at the beginning (you may have seen this at our meetups or corporate workshops) – it allows us to tailor the experience to what matters to the people in the room as much as possible throughout the day.It’s the reason why even the one-day workshop uses an example that’s “guided” rather than “prescriptive”: Instead of canned code that may or may not resonate with participant’s real problems and levels of experience, we use the Adaptech platform to build something in the same problem space, but a little bit more customized:We make an effort to relate it to real-world problems at every step.
– Declarative vs. procedural knowledge. Declarative knowledge allows us to name, explain and talk about matters (“Explain event sourcing and CQRS”). By contrast, procedural knowledge allows us to act and do things. The workshop activities are designed to gradually build participant’s ability to do the latter as the day progresses so they can apply the knowledge in their everyday work. To this end, we start with activities around explaining/understanding/communicating and progress to procedurally focused ones (doing, acting, “hands-on”).
Future Workshop Plans
We are going to offer a completely customizable two day workshop which will literally allow a team to “come with an idea, leave with a working system”. It’ll have the one-day “guided” version as a prerequisite. Talk to us if you’d like to run it at your organization.
In another career, Robert Reppel has designed and taught programming- and other courses and workshops in academic and industry settings. He is now Adaptech’s CTO.