Building Microservices With .NET - .NET Microservices Courses

Does this sound familiar?

In the early days of your project, everything was great: the small code base was easy to understand, you could add features and fix bugs quickly, you could verify the whole app was working properly with just a few manual tests and you were able get a new version up and running any time your boss asked to show your progress.

A year later, your customers are loving your app, but now that your team has grown and you have to deal with thousands of lines of code, things are not fun anymore:

The code base is too complex to understand and explain to new team members, which makes adding new features and fixing bugs difficult and time consuming
Loading and building the code in your IDE keeps getting slower. It's painful to make even one-line changes
The app keeps breaking very frequently now that there are so many devs making changes at the same time. Even a small bug in a single module can break the whole thing
You keep missing deadlines. With so much to build and test, you can only release new bits once a month, and usually late on a Friday or Saturday night
Scaling to handle the increasing load is too hard. Getting new servers, configuring them, deploying your app there, etc. And when the load goes down, so much wasted server power.
Move to the latest .NET stack? Only a dream. It would mean rewriting a crazy amount of code, not to mention the time needed to verify all features keep working properly and reconfiguring your production environment for the latest tech

There must be a better way, right? After reading a few blog posts and watching some YouTube videos, you realize you are suffering from a case of monolithic hell, and you keep hearing that the way to get out of this mess is to adopt a microservices architecture.

What are microservices?

Business aligned, loosely coupled services

Microservices are an architectural style that structures an application as a collection of autonomous, loosely coupled services that are modeled around a business domain. Each microservice is focused on doing one thing well.

Owned by small, focused teams

A microservice is small enough that a single feature team can own it. Small team sizes promote greater agility. Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.

Built and deployed independently

A team can update an existing microservice without rebuilding and redeploying the entire application and roll back an update if something goes wrong. In traditional applications, a bug found in one part of the application, can block the entire release.

Hi, I'm Julio

My name is Julio Casal. I'm a passionate software engineer with almost two decades of experience building all sorts of applications and systems based on the .NET platform.

I like to continuously explore the latest software engineering trends and practices and use them to solve real world problems.

I believe reducing complex concepts into simple step by step instructions is incredibly valuable and helps to make coding accessible and fun for everyone.