In this post we'll explore our options regarding how different services could communicate with each other. There is no code in this post, we'll just explore some different architectures and the trade-offs included with each one. In the end you can make up your own mind about your own specific domain. I have my preference for Govrnanza and in the next part we'll implement that strategy and get into some code.
My feeling is that now perhaps we can have a more realistic conversation about microservices without the hype associated. Microservices are another pattern in our toolkit that can be applied under the right cirumstances.
Personally I think that Cloud Native apps, be they micro, medium or monolithic are the true winners in the last couple of years. Cloud native apps are flexible and scalable.
- API Series Part 1 - Let's Build Something
- API Series Part 2 - Documentation - Swagger
- API Series Part 2b - Add Non-Intrusive Markdown to Swagger UI
- API Series Part 3 - Adding VS2017 Docker Support
- API Series Part 4 - Secrets Management with Docker Secrets
- API Series Part 5 - Configuration with Docker Configs
- API Series Part 6 - ASP.NET Core 2.0 and Integration Testing
In this series we'll build a set of APIs with ASP.NET Core 2.0 in a cloud native, microservices architecture that can satisfy a long list of non-functional requirements.
So what does cloud native actually mean? It means that you don't know where your applications are going to run anymore. Your applications need to be able to work out how they are configured and integrate themselves into the wider system of services and start working. Why is that a desirable thing? Because it means that we can stand them up and down at will, without need for special system configurations. That means we can create copies of them for scaling out and we gain resiliency because when one copy of an application dies we just start up another one.