Party until you drop with Azure Service Fabric!

This post was authored by Mani Ramaswamy, a Program Manager on the Azure Service Fabric team.

What did we build?

Azure Service Fabric makes developing and managing cloud applications simpler and more efficient while offering high scalability and reliability. While the local cluster provided with the SDK provides a high-fidelity substitute for the cloud during development (it is a real cluster, after all), people naturally want to try deploying and managing applications in a true multi-machine cluster running in the cloud. At the same time, we understand that our minimum cluster size of 5 VMs can be a bit costly for those who simply want to kick the tires.

During one of our brainstorming meetings, we were discussing ways to let developers try Service Fabric in Azure with no strings attached. What we wanted was a shared, public space where users could easily get a taste for the Service Fabric experience in Azure without spending a dime or even providing a subscription. We wanted them to be able to deploy an application, see what happens when they "take down" a VM, and perform a zero downtime upgrade. And so, Party Clusters were born.   

Why did we build it this way?

Originally we thought of one giant 300-node cluster that everyone joins. Sounds like fun in theory, but it has some big problems, like how do I find the application I deployed among the thousands of others? How do I get a port to try out my web service? And who’s the guy that wrote the script that just deletes everyone’s applications all the time? Maybe someday we’ll try it as a social experiment, but for the sake of having something more usable, we decided to host a bunch of smaller parties with a limited number of users per cluster, and let you pick which one you want to join.

While our intention is to enable you to try Service Fabric on Azure (and experience feelings of unbridled joy when you see a zero downtime upgrade, or not having to write code to protect against hardware failures), the Party Clusters are not meant for any production workloads - remember, they’re unsecured and shared with other users, and everyone can see everyone else’s applications (obligatory Terms of Use link). We also clean up each cluster after a few hours, meaning we replace each cluster entirely with a brand new one, and everything on it goes away, so there’s that too.

How did we build it?

Using Service Fabric, of course. Broadly, it’s a single-page ASP.NET web app front end which links up to a cluster management service that maintains the list of clusters and how many users and services are running in each cluster, along with the time remaining before the wave hits and the cluster gets reset. When you request to join a cluster, we send you an email (using SendGrid) providing the end point of the cluster and a unique application port. That port is for you to use in your applications – say if you want to deploy an application with a web front-end yourself, you get your own port to use. Everyone gets their own port on each cluster.

We had a fun time building this out on Service Fabric, and, like any service, we now own it and run it. Stay tuned for an upcoming blog series on our experiences building and running it, where we’ll dive a little deeper into the technical stuff.

For now, the Party Cluster service is open source and available on GitHub as a sample application.  

Some common questions

A few questions tend to come up when we talk about the party clusters, so let’s address them here.

Can I have my own dedicated party cluster?

No – what kind of party would that be? 🙂

The intent of the party clusters is to let you try the Service Fabric experience in Azure when you’re first experimenting with the platform. Once you need the benefits of a private cluster, you should create one within your own subscription.

Can you make the time-to-live longer?

We continue to tweak this configuration – indeed, we recently increased it from 2 to 5 hours. Naturally, we are looking for a balance between maximizing ease of use for legitimate customers and limiting the attraction to malicious users seeking to perform destructive actions (like deleting everyone’s application) and those who might just be seeking free compute.

Why can’t we have smaller private clusters – say 2 or 3 nodes?

The answer to this question is worthy of its own blog post. The short answer is that a cluster which is maintaining state requires a minimum number of machines in order to ensure high availability in the presence of failures. And even if your applications are completely stateless, our system services are not and therefore requiring this minimum configuration. We are investigating enabling 3-node clusters for dev/test scenarios where you are willing to trade off some availability in order to lower costs.

Now what?

Try Service Fabric, download the SDK, play with the samples, develop your own applications, try deploying to Azure with the Party Cluster, have fun, and see what Service Fabric has to offer! And give us feedback on any of these – we’d love to hear from you!

Comments (1)
  1. Khaled Hikmat says:

    Tried twice to join a cluster but did not get any email. It has been several hours!!

Comments are closed.

Skip to main content