After having spent some time prototyping with Microsoft Azure Function, and Azure App Services, I’ve expanded the focus to include Azure Service Fabric. We’re migrating over to Service Fabric and I’ll explain why:

 

Context

To give some context, when I first came to Azure, I was looking for a PaaS solution for the API for the contextere back-end. Because Service Fabric was described as an Azure-focused container orchestration solution it did not initially make my list of “technologies to explore”.

Fast forward several months and I had an API deployed on Azure App Services. However, as I now needed to ingest IoT along with other telemetry data and propagate it through the system, it became apparent that the numerous database accesses required to keep up with the data would become a bottleneck and that the overall solution would benefit from being able to keep more state in memory to increase scalability. It was time to revisit Service Fabric.

 

What is attractive about Service Fabric?

If you go beyond the high level description you find at https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview, Service Fabric’s strength is its three programming models (stateless services, stateful services, and reliable actors) and matching APIs which simplify the construction of reliable, scalable, and partitioned services. It also helps you adhere to some of the 12 factor app concepts (https://12factor.net/).

Indeed, when you start building your microservice and leveraging the Service Fabric APIs, the reliability becomes a deployment property where you indicate how many replicas you want to have for each service. Scaling up and down can be achieved at runtime at the level of the service, and partitioning becomes a matter of specifying a partition key when accessing the service and specifying the number of partitions at deployment time.

Of course, Service Fabric is open and lets you deploy executables or containers that don’t use the Service Fabric API, but you won’t be able to achieve the same density than if you built your service in C# or Java leveraging the API.

 

Why are we building on Service Fabric?

A crucial aspect of the contextere platform is mission critical enterprise scalability. Service Fabric naturally supports that goal. However, we also found additional benefits that reinforces the sentiment that Service Fabric was the right solution to build upon:

  1. The actor programming model is a natural fit for our problem domain. It allows us to clearly separate the various responsibilities of our system from both a design and runtime point of view, and it helps us efficiently dispatch and process the ingested telemetry data
  2. The possibility of deploying any executable or docker container helps us to expand beyond C# or Java and leverage machine learning libraries from Python or other ecosystems
  3. The flexibility of the application model allows us to size our platform to the deployment needs of individual customers while also tailoring individual service packages on a per customer basis
  4. The application deployment model provides the flexibility for shared cluster or fully isolated deployment providing our customers with the choice of security and cost effectiveness

 

Some considerations for others:

Service Fabric provides some solid benefits, but there are some key considerations when developing within the environment:

  • Whereas solutions like Azure App Services or Azure Function partially or fully abstract away the infrastructure on which the application is going to run, a Service Fabric cluster requires you to directly manage the underlying infrastructure of VMs, networks, load balancers, etc. There are, or course, existing templates to mitigate this additional development but it does add time and overhead.
  • To benefit fully from Service Fabric, you have to use its programming model and APIs. While this may have its constraints for some developers, those are heavily mitigated by the fact that the Service Fabric runtime can be deployed on any cloud provider and even on premises with existing hardware.
  • Even though there is extensive documentation and some good development examples available, Service Fabric currently has a smaller user base compared to App Services and that somewhat impacts peer learning and sharing.

 

Overall, I’m certainly excited by the potential that Service Fabric provides to accelerate our platform development and exceed our customer’s deployment expectations as we grow and scale.

Comments are closed.