Microsoft Azure Service fabric containers and microservices

Microsoft Azure Service fabric makes use of many new service application methods to allow new ways to develop code in a better, more efficient and more rounded way. Two examples of these are containers and microservices.

Microservices break down what are traditionally monolithic applications (tightly coupled between tiers liked in a few executables and DLLs.) This was to allow individual scaling between components so you did not need to wait for others to finish their testing allowing a more agile method of development. This has the effect of simpler business functionality that can be managed independently and so is more adaptable to different technologies. However, it should be noted microservices are more complicated due to the more working parts and that there is more “noise” inside the application and more communication ahs to occur to make sure the supplication is working correctly.

Service fabric is fully supporting of microservices, and in fact has built-in programming APIs that make it easier to build microservices in service fabric. When the microservices are deployed onto a cluster they will normally come up as applications in the service fabric explorer, where they will displayer their health state and status allowing easy management of individual services.

Containers work by especially wrapping the application (including its dependencies, libraries and configuration) in a singular, isolated box which is self sufficient in it’s running (i.e. it contains everything needed to run the application inside it.) Containers run directly on top of the kernel in an isolated view to the rest of the system, having no knowledge of anything outside itself where it is basically partioning it from the rest of the world.

Containers are useful on top of being able to run on any OS as they are small (due to only having the minimum required) and fast again due to the small size.

[A over arching view of the layers of a container]

Service fabric currently supports dockers on Linux and Windows as an application model (where the application represents an application host in which multiple service replicas are places,) a guest executable scenario (where you don’t use service fabric models but instead package an existing application) and running service fabric inside a container. Guest executable scenario is an interesting use of containers in service fabric as it allows a normal application to be managed by a service fabric cluster allowing, high availability, health monitoring, lifecycle management and density (multiple applications on one cluster) while still maintain the original applications technology without a lot of complex hacking work.

So combined, these two technologies allow service fabric to be able to support a variety of systems, that while may be more complex to design, allow for high integration and scalability of the system as well as the ability to export the application to other systems with relative ease if you opt for the use of containers.