Microservices and Docker containers: Architecture, Patterns and Development guidance

As part of the series of posts announced at this initial blog post (.NET Application Architecture Guidance) that explores each of the architecture areas currently covered by our team, this current blog post focuses on “Microservices and Docker containers: Architecture, Patterns and Development guidance”.

Just as a reminder, the four introductory blog posts of this series will be the following:

The microservices architecture is emerging as an important approach for distributed mission-critical applications. In a microservice-based architecture, the application is built on a collection of services that can be developed, tested, deployed, and versioned independently. In addition, enterprises are increasingly realizing cost savings, solving deployment problems, and improving DevOps and production operations by using containers (Docker engine based as de facto standard).

Microsoft has been releasing container innovations for Windows and Linux by creating products like Azure Container Service and Azure Service Fabric, and by partnering with industry leaders like Docker, Mesosphere, and Kubernetes. These products deliver container solutions that help companies build and deploy applications at cloud speed and scale, whatever their choice of platform or tools…

https://blogs.msdn.microsoft.com/dotnet/2017/08/02/microservices-and-docker-containers-architecture-patterns-and-development-guidance/

Design Pattern – Adapter

The purpose of the adapter pattern is actually quite simple. It converts one interface to another one, thus making it possible for classes to work together where the interfaces are different.

Real World Example

Because it’s such a common pattern I had to think for a while before coming up with an example.

Say, our application has to export some data in various formats – excel, pdf etc. It would be quite likely that third party libraries for each of the formats have different interfaces. We could of course write a switch statement, but the better solution would be to wrap each of the third party libraries into a class that implements a common interface. Then all we have to do is resolve the wrapper based on the format. Since the wrapper would implement a common interface the task of exporting data become relatively simple

Blog at WordPress.com.

Up ↑