In our recent let’s study together. We received some great questions at the MicroServices event for.NET. We’ve been answering a lot of questions on the floor, but we want to continue answering some of the most popular questions that came up during the conference. If you miss the live broadcast, don’t worry, because you can watch it on demand.…

As we scale these services, how do we scale the databases associated with these services?

There are well-defined patterns and best practices that can improve performance and scale a database. To learn how to partition data into partitions to improve scalability, reduce, and optimize performance, see Horizontal, Vertical, and Functional Data Partitioning. For an in-depth look at the scalability of microservices, distributed data, why each microservice has a database, and the choice between a relational database and a NoSQL database, check out our guide on building cloud native.NET applications for Azure or download the free ebook.

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

The autonomy of teams to use microservices is an important benefit of building cloud-native applications. In order to give the team the flexibility to roll out updates, security patches, and bug fixes in production without breaking other microservices, it is best to use a separate database instance. The native cloud application architecture is inspired by the well-known 12-element application methodology. One of the elements, “support services,” states that secondary resources such as data stores, caches, message brokers, and so on should be exposed through an addressable URL. Cloud providers offer a rich variety of hosting support services. Rather than owning and maintaining your own database, we recommend checking the database options available in the cloud.

Can a single Web API communicate with a microservice?

Yes. A monolithic application can communicate with a microservice if its endpoints are reachable in the infrastructure or are accessed securely using a common endpoint. Microservices and their data can be consumed synchronously through their endpoints or asynchronously through messaging (such as an event bus). As part of the modernization of technology, we recommend strangling patterns that facilitate the gradual migration of old systems. As part of the solution, you need to create a facade to block requests. The facade routes these requests to the old application or the new service. For more information on microservice communication and modern technologies, see the.NET Architecture Guide.

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

That’s a good question. This issue is explained in detail in two sections of the book Building Cloud Native.NET Applications for Azure. These links will help you:

  • Native cloud communication mode or download free e-books.
  • Manage data in distributed applications.
  • You can also download a free ebook on the microservice architecture guide, which covers patterns such as DDD, CQRS, event sources, etc.

Do microservices need to use containers?

It’s not necessary. However, using containers also has its benefits. Microservices, often referred to as microservices architecture, are design guidelines and best practices. It helps you decompose your application into smaller services defined by specific business boundaries that are managed independently by smaller teams. A container combines an application and its configuration and dependencies into a single, stand-alone deployable unit. Containers are ideal for binding and deploying stand-alone microservices. You can see the benefits by writing the first microservice endpoint and containerizing it.

More MicroServices resources

Are you looking for more microservices and native cloud resources for.NET development? Stay tuned to Microsoft blogs and official documents. If you have any question, welcome to the Microsoft Q&A BBS to ask:…