I've been working on a personal mobile project since the past year or so. This requires a highly scalable and real time back-end platform. I spoke to some industry colleagues on the high level architecture before I got started in early 2019 and some said "Containers" and some said "Serverless". Granted, coming from the Windows world, I've not worked with Container technologies before [btw, Windows Server Core 2016 and Nano Server both have excellent Container Support now].
I've been working on large scale global distributed Micro-Service systems since the past 5 years or so with the all the following benefits on the Service Fabric Platform.
Of course, Service Fabric supports "Containers" too but, I never got around to using them and just used Service Fabric the way it was originally designed for. Orchestrating "Processes" on a massive scale with the goodness of Reliable Programming Services and native support for Stateful Services and end-to-end DevOps using Azure DevOps Server
Sticking to "Process" orchestration allowed me to architect systems that are much simpler, more cost effective, easily maintainable without sacrificing any benefits of "Containerization" and most importantly gave the best bang for the buck for my employer.
Containers gives you Process Isolation, Consistent Environment, Run Anywhere. If we apply the same principles to Service Fabric orchestrated environment [Process based], it ticks all the boxes.
We can rely on O/S provided default process isolation + .Net based App Domains to achieve process isolation. [Granted, .Net core does not have App domains but, I am still ok with O/S provided process isolation]
Service Fabric packages your Code + Config + Data [for Stateful services] and deploys to "n" number of replicas across your cluster.
It runs any where from your laptop to the most massive data centers.
We can impose resource governance limits on each individual process. [ex: 50% of memory and 25% CPU for a specific process, placement constraints limiting certain processes to certain "node types" etc]
"Processes" provide the best activation times and are the leanest compared to VM's and Containers [On both bare metal and VM's]
Saves time and money not having to deal with container technology and Orchestration.
I would say "Containers" makes sense in the following scenarios:
If you are developing global multi tenant applications where each tenant should be running on a different isolated environment, config, runtime and package dependencies, it makes absolute sense to go for "Containers". [ex: Building your own Cloud like Aws/Azure/GCP]. Update: Server 2019 and Nano Server support Hyper-V containers which work great with "Hostile Multi-Tenant" scenarios.
Lift and Shift: The app currently works, need to make it portable without re-writing it, containers makes sense.
For Enterprise LOB microservice applications, Global Scale Distributed Systems, AI/ML workloads, IoT Edge computing scenarios and Web Hosting, consider a Process Orchestrator like Service Fabric before jumping into Containers.
Please let me know your thoughts in the "comments" below..
PS: As expected, I did not go with Containers for my mobile project. That's a topic for another article :)
Top comments (2)
Why are you still deploying .NET Framework web apps?
Please elaborate your question..
If you mean, why are you deploying classic ".Net frameworks projects"? We are not. We are actually using Blazor [server side on .Net Core] for our web apps and use service fabric to host using httpsys. Does that answer your question?