Just as there is no one set definition for a microservice, there is also not one set architecture. What we will do is make a list of some of the characteristics that we view a microservice architecture to have. That list would then look something like this:
- Each microservice can be deployed, developed, maintained, and then redeployed independently.
- Each microservice focuses on a specific business purpose and goal and is non-monolithic.
- Each microservice receives requests, processes them, and then may or may not send a response.
- Microservices practice decentralized governance and in some cases, when permissible, decentralized data management.
- Perhaps most importantly, at least in my mind anyways, I always design a microservice around failure. In fact, they are designed to fail. By following this paradigm, you will always be able to handle failures gracefully and not allow one failing microservice to negatively impact the entire ecosystem. By negatively impact, I mean a state where all other microservices are throwing exceptions due to the one errant microservice. Every microservice needs to be able to gracefully handle not being able to complete its task.
- Finally, let's stay flexible and state that our microservice architecture is free to remain fluid and evolutionary.
- No microservice talks directly to another microservice. Communication is always done in the form of messages.
With all that in mind, we've now created our definition of a microservice and its architecture and characteristics. Feel free to adjust these as you or your situation sees fit. Remember, as C# developers we don't always have the luxury, save truly greenfield projects, to dictate all the terms. Do the best you can with the room you have to operate within. As an example, chances are you will have to work with the corporate database and their rules rather than a small siloed database as described earlier. It's still a microservice, so go for it!