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

When we scale the services, how can we scale databases related to those services?

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:

• Cloud-Native Communication Patterns or download the free e-Book.
• Managing data in Distributed Apps
• You can also download the free e-Book on Microservices architecture guidance which covers some patterns like DDD, CQRS, Event sourcing etc.

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.