Azure Service Fabric is Microsoft’s Platform-as-a-Service (PaaS) and is used to build and deploy microservices-based cloud applications. Fabric, in this context, is a synonym for framework. Azure CTO Mark Russinovich describes Service Fabric as a layer that understands “the binding between microservices and the underlying infrastructure that they run on.” Apps created in the Service Fabric environment are composed of separate microservices that communicate with each other through service APIs (application-programming interfaces)
The modular nature of microservices makes it possible to scale individual components of an application separately according to requirements, frees developers from the need to deal with infrastructure problems and simplifies the process of rolling out changes. The microservices approach contrasts with the traditional monolithic architecture, in which elements of a program are interwoven and interdependent, requiring that the whole program be addressed if any element is to be changed. Basically it is an architecture embracing on the microservice architecture where developers disrupt the traditional monolithic applications into a set of discrete and fine-grained services.
Service Fabric enables microservices in a quick and efficient way. Service fabric reliable services are powerful concepts, allowing to both lift and shift your applications, enables scaling, disaster recovery and resilience. Even though it’s slightly behind AWS in cloud market share, Microsoft Azure is clearly the preferred option for many companies, especially for retailers.
Some of the reasons for this:
To understand the essence of Service Fabric, first we must talk about the evolution from monolithic apps to microservices-based apps.
Before microservices were a thing, most applications were built in a “monolithic” way. In a monolithic architecture, the app’s functionalities are tightly coupled into one service. This approach can (and usually does) mean long downtimes when deploying new features, which results in fewer opportunities to make updates.
Also, there are downsides when it comes to scaling. Because every component scales at the same rate regardless of use, scaling monolithic apps to meet demand is slow and expensive. Availability and reliability are achieved by hardware redundancy, which means additional cost and complexity.
In the cloud era, this is a rather unproductive and costly way of doing business. Today, time-to-market, availability, and the ability to scale on demand have become more critical than ever. This has resulted in a shift towards building microservices-based applications.
The name “microservices” conveys the fact that the size of the service matters; microservices are supposed to be small. In this approach, each application is split into a set of fine-grained, loosely coupled services. Examples of such services can be protocol gateways, user profiles, shopping carts, inventory processing, and so on.
The benefit of decomposing an application into different smaller services is that it makes the application easier to understand, develop and test. Which is great, because then services can be updated and scaled independently from each other, improving agility and productivity.
Building cloud applications via microservices through us affordsseveral advantages:
1
By isolating the functionality and via clean APIs, services have well-defined inputs and outputs, which make unit testing, load testing, andintegration testing easier.
2
Individual teams that own services can indepen-dently build, deploy, test, and manage them based on the team’s expertise or what is most appropriate for the problem to be solved. This makes the development process more agile and lends itself to assigning each micro-services to small nimble teams.
SF provides rolling upgrades, granular versioning, packaging, and deployment to achieve faster delivery cycles, and maintain up-time during upgrades. Build and deployment automation along with fault injection allows for continuous integration and deployment.
3
A monolithic application can be scaled only by deploying the entire application logic on new nodes(VMs/containers), in SF only individual microservices that need to scale can be added to new nodes, without impacting other services. This approach allows an application to scale as the number of users, devices and content grows, by scaling the cluster on demand. Incremental deployment is done in a controlled way.
4
SF manages multiple applications running on shared nodes, scaling themselves continuously, because the workloads change dynamically all the time. The components of SF that this paper fleshes out help keep nodes’load balanced, route messages efficiently, detect failures quickly and without confusion, and react to failures quickly and transparently.
5
SF provides useful abstractions for stateful services, namely Reliable Collections, a data-structure that is distributed, fault-tolerant, and scalable.
Service Fabric is a terrific platform for orchestrating your Microservices. It provides many features like Service Discovery, Fault Tolerance, Reverse Proxy etc., out of the box, making it extremely easy to manage your Microservices. Azure’s core infrastructure is based on Service Fabric, and the platform was running in development at Microsoft for five years prior to its release. Service Fabric powers many
Microsoft products including Azure SQL Database, Azure DocumentDB, Azure IoT, Cortana, Power BI, Microsoft Intune, Event Hubs and Skype for Business
Service Fabric for Windows Server, Linux and Java APIs preview versions are available for deployments on premises or in other cloud environments, including Amazon Web Services (AWS), OpenStack and VMware.
Detailed information can be found here