I’m Excited About Service Fabric, Now What?
In my last blog, “Building Cloud-Scale Enterprise Apps: Our Take On Microsoft Service Fabric,” I looked at some of the common pain points Microsoft Service Fabric can help developers with. This week, we’ll take a closer look at some possible use cases.
A possible use case is a social network where users can send messages to individuals or groups, and post things to their “wall.” This isn’t a difficult model on a single server with a small number of users. However, as the number of users and traffic grows, this quickly becomes an exponentially complex problem that will rapidly reach the capacity of a single-server solution.
To compensate, you may go through a process that looks something like this:
1. Throw in more servers and more timer jobs, but it is still slow.
2. Re-architect using queues and specialized worker threads, so now it’s faster. However,
your bottleneck is the database.
3. Throw together a SQL cluster for reliability and a cache like Redis for fast reads, but then you have a data consistency problem.
But if you wrote it with the Virtual Actor model, all of these state management problems and communication paths are abstracted away, allowing objects to pass messages to each other as if they were a single threaded monolith, and allowing state to be kept in the object instead of being saved out to a database table–only to be fetched again milliseconds later.
I can see that almost any problem that can be modeled with objects can use the Virtual Actor model. Even a product like eBriefing’s back end can be built as a network of objects, such as Libraries, Books, Pages, Notes, Annotations, Users, and Groups. Data relationships like containment can be modeled by object relationships instead of SQL table foreign key relationships. The state of each object can be held in the object itself instead of it being stored and fetched to and from a corresponding SQL table. Do you want an object? Then fetch its reference by its ID and start accessing its properties and methods.
Blurring the line between cloud applications and enterprise applications.
If this platform runs both in an enterprise data center and in the Azure (or third-party cloud), then this basically blurs the lines between what is a cloud-hosted app and what is an internal enterprise app. Therefore, the migration from privately hosted apps to the cloud hosted, or even a hybrid-hosting model, becomes blurred even further.
As for enterprise use cases for this technology, I see the following:
1. Enterprise application modernization. If your customer wants to benefit from the cloud-scale reliability and scalability features, then legacy enterprise apps can be packaged up or rewritten to use this new platform. This is exactly what Microsoft has done with many of their apps that are now Azure-hosted SaaS solutions, i.e., SharePoint to Office 365.
2. Middle layer applications that concentrate on moving data throughout the enterprise: (A) Service-bus-style applications that move, transform, publish, and store data between applications.(B) Data Synergy APIs that allow access to disparate legacy data stores (database) to the consuming application in a unified and simplistic manner. (C) Workflows.
3. Business-to-business applications that exchange data between enterprises. These are high availability applications that cannot go down without impact to profit, or in the case of law enforcement agencies, without impacting public safety.
4. Mobile back-end services. The biggest problem with these has been building something that scales from prototype to massive scale with high reliability. But now, this is easy. Sure, there are public mobile services galore, but what if you need a custom mobile service? And what if it must run inside of an enterprise? Service Fabric has you covered.
Service Fabric will be available on premise via Windows Server 2016 and Azure Stack.