In my capacity as a Dotnet developer I have worked with various teams, companies, and industries, and I have met some crazy characters but some brilliant professionals as well. Often I found the debate within these teams where there is a developer who is against anything new that is not their monolith application from 10 years ago vs a developer who is waiving hands above head to get the team to move to microservices.

In this article, I will give my opinion and it will get spicy, and there will be disagreement. That is ok, it's called free speech and it's ok to have healthy disagreements. :D

So Your Team Is Considering Microservices?

Please upgrade your codebases to the latest long-term supported version of Dotnet. Be nice to your new hires and have decent automated CI/CD pipelines and no manual Powershell scripts to move code between environments or even worse continue to RDP to VMs and copy your DLLs to the new new new directory. Don't be that legacy team that fears the new and dismisses innovation.

Microservices won't fix your culture, or your bad coding habits, or overnight solve your scaling problems, just worsen them. You have to get clear on your organization's communication structure and what value your product provides to the customer. Clearly define your domain and your bounded contexts.

Whatever your reason to change architecture you, your team, the executive, and the stakeholders all have to be on the same page. Failure to do so will lead to misalignment, and constant change in priorities and your team will neither get the budget nor time. If there is a team member not on board they will become a hazard to your project and will sabotage the project. If your business does not care about anything technical and just wants new features, i.e. the company is a feature factory then you are in for a crazy time like changing the engine and tires while the vehicle is traveling at high speeds. All is not lost and there are patterns and practices to deal with these challenges.

Finally, whether you are new dev or an old-grey beard dev get comfortable with failure and learn to fail fast. You can't afford to code for months and only have one release day or week every other month. The cost of finding out the value you thought you are delivering is not aligned with what the customer wanted might sink your company. Close the feedback loop with your customer and get that feedback to your dev team asap.

The Spice Must Flow

If you explain your system like this and want to go the microservices route:

You are in for a rough time friend. My recommendation is either to start anew, but it's expensive and will take time. Or go clean up your data, get crystal clear on your domain, bounded contexts, and value offer then come back to relook microservices.

Before you grab your favorite Reddit keyboard and come after me let's put ego aside and cut the BS:

• Code split into separate projects while everything still points to the same DB is not microservices, it's a distributed monolith.
• "I have rolled my own pub-sub using a shared DB". Don't do this, please use a message or event bus which is decoupled from your services.
• Naming your services after Marvel or DC characters is not showing off your intellectual capacity but rather your lack thereof and it's annoying AF. Be clear and concise with your naming on why this service exists and what it does.
• Don't be the guy: "but Netflix and Spotify do...". No, chances are your company is nowhere near this scale and will not have the dev capacity to build & maintain 500 services in a given quarter.
• If you are starting in a new unknown domain where there is lots of experimentation and high code churn then a small monolith might be a better call as you can move faster however aim to refactor it into MS architecture once the domain has revealed itself and you are looking to scale your code, dev team, and product at scale. Note: Getting it wrong would result in years of balancing refactoring and product deliverables while struggling to scale your team and platform.
• No, microservices or any cloud service will not solve your scaling and performance issues when your code is unoptimized and the whole system is a big ball of yarn.
• Going from monolith to microservices is a process that does not happen overnight and comes with a refactoring cost.
• Refactoring and breaking apart code is easier than doing it with a single massive database where it has no source control, and relies heavily on domain-stored procs which in turn are interconnected with each other and other DBs.
• "Making a change in module A leads to an unrelated break-in Module Z", then you have a classic monolith issue with tight coupling and your DDD has unintended side effects. This will be a thorn in your side when refactoring to microservices later, fix it if you can.
• "It's one architectural style vs the other". No, it's about time, cost, and quality. Each has its own trade-offs and needs to be clearly understood before going to business with an architecture plan.

The good news is if you are stuck on the monolith from hell you have options.

If your system is not at this level required then Azure App Services might be an alternative and is a mature cloud service with great documentation you can do a gradual migration to containers, runs on IIS, and comes in a few variants. First, get your system off of VMs and manual deployments to free up the budget and dev time for refactoring.

"You hold on for 1 minute there sir", my monolith architecture is perfect and adheres to all the software architecture acronyms you can throw at it.

Great stuff, you get a gold star and your migration path should be relatively straightforward as long as you continue to follow best practices when breaking the monolith apart.

To be clear, I prefer to work in a microservice architecture and have seen the increased rate of delivery, stability, and redundancy contribute to successful products that were critical for business growth. In my career thus far I have yet to come across a perfect monolith many developers rant and rave about. But I have also seen some bad microservice implementations and most of the time it was a failure due to broken down communication between the business, developers, and customers.