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

We've experienced in the past that deploying new features before the weekend is not a good idea because potential bugs are not discovered in a timely manner and our reaction times to critical problems are also longer over the weekend than during the week. So for a couple of years now, we've stuck to our no-deployments-on-weekends policy, and every once in a while an exceptional deployment with either some "very important" new feature or "only small changes, nothing big" reminded us that it was really a good idea to deploy only on weekdays. There was one downside to this: we always missed out on getting fresh bits on our servers on Monday morning because someone had to trigger the deployment by doing a push to a dedicated Git repository before our TeamCity deployment configuration started to run at 2:20 am. Most of us usually don't work on Sundays so there usually was no-one to do that. Using a CRON expression in your trigger It turns out, TeamCity supports date/time triggers defined by a CRON expression: Since I don't use cron on a daily basis and don't speak cron fluently, I was glad to stumble upon Cron Maker which was a great help with getting the syntax right: Having a tool like this in my tool chain makes me confident and I won't avoid using CRON or its powerful expressions in the future! Happy cron'ing!