.NET Developer Days 2017: Microservices Everywhere

by Oliver 27. October 2017 09:00

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

Run Web Application Deployment in TeamCity – Only on Weekdays

by Oliver 26. May 2016 22:12

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!

About Oliver

shades-of-orange.com code blog logo I build web applications using ASP.NET and have a passion for javascript. Enjoy MVC and Orchard CMS, and I do TDD whenever I can. I like clean code. Love to spend time with my wife and our three children. My profile on Stack Exchange, a network of free, community-driven Q&A sites

About Anton

shades-of-orange.com code blog logo I'm a software developer at teamaton. I code in C# and work with MVC, Orchard, SpecFlow, Coypu and NHibernate. I enjoy beach volleyball, board games and Coke.