The idea of componentizing software was first popularized in the world of computing in 1960s. Modern day enterprise distributed systems are build based on this principle of encapsulating functionalities as software components which are consumed by applications to assemble business work flows. These software components which provide functionality to other applications are popularly termed as services. The composite applications that use services can be anything ranging from a mobile application, a web application, or a desktop application.

In a traditional world, applications are monolithic by nature. A monolithic application is composed of many components grouped into multiple tiers bundled together into a single deployable unit. Each tier here can be developed using a specific technology and will have the ability to scale independently. 

Although a monolithic architecture logically simplifies the application, it introduces many challenges as the number of applications in your enterprise increases. Following are few issues with the monolithic design:

• Scalability: The unit of scale is scoped to a tier. It is not possible to scale components bundled within an application tier without scaling the whole tier. This introduces massive resource wastage resulting in increase in operational expense.
• Reuse and maintenance: The components within an application tier cannot be consumed outside the tier unless exposed as contracts. This forces development teams to replicate code which becomes very difficult to maintain.
• Updates: As the whole application is one unit of deployment, updating a component will require updating the whole application which may cause downtime thereby affecting the availability of the application.
• Low deployment density: The compute, storage and network requirements of an application, as a bundled deployable unit may not match the infrastructure capabilities of the hosting machine. This may lead to wastage of shortage of resources.
• Decentralized management: Due to the redundancy of components across applications, supporting, monitoring, and troubleshooting becomes expensive overheads.
• Data store bottlenecks: If there are multiple components accessing the data store, it becomes the single point of failure. This forces the data store to be highly available.
• Cascading failure: The hardware dependency of this architecture to ensure availability doesn't work well with cloud hosting platforms where designing for failure is a core principle.

A solution to this problem is to migrate to a distributed system architecture. A distributed system is highly maintainable and far less complex than a monolithic application. There is a clear separation between the various parts of the application in a distributed system. This gives third party service providers an opportunity to plug their applications to the services that the distributed system provides.

A distributed system is generally realized through a Service-Oriented Architecture (SOA). The idea behind using SOA is that instead of using modules within an application, use services to provide functionality to the client application. An advantage of SOA architecture is that there can be multiple independent clients of an application. For instance, same set of services may be used by a mobile client and a web client of an e-commerce application. The SOA architecture also supports the independence of client and functionalities. If the contracts of a service do not change, the service may be modified to provide the functionality without altering the clients.

Due to lack of standards and implementation consistency on what functionalities should be provided by each service realized through SOA architecture, traditional architectures resulted in large monolithic services. Because of size of the services, the services became hard to scale. SOA also lacks simplicity as it is generally realized through web services. Traditionally, web services use SOAP and XML, which today have been replaced with REST and JSON. Since services in SOA can encapsulate several functionalities, each of the individual SOA service becomes deployment monoliths. SOA tends to reduce delivery agility and does not gel well with recent DevOps practices such as continuous integration and continuous deployment.

The Microservices architecture is the evolution of SOA. The Microservice architecture is a software architecture pattern where applications are composed of small, independent services which can be aggregated using communication channels to achieve and end-to-end business use case. The services are decoupled from one another in terms of the execution space in which they operate.

Each of these services will have the capability to be scaled, tested and maintained separately:

Microservices have all the features of SOA with additional service sizing constraints. Each Microservice has a single focus and it does just one thing and does it well. A distributed system composed of Microservices will have multiple Microservices that communicate with each other to provide a set of functionality for a specific part of the application.

Because the Microservices need to communicate with each other and with the clients, the communication mechanism needs to be quick and platform independent, for example, HTTP REST. A platform independent communication platform also ensures that Microservices and clients developed on different platform can communicate with each other for example a Java client communicating with .NET service.

Microservices are more agile than SOA. This helps development teams change part of systems quickly without affecting the rest of the system. Overall, added agility reduces the time to market of a product and allows the product to be adaptable to changing market conditions.

Microservices can also adapt to changing organizational systems. For instance, a change in account management product of a company would only alter the accounts service of the system without altering the other services such as the HR service or facility management service.

There are complex problems that need to be solved to host Microservices at scale. Such problems include preserving state, rolling upgrades, inter-service communication, and optimal use of machine resources. Such problems lead to slow adoption of Microservices architecture.

Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage, scalable and reliable Microservices thereby addressing significant challenges in developing and managing Microservices. It does so by treating a collection of virtual machines as a worker pool on which Microservices can be deployed. Since, all that Service Fabric needs is a runtime, it can be executed on heterogeneous platforms on any data center.

Service Fabric is a reliable, tried and tested platform to build Microservices. It is already used to host some of the largest Microsoft services such as SQL Azure, Bing, Events hub, Cortana services, and so on.

Following are few advantages of a Service Fabric which makes it the ideal platform to build a Microservice based Application Platform:

• Highly scalable: Every service can be scaled without affecting other services. Service Fabric will support scaling based on VM scale sets which means that these services will have the ability to be auto-scale based on CPU consumption, memory usage, and so on.
• Updates: Services can be updated separately and different versions of a service can be co-deployed to support backward compatibility. Service Fabric also supports automatic rollback during updates to ensure consistency and stability of an application deployment.
• State redundancy: For stateful Microservices, the state can be stored alongside compute of a service. If there are multiple instances of a service running, the state will be replicated for every instance. Service Fabric takes care of replicating the state changes throughout the stores.
• Centralized management: The service can be centrally managed, monitored, and diagnosed outside application boundaries.
• High density deployment: Service Fabric supports high density deployment on a virtual machine cluster while ensuring even utilization of resources and even distribution of work load.
• Automatic fault tolerance: The cluster manager of Service Fabric ensures failover and resource balancing in case of a hardware failure. This ensures that your services are deigned for failure, a compulsory requirement of cloud ready applications.
• Heterogeneous hosting platforms: Service Fabric supports hosting your Microservices across public and private cloud environments. The Service Fabric cluster manager is capable of managing service deployments with instances spanning multiple data centers at a time. Apart from Windows operating system, Service Fabric also supports Linux as a host operating system for your Microservices.
• Technology agnostic: Services can be written in any programming language and deployed as executable or hosted within containers. Service Fabric also supports a native Java SDK for Java developers.