Clever Geek Handbook

Migrating to Microservices for .NET Applications - Some Questions

I would like to start sharing my microservices apps. My first challenge is to remove functionality that is repeated in each of our applications. Things like sending emails, exporting, searching for indexes, etc. - material in which the same or similar code is repeated in every application.

I just feel a little overwhelmed and struggle to get started. I understand that the goal of microservices is that you can pick the right language to work with, but for our current goals, I am assuming that .NET will be the main framework in which I will build everything.

Basically, to begin with, I want to create a microservice that just sends emails that all of our applications can talk to and send them via email. I thought that the sender of the email has the logic for sending the email, but every application has to specify recipients, body, etc.

I am struggling with things like:

  • What protocol should the application use to communicate with this service? REST over HTTP? If so, is the email sending the microservice really just going to be Web API 2 (which is what I personally would run into if I had to create a REST api).

  • If I'm going to REST, what is the best way to make frequent calls from the backend? Most of the emails on our system are sent through the backend code right now. I've seen the name RestSharp which is generally considered the best.

  • Future planning, I think having some kind of gateway that knows about all the services would be helpful so that every application only knows about that gateway and then the gateway speaks about any services it needs. Will it just be another REST API between apps and microservices?

Sorry for all the questions, just running all these things (and architecture in general) to activate your workspace, and get a little bit involved with it.

+3


source to share


2 answers


Since email is inherently an asynchronous process (fire and forgetting), and often requires the use of several untrustworthy resources, it is better to integrate them with a message queue (MSMQ, RabbitMQ, etc.) and they tend to have pretty decent API.net.



If you're going beyond simple things like email, it might be helpful to look at a larger scope around queues to better support retries, error management, transaction management, etc. They are often referred to as "service bus" "technologies and there are a couple of good free OSSs on .net including MassTransit and Rebus . If / when you are looking for a fully supported .net service bus, you will probably find NServiceBus , which is in the interest of full disclosure. the author of the original.

0


source


This is a really big question. When you go into microservices, you need to remember that a lot of your headaches will work (devops oriented), not "code".

Plus, there are so many out there that at some point you just have to make a decision, regardless of whether it's optimal. In any case, everything will change. Make the best decision you can make right now, go with it, and check it out later.

As far as your questions go, REST is common practice. There are other options as well (WCF, Avro, whatever). Give yourself time to make a decision. If you know REST and are comfortable with REST, make a decision. Try to see if you can build it so you can change / add other protocols later, but don't make it delay you too much.

Like Udi, some architectural considerations are concerned if you need to call this overhead sync or async (via the message bus). Also, yes, consider opening a service. There are several options (zookeeper, consul).



For some background and overview, try going through some of the resources:
http://blog.arkency.com/2014/07/microservices-72-resources/

This also gives a quick overview of microservices models:
http://microservices.io/patterns/microservices.html

But then again, there is a lot of information and ways to do things without fussing.

0


source






More articles:


All Articles