On the Shoulders of Giants: How do Microsoft's Azure Service Fabric and Pivotal's CloudFoundry compare?

How do Azure Service Fabric (ASF) and CloudFoundry (CF) compare? This is by no means neither an authoritative nor a complete comparison of the features, just a couple of quick observations. I base my statements on the resources mentioned at the end of my blog post.

Well, first of all, and obviously enough, ASF runs on Azure, nowhere else. CF runs on almost all Cloud providers out there, including Azure. Sounds like a great plus for CF when it comes to freedom of Cloud provider choice. The topic is vendor lock-in, and I have great respect for Microsoft's decision to provide CF as an alternative in Azure. I was not expecting this move from Microsoft, as their "normal" reaction in the past was to create something different to lock their customers in. It seems that they have changed their strategy completely. Now they simply compete with better services, and they seem to be quite sure about themselves.

On the CF side: We should not ignore that CF is not equal CF. The portal experience and the provided services can be quite different from one Cloud provider to the other. What remains is a application deployment model and core features that are standardized on CF. Moreover, authentication and authorization is not standardized on CF, and this creates a Cloud lock-in nevertheless. The only abstraction layer known to me for these aspects of an application is the Spring econiche with Spring Boot, Spring Security, and Spring Cloud. CF and Spring are a strong team, and the power behind its development is great.

ASF has some very strong selling points, too, though. It is used as the platform for many Microsoft internal platforms themselves, hence it is battle tested. Its "Reliable Actors" offering provides a very compelling distributed computing model. The "Reliable Actors" model does not provide the full Erlang/Akka Actor System model, but it provides the same abstraction layers. I believe that it most closely compares to AWS BeansTalk or AWS Lambda.

One more strong point for ASF is that developers can have their own local ASF instance by simply downloading the Service Fabric Developer SDK. You can install a local CF instance but it takes more than just running a setup-sdk.exe.

On the flip side of the coin: ASF creates technology and vendor lock-in. It currently supports only C#, although Java support is in the making. But Java will always be second-class citizen on ASF, new features will only be introduced after its introduction for .Net/C#.

Conclusions: CF is the "de facto standard" for PaaS. Hence a Public Cloud strategy for Enterprises could be to standardize on CloudFoundry in order to simplify the management of Public, Private and Internal Clouds. Other Public Cloud platforms should not be ruled out, but product development teams would then need to have very good arguments to move to a non-standard Cloud PaaS offering.

Resources: