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.
Related
What is the difference between azure API-apps,logic-apps,web-apps and azure functions? And what difference does it make for developer?
Logic Apps:
Logic Apps provide a way to simplify and implement scalable integrations and workflows in the cloud. It provides a visual designer to model and automate your process as a series of steps known as a workflow. There are many connectors across the cloud and on-premises to quickly integrate across services and protocols. A logic app begins with a trigger (like 'When an account is added to Dynamics CRM') and after firing can begin many combinations actions, conversions, and condition logic.
Api Apps:
API apps in Azure App Service offer features that make it easier to develop, host, and consume APIs in the cloud and on-premises. With API apps you get enterprise grade security, simple access control, hybrid connectivity, automatic SDK generation, and seamless integration with Logic Apps.
Web Apps:
App Service Web Apps is a fully managed compute platform that is optimized for hosting websites and web applications. This platform-as-a-service (PaaS) offering of Microsoft Azure lets you focus on your business logic while Azure takes care of the infrastructure to run and scale your apps.
Functions:
Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud. You can write just the code you need for the problem at hand, without worrying about a whole application or the infrastructure to run it. Functions can make development even more productive, and you can use your development language of choice, such as C#, F#, Node.js, Python or PHP. Pay only for the time your code runs and trust Azure to scale as needed. Azure Functions lets you develop serverless applications on Microsoft Azure.
Api apps and Web apps are pretty much the same deal. Logic Apps and Functions are the same in a sense that they allow you to do something as a response to event or on a schedule, but Functions are a way to run code (or existing app) and Logic Apps are more like a workflow constructor, where you take existing actions and chain them (so no coding, or almost no)
ps. You can easily find documentation for those online to get a broader understanding
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.
What is the difference between azure API-apps,logic-apps,web-apps and azure functions? And what difference does it make for developer?
Logic Apps:
Logic Apps provide a way to simplify and implement scalable integrations and workflows in the cloud. It provides a visual designer to model and automate your process as a series of steps known as a workflow. There are many connectors across the cloud and on-premises to quickly integrate across services and protocols. A logic app begins with a trigger (like 'When an account is added to Dynamics CRM') and after firing can begin many combinations actions, conversions, and condition logic.
Api Apps:
API apps in Azure App Service offer features that make it easier to develop, host, and consume APIs in the cloud and on-premises. With API apps you get enterprise grade security, simple access control, hybrid connectivity, automatic SDK generation, and seamless integration with Logic Apps.
Web Apps:
App Service Web Apps is a fully managed compute platform that is optimized for hosting websites and web applications. This platform-as-a-service (PaaS) offering of Microsoft Azure lets you focus on your business logic while Azure takes care of the infrastructure to run and scale your apps.
Functions:
Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud. You can write just the code you need for the problem at hand, without worrying about a whole application or the infrastructure to run it. Functions can make development even more productive, and you can use your development language of choice, such as C#, F#, Node.js, Python or PHP. Pay only for the time your code runs and trust Azure to scale as needed. Azure Functions lets you develop serverless applications on Microsoft Azure.
Api apps and Web apps are pretty much the same deal. Logic Apps and Functions are the same in a sense that they allow you to do something as a response to event or on a schedule, but Functions are a way to run code (or existing app) and Logic Apps are more like a workflow constructor, where you take existing actions and chain them (so no coding, or almost no)
ps. You can easily find documentation for those online to get a broader understanding
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.
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