Scalability


Q: Is AppFabric enterprise-ready? I have more than 100 services hosted in a single server. Will it be performing good enough?
A: Performance is a key measure for server products such as AppFabric. Ensuring that AppFabric is able to cater for large number of applications and services installed on a single server is a key goal for AppFabric.

Q: I am confused about the scale-out feature. What exactly does AppFabric do to enable scalability of services?

A: AppFabric is designed to compose with the existing load balancing solutions to scale out the long running workflows. It includes a specialized persistence provider and a database that is shared by all nodes in the cluster to enable moving the workflow state between servers across the cluster. It also includes specialized retry logic that handles the race conditions when two messages for the same workflow arrive to different nodes.

Q: How would I use the .NET routing service in AppFabric?

A: AppFabric simply supports hosting a WCF service that uses the .NET routing service (system.servicemodel.routing) as a generic WCF service. Routing doesn’t depend on AppFabric for anything, and AppFabric provides no special tooling or support for it.


Q: How does the scale-out solutions offered by Windows Azure and the Microsoft .NET Service Bus Overlay relate to the scale-out features of AppFabric? How do I choose one or another?
A: The Azure Platform is an internet-scale cloud computing and services platform hosted in Microsoft geo-distributed data centers, and is a core part of Microsoft’s overall Software+Services initiative (which includes applications delivered as services and developer level services which empower developers to both build new Internet scale applications as well as extend existing applications in new ways). Because new or enhanced applications for both Strata and AppFabric are built using the Visual Studio development environment and the .NET Framework, this provides customers with the choice of building applications either on premises, in the cloud, or hybrid solutions offering the best of both worlds. Both Strata and AppFabric also are deeply standards-based and interoperable, as they both leverage support for a broad range of internet protocols, including HTTP, REST, SOAP, and POX.
With the first version of AppFabric, you’ll be able to easily scale your services out from one machine to clusters of up to 8 nodes. In the future, as the Overlay technology is integrated into AppFabric, you’ll be able to scale out a lot farther. In the meantime, by building upon consistent programming models in .NET and using the breadth of interoperability found in the platform, this will enable you great flexibility and the power of choice in the future. AppFabric represents an evolutionary step in our vision towards providing frameworks, runtimes and tools that make it easier to build scalable applications by default. With the first version of AppFabric, you’ll be able to easily scale your services out from one machine to clusters of up to 8 nodes. In the future, as the Overlay technology is integrated into AppFabric, you’ll be able to scale out a lot farther. In the meantime, the more you apply the principles of scalability in writing applications today, the easier it will be for them to run on both the first version of AppFabric and on subsequent releases.


Q: There is a feature called “retry” in 3.0/3.5 persistence provider. How does it relate to persistence provider scale-out?
A: You must be referring to SqlWorkflowPersistenceService. That feature exists to enable retries to recover from network errors, SQL failover and other recoverable errors like occasional deadlocks. This is not related to scale-out in any way.

Q: What will be the approach to load balanced clustering of servers under AppFabric? Will workflow execution occur on multiple servers? I expect a workflow instance domain is limited to a single server but will new instances of the same workflow type (pattern) instantiate on other servers to scale?

A: You are right that a workflow instance will execute on a single server and that new instance will instantiate on other servers in the farm. Execution is not limited to a single server in the typical scenario - usually workflows do not have affinity to any particular server or host. If the WF has been persisted and another message arrives for it, then the WF will be re-loaded to the server where the message arrived. AppFabric will allow you to use any load-balancing mechanism and AppFabric will start the new instances. If there are messages for an already created instance the persistence provider in AppFabric will make sure that the correct instance is loaded from the DB. If the WF was running and the server crashes for some reason, then the instance restart service will be able to bring the instance back up on another machine in the farm. The key point is that the AppFabric Monitoring and Persistence data store, in a typical and standard configuration, is the single point of failure. To prevent this from taking down your system if unavailable, you may want to consider clustering these databases.