"Microservices" was the buzzword during the conference with over half of the talks mentioning them and a few diving quite deep into the topic, e.g. Michele Leroux Bustamante with her session "Surviving Microservices". Here's a pretty diagram of what to imagine when hearing "microservices":

[Diagram credits go to Chris Richardson from microservices.io]

Why Microservices?

Well, there are some neat things to learn from a microservices architecture:

• a microservice forms the smallest architectural quantum (term coined by Neal Ford et al.) i.e. a part of a system's architecture that can be managed separately from the rest of the system
• microservices can be developed and deployed by independent teams on individual schedules, thus minimizing coupling and risk of failure
• microservices can be easily scaled out
• Docker plays an important role in the deployment story

During Development

• use a separate source repository per service
• create NuGet packages for them, that can be versioned, and let consumers of your service decide when they are ready to upgrade
• set up infrastructure early: Docker, DevOps, CI, CD

Troubleshooting

Well, with a distributed architecture such as one consisting of microservices, troubleshooting can become a real challenge. That's why it's important to implement something along the lines of an activity id that will be attached to every action processed in any of the microservices. This id can later be used to follow the flow of a business process through the application.

Wise quote at the end

Once you've accepted your flaws, nobody can use them against you.

Thank you. Happy microservicing!