Microsoft just changed everything about enterprise app development with their announcement that Service Fabric will be released as part of Windows Server 2016.
For years, our enterprise customers have requested the features of commercial Software as a Service (SaaS) applications in their enterprise. They want fault tolerance, high availability, resilience, elasticity, and near-zero downtime. In order for this to happen, we needed a major cloud vendor to build a cloud apps runtime, a platform or Platform as a Service (PaaS) that can be installed into an enterprise. The cloud vendor would then have to prove that this technology is worthy by building its own SaaS offerings on top of this platform.
This is exactly what Microsoft has done with Service Fabric.
A Bit of Background
Microsoft has stated that they have been building most of their consumer SaaS offerings on the platform that is now called Service Fabric for years (the last five years to be exact). This means apps like Office 365, Intune, Bing, and Cortana are built on a cloud platform that can also be used to build enterprise apps.
Sure, I can build a big distributed system the old fashioned way with queues, stateless workers, caches, and a SQL farm on Virtual Machines, but this is a major pain and it’s unlikely that I can make it 1/100th as resilient as the Microsoft Azure team has. Plus, as a developer, I want to spend my time solving business problems not reinventing the wheel.
Pain Point 1: App Upgrades
As a developer of distributed enterprise apps, app upgrades are a pain point, especially when down time cannot be tolerated. Service Fabric solves this deployment and upgrade problem with a new model that upgrades in place across the entire cluster seamlessly. This is awesome! It means that a true cloud scale, consumer quality upgrade experience is possible in the enterprise. Service Fabric allows developers to work on a system that receives updates daily for new features AND bug fixes. This capability aligns with the government’s desire for agile development and delivery of enterprise applications.
Pain Point 2: Inefficiency
Another benefit of an app run time that spans an entire cluster of services is the increased efficiency with computer resources. We often have entire farms of servers, each of which contain production, staging, UAT, and Development environments dedicated to a single application. This results in a lot of servers doing very little most of the time. With Service Fabric, all the apps can be installed on an app run time that spans the cluster of servers and the run time decides what services runs on which server. This results in many apps sharing the same servers, and in turn increasing efficiency.
Key Differentiators
What differentiates Service Fabric from Amazon or Google App Engine (other than the fact that these are “cloud only” solutions)? Microsoft Service Fabric solves the problem of “stateful services.” Stateless services are part of the problem with distributed systems. In a stateless worker services environment, you are always trying to save your state in case something bad happens, and something bad always happens. This leads to a series of events that look something like this:
1. Something bad happens.
2. The stateless service has to go and find its previous state, “What was I doing again?”
3. The stateless service has to do another unit of work and save its state again.
Since state management is one of the biggest problems to solve with cloud-scale apps, the stateful service solves this problem for us. If you can keep your state within your service, you can avoid this slow, complex, and unnecessary process. Imagine if every customer’s database is running as a SQL server app within a container that could go down and spin back up on a secondary instance almost instantly. Now, the state is carried in my service as a miniature, self-contained application in its own resilient container. That is huge.
Thinking in Objects is Back
Remember “Codename Orleans” from Microsoft Research? To ensure this platform has an entirely new, awesome programming model, Microsoft released the Virtual Actor model of Codename Orleans as part of Microsoft Service Fabric but renamed it the Reliable Actor API. Yes, this is the same Codename Orleans that the Halo 4 team used to build the game’s back end in record time.
The coolest thing about Orleans…I mean the Reliable Actor API…is that it has an object-oriented cloud runtime where you can write in classes and objects. These are objects that scale to the moon and always feel like they are in memory. You don’t have to store your object’s state in case it goes away because its state is stored for you.
Object orientation is no longer just for design time modeling of distributed systems, but now with the Actor model, we can model and implement the business problem in domain objects that customers and developers can understand. This modeling simplifies complex problems in cloud scale applications.
It’s safe to say that we’re pretty excited about the possibilities with Service Fabric and the common headaches that this product can help us avoid.
The More You Know…
Take a closer look at what all of this means and read-up on some possible use cases in Part 2: Possible Use Cases for Microsoft Service Fabric
About the Author
Matt started his career with mainframe development, then moved quickly to develop desktop development, where he developed commercial box software until getting back into government IT consulting with MetroStar Systems. He now builds mobile apps and back-end systems as director of the mobile department. He has an eye for simplifying complexity and enjoys algorithms and the art of making systems faster, lighter, and cheaper.
