I understand that both Azure Service Fabric and Azure Container Services can be used to host microservices through containers.
In what scenarios is it practical & cost effective to use one over the other? What are some strong use cases for Azure Service Fabric and Azure Container Services models of hosting
I read this comparison but did not find it comprehensive
Update: A comparison table like one in this diagram would help keep the points "sticky" & memorable while deciding which option to use
Acronyms used in the table - AF - Azure Functions, ASF - Azure Service Fabric, ASE - App Service Environment, ACS - Azure Container Service, VMSS - Virtual Machine Scale Set
The “rank” should not be misconstrued as good or bad
Beside the link you pasted for "Choosing between Azure Container Service, Azure Service Fabric and Azure Functions" - Following is what I have found out.
Azure Service Fabric (ASF) is more of a PaaS offering while Azure Container Service (ACS) is more like an IaaS offering.
ASF gives you its own specific programming model, which if you follow then you will be able to take advantage of ASF features. That is why there is an ASF SDK for C#/Java you need to use. However ASF additionally allows guest executables and orchestrating Docker containers (not sure how much will they be leveraged compared to ACS or will they be at par).
At the moment ASF is Windows only (ASF on Linux preview now available # Feb 2017) (it smells vendor tie-in)
ASF offers you Actor model which is good for IoT solution (maybe quicker to implement than to DIY on ACS)
ACS in this sense is more open; it provides only container based model and heavily relies and support docker ecosystem. And once its a container its pretty much technology agnostic.
This could also be the reason for Microsoft's push for Windows Nano which is a basis for the windows based (server level) containers (my opinion). So with ACS you can either have Windows or Linux containers or both.
ACS also allows you to use the open source, industry famous container orchestrators including Docker Swarm, DC/OS-Mesos.
While ASF provides sort of its own orchestration. In other words ASF provides more integrated, easier to use feature rich model but ACS gives you much more openness and flexibility.
MS guys in some conference also mentioned that it could be considered that ASF is more of a Microsoft oriented shop while ACS is more oriented towards open source technologies.
[Feb 2019 Update]
It's a difficult comparison as Azure Service Fabric also exposes an application framework. It's pretty opinionated about the way applications should be built, which doesn't necessarily fit well with notions of 12-factor, cloud-native container apps.
This is an ever-moving feast, but there are a growing number of container runtimes in Azure:
Azure Kubernetes Service is the container orchestrator that replaced
ACS. It seems to be moving very much in a PaaS direction.
Azure Container Instances are useful for small jobs and burst scale
Azure Batch is optimised for large, repetitive compute jobs
Azure Service Fabric is an IaaS offering geared more around lifting and shifting Windows applications to the cloud
Azure Service Fabric Mesh is the new kid on the block - a PaaS service for Service Fabric apps.
All in all, if you're starting with containers then I would give Service Fabric a miss and head for Kubernetes. You can run containers in Service Fabric, but you can be made to feel like a second-class citizen. IMHO, OFC.
Gross over simplification. If your a Linux guy ACS will probably match what you want better. If you are a Windows dev writing windows code ASF will probably serve you better.
Related
We have a bunch of Windows Services. We need to be able to continue to deploy our code as Windows service on premise, but would like to deploy to Azure where appropriate. The goal is to manage less infrastructure. I'm not keen on deploying dozens of bits an pieces as Azure Functions, but not entirely opposed to it either. Azure Batch / Webjobs are also another option. However, the long term goal is to move all of our services over to an orchestration server like Service Fabric so that all the services can be deployed and orchestrated from the one place. This is mainly a deployment consideration.
We will break the existing C# code in to .NET Core class libraries and reference them from either Service Fabric hosted in Azure, on-premise Service Fabric, or on-premise Windows Service. Is Service Fabric an appropriate choice? Or, is there a strong reason to run background jobs as Azure Batch / Functions / Webjobs?
This is Microsoft's diagram from here:
The answer to the question is that we don't really need full fledged orchestration right now, but it will become more important moving in to future. I have to balance being able to deploy all our code in one hit with the ease of ad hoc deployment that Azure Functions offer.
(Stateful) Services can be an excellent way to run background jobs. They offer the RunAsync entry point, in which you can run your job, check (and store) progress. SF really shines when multiple services collaborate on tasks, offering SF Remoting as a communication channel, with built-in retry support.
You can choose to containerize your software, which would free you from platform lock-in, but prevent you from using some platform features.
By automating delivery of services (CI/CD), you can deploy to any platform you choose. This is not something that is specific to SF.
I am looking at possibly running some of our business on Azure.
I am trying to pick the services that would work best for my company, but I am getting mixed signals.
Because I am starting a new system, I want to pick the offerings that are not "legacy" (aka "current"). But there seems to be no way straight forward way to know that.
For example, this page of the Microsoft Documentation says
Cloud Services is similar to Service Fabric in degree of control versus ease of use, but it’s now a legacy service and Service Fabric is recommended for new development.
This page clearly states that Cloud Services is "legacy". However, you would never know this by going to the Cloud Services overview page. It has great marketing material that sells Cloud Services as a great option. But if I picked it, then I would be starting out on a platform that is in a legacy status.
Now I know that about Cloud Services vs Service Fabric. But there are tons offerings on Azure. I am trying to research them one by one to find out which ones are the most recent incarnation, but I feel like I am wasting my time.
Another example is storage. Lucky for me an Azure MVP answered my question on this one. Apparently, there is "older storage account" based disks and "managed" disks. Turns out managed disks are the new, easy way to do things. The storage account is harder. Still available, but not really what a new user should be picking. But again, this is very hard to find out unless someone who has been working with this stuff for a long time tells you.
I was about to start in on App Services and Web Apps, but I thought I would ask first to see if I am doing research that is already done and posted out there.
Is there somewhere that shows the current list of Azure services that you should look at if you are starting a new project?
I asked the similar question almost a year ago, and I even spoke with Azure Support Team after that. At that time, Microsoft did not officially state Cloud Service is legacy.
Does Azure App Service/Web App replace Azure Cloud Service?
We have been hosting our enterprise applications in Cloud Service since 2013, and a couple of them are in App Service. Here is my thought -
4 years ago we only have Cloud Service - Web Role and Worker Role,and App Service (formally named as Web App) is not fully ready for enterprise applications yet. Since App Service came up, Microsoft heavily promote App Service compare to Cloud Service. In addition, what I notice is Cloud Service did not get new features like App Service.
Service Fabric is quite new, and it doesn't have all the belts and whistles like App Service, so we might have to wait a bit for enterprise applications.
Only advantage of Cloud Service is you can remote desktop to a role instance, after the application is deployed.
If I host a new application in Azure today, I'll definitely use App Service.
Microsoft has published a list of Azure reference architectures. It was last updated in November 2016. You can browse it here, and there is some guidance given. But for example, you mentioned using Service Fabric (which is a great way to go for a robust app that really needs to scale), but Service Fabric isn't mentioned in the aforementioned resource.
I spend a lot of time running down Azure resources in relation to web applications (not to be confused with App Service Web Apps), and I have not found a definitive source of the type of info you're looking for personally.
I am starting my journey of IoT development with MS Azure. I would like some insight on the Azure cloud. I am a total newbie on cloud development. Can someone tell me some good books/links on Azure that will help me understand how I can use Azure for IoT and start development on the same.?
Thanks a lot for your inputs.
This totally depends on the architecture of your application. You can use SAAS components for rapid prototyping, parts or all of your application architecture. This will give you a better insight into selecting the appropriate stack of tools for your application.
If you want to deploy your own software stack, you would provision Azure Virtual Machines. Azure provides an SDK to interact with the cloud infrastructure.
Docker is a really good option to use for application deployment these days. Google provides better support for Docker containers using its Kubernetes framework.
Simple APIs or website can be developed on azure using Azure webapps. I am currently developing a node application using azure websites. The actual container where the site runs is a windows NT machine with IIS. If you want your SAAS server container's to be linux based then you might look at AWS/Google or Redhat Openshift.
I have used OpenShift SAAS, and found it quite easy to get onboard with.
I advise you to have a look at Build and Ignite events, this week. There might be more announcements there. You can definitely have a look at the following white paper: http://download.microsoft.com/download/E/1/F/E1FFDADF-C0FF-4E72-A834-B173A079F393/Microsoft_Internet_of_Things_White_Paper.pdf
The most important services for IoT in Azure are (until today):
Azure Event Hubs: a massive ingestion service that can take in millions of telemetry events per second.
Azure Stream Analytics: Real time complex event processing, combining multiple incoming streams of data and detection patterns in it
PowerBI: this will allow users to build and explore interactive reports and graphs
Azure Machine Learning: Leverage prediction & machine learning models
For storage, you have DocumentDB, Azure and blob storage, among other
HDInsight will help you in working with the data (big data) and make jobs with it.
Azure Web Apps and API apps will allow you to present and expose the data to you users and custom reports
Good luck
I want start developing with Azure platform. My question is: is there any chance to run azure environment on Windows Server? I don't want to test in Visual Studio, but on separate environment.
What software I need to emulate Azure environment?
The best you can do is to run the Azure Emulator that you're currently running on your desktop on the server, but that really won't achieve anything meaningful.
Windows Azure is not a set of features that can be installed on top of an OS. It's a complete data centre environment comprising bespoke hardware, customised OS, network systems, storage, SQL Azure, AppFabric and a whole host of other things.
If you have many millions of dollars to invest, Microsoft can build you a Windows Azure capability. We have one in Japan. One day, hopefully in the not too distant future, you'll be able to buy a much smaller one, but it's still likely to cost millions (if you're lucky, only a few $100k).
Practically speaking, it's much more cost effective to test your Azure applications on the public Azure platform.
From a practical perspective, you can architect your application to abstract out any direct dependencies on Azure into independent classes that can be substituted using Dependency Injection. By implementing versions of these classes that are designed to run in a standard Windows environment, you can test the vast majority of your application in your environment before deploying to Azure. Use SQL Server as a local equivalent to SQL Azure. Azure storage replacements may take some more thought and if you use features such as Service Bus or ACS, you've got yet more work to do.
But be sure to run a comprehensive test phase with your application running on Azure before you roll it into production.
Is there any ability to install a "development environment" for Azure, or a local equivalent that supplies all the same APIs, storage methods etc?
The end game is to not pay for Azure while I'm developing.
Yes, Azure SDK and Tools come with a local emulation environment that closely resembles real Azure and allows one to do most of development without ever deploying a single bit to Azure.
Emulation is provided for Roles and Azure Storage (Tables, Blobs, Queues).
If you need SQL Azure, suggestion is to use regular SQL Server and closely stick to compatible functionality only.
Just go to the Windows Azure page to download the SDK and tools - the installation is streamlined using the Web Platform Installer.
The local simulation environment simulates blobs, tables, and queues, as well as compute instances (although as separate processes, not as separate VM instances). The APIs all work in the local simulation environment.
To use SQL Azure, you'd need a real account. Same thing for the AppFabric services.
Just so you know: you can get a completely free account for 30 days, with SQL Azure, AppFabric services, and a few compute instances. Go to www.windowsazurepass.com, and use promo code DPWE01.
EDIT: Agreed with Igor in his answer: you can develop with SQL Server and then push your database up to SQL Azure. The latest SQL Server Management Studio supports SQL Azure-compatible sql output scripts. As Igor points out, just stick to compatible SQL (which is a very large subset of SQL Server).
The SDK is the way to go, but note, deploying worker role instances can be quite a bit more complicated, but testing locally once the SDK is installed, is fairly straight forward.