Your Top .NET Microservices Questions Answered

Nish Anil

In our recent Let’s Learn .NET event focused on getting started with microservices we received some great questions from you. We were able to answer many questions live, but we wanted to follow up and answer some of the most popular that came up during the session. If you missed the live event, don’t worry because you can watch it on-demand.

Watch on Channel 9

There are well-defined patterns and best practices for improving performance and scaling databases. Refer to Horizontal, vertical, and functional data partitioning to understand how data is divided into partitions to improve scalability, reduce contention, and optimize performance. To go deep-dive into Scaling microservices, Distributed data, why database-per-microservice, choosing between Relational vs NoSQL databases, refer to our guidance on Architecting Cloud-Native .NET Apps for Azure or download the free e-Book.

Do we need to use a new Database for each microservice, or can the microservices share the same Database instance?

Autonomy for teams to work with their microservices is a crucial benefit of architecting cloud-native apps. It is preferred to use independent database instances to give the teams the flexibility to roll out updates, security patches, bug fixes in production without breaking other microservices. Cloud-Native app architecture takes inspiration from the famous 12-factor app methodologies. One factor, “Backing Services,” states that the Ancillary resources like the data stores, caches, message brokers should be exposed via an addressable URL. Cloud providers offer a rich assortment of managed backing services. Instead of owning and maintaining the database yourself, we recommend checking out the available database options in the cloud.

Can a monolithic Web API talk with microservices?

Yes. Monolithic apps can talk with microservices if their endpoints are reachable within the infrastructure or securely using a public endpoint. Microservices and their data can either be consumed synchronously via their endpoints or asynchronously through messaging like the Event Bus. As part of modernizing techniques, we recommend the strangler pattern, which helps in incrementally migrating a legacy system. As part of the solution, you need to create a façade that intercepts requests. The façade routes these requests either to the legacy application or the new services. To learn more about Microservices communication and modernizing techniques, refer to the .NET Architecture Guidance.

If microservices are loosely coupled and deployed independently, how do they communicate with each other? How do you synchronize data between microservices?

This is a great question. The answer is explained in detail in two sections of the book Architecting Cloud-Native .NET Apps for Azure. These links will help you:

Do microservices need to use containers?

Not necessary. However, using containers has its benefits. Microservices, generally known as Microservices Architecture, are design guidance and best practices. It helps you decompose your application into multiple smaller services defined by specific business boundaries that are independently managed by smaller teams. Containers combine an app plus its configuration and dependencies into a single, independently deployable unit. Containers are an excellent fit for bundling and deploying independent microservices. Get started writing your first microservice endpoint and containerizing it to see the benefits.

More microservices Resources

Looking for more microservices and cloud-native resources for .NET development? I have you covered in my recent blog post highlighting blogs, videos, eBooks, documentation, and more.


Discussion is closed. Login to edit/delete existing comments.

  • Miguel Guzmán-Centeno 0

    From an architectural point of view, is it possible to create a hybrid solution in which it can be deployed as a monolithic application as well as a microservice-based application with minimal effort? For example, the same DLL being the main part of a microservice as well as part of a monolithic solution.

    • Fernando Borrego Polo 0

      As a general rule it’s not a good idea because then you are creating a hard dependency, any time you change that shared code you are force to deploy both systems. Other than some DTOs to exchange information, services (not even microservices, but any kind of independent service) should not share code with other services. My preferred approach would be to start separating the code internally before even creating a new microservice, what sometimes is called a loosely coupled monolith. If you search for that term you will find plenty of articles and videos on how to evolve your monolith this way.

Feedback usabilla icon