"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!

Although the choice of the best session was not easy, it has to be awarded to Sasha Goldstein with his session on performance detective work. His session was very well prepared, had a clear goal and path, was packed with insights into challenges and problems during performance investigation work, and offered hand-crafted solutions like his own realtime ETW event tracing tool etrace. What follows is an excerpt of Sasha Goldshtein's presentation. Structure of a Performance Investigation Obtain the problem description Build a system diagram Run a quick performance checklist Understand which component is exhibiting the problem Investigate thoroughly Find the root cause Resolve the issue Verify resolution Conduct and document post-mortem Performance Metrics, Goals, Monitoring Performance metrics don’t live in a vacuum! Derive performance metrics from business goals Monitor these metrics in your APM solution, home-made dashboard, or collection script, and get alerts Investigation Anti-Methods Make assumptions Trust “instincts” and irrational beliefs Look under the street light Use random tools Blame the tools The USE Method USE: Utilization, Saturation, Errors Build a functional diagram of the system, including hardware/software resources For each resource, identify utilization, saturation, and errors Understand, resolve, and verify errors, excessive saturation/utilization, under-utilization Statstics Lie Be Careful With Statistics Averages are meaningless Medians are almost meaningless Percentiles are OK if you know what you’re doing Find good visualizations for your performance data Beware coordinated omission Look at histograms or sometimes even percentile plots aka cumulative distribution charts to really understand your data, e.g. your performance traces. Just look at this dinosaur to understand that very differently shaped data can lead to the same statistics values: Conduct a Postmortem – Do It! Document the steps taken to identify, diagnose, resolve, and verify the problem Which tools did you use? Can they be improved? Where were the bottlenecks in your investigation? Can you add monitoring for sysadmins/ops? Can you add instrumentation for investigators? How do we triage this problem automatically next time it happens? Resources etrace: a real-time, command-line frontend for ETW events –> https://github.com/goldshtn/etrace LiveStacks: a real-time, command-line stack collector and resolver –> https://github.com/goldshtn/LiveStacks BenchmarkDotNet is a powerful .NET library for benchmarking: http://benchmarkdotnet.org/ HdrHistogram: A High Dynamic Range (HDR) Histogram –> https://github.com/HdrHistogram/HdrHistogram Slides: How NOT to Measure Latency: https://www.azul.com/files/HowNotToMeasureLatency_LLSummit_NYC_12Nov2013.pdf Blog post: Windows Process Memory Usage Demystified Course: Statistics for Engineers – https://github.com/HeinrichHartmann/Statistics-for-Engineers (use http://nbviewer.jupyter.org/ to view the ipynb files) And now, happy performance hunting!

A colleague of mine and I attended the .NET Developer Days conference this year. It was my third time participating; he was there for the first time. Here are links to the complete agenda and the pre-con workshops. My personal conference schedule Wednesday, October 18th Programming ASP.NET MVC Core (abstract) Dino Esposito @github Thursday, October 19th Surviving Microservices (abstract) Michele Leroux Bustamante – Opening Keynote Build Web Apps the “Progressive” Way (300) (abstract) Jeff Burtoft @github Async/Await and the Task Parallel Library: await headexplosion (400) (abstract) Daniel Marbach @github Setting up a CI/CD pipeline for a Containerized Project in VSTS (200) (abstract) Maciej Misztal – Sponsor Session Adding History to CRUD (400) (abstract) Dino Esposito Software Architecture That Every Developer Should Know (300) (abstract) Alon Fliess Building for the Future without Abandoning the Past (200) (abstract) Jeff Burtoft Friday, October 20th Performance that pays off (300) (abstract) Szymon Kulec @github The Performance Investigator’s Field Guide (300) (abstract) Sasha Goldshtein Building Evolutionary Architectures (300) (abstract) Neal Ford Securing .NET applications in Azure (300) (abstract) Sebastian Solnica – Sponsor Session How I Built An Open-Source Debugger (300) (abstract) Sasha Goldshtein Stories Every Developer Should Know (abstract) Neal Ford – Closing Keynote Random notes about the conference Predominant Topic Microservices are everywhere – this is my take on it Best Session The Performance Investigator's Field Guide – here I've shared my impressions Catering Inter Bankiet delivered fantastic food and drinks, including lots of good coffee and sandwiches Event Venue EXPO XXI, Warsaw – a good place for the conference, a few walking minutes from Warszawa Zachodnia Summary The 2017 edition of the .NET Developer Days was a success. I still have to process my notes and all the input I've gathered there. I will update my personal conference schedule with links to my own digest posts of the sessions where it makes sense. If you want to attend the 2018 edition, you will be able to catch a super early bird ticket from the beginning of December! Happy conferencing!