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
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 hoping I can put in some simple API calls in legacy systems so I can capture point-in-time metrics "somewhere" in Azure, so that I can then take advantage of the Azure Portal dashboard and metrics graphing. I looked into Insights SDK but that seems to require that whatever I'm running be deployed somewhere in Azure cloud. I just want to run a simple powershell script or simple .net console app that connects to a legacy database in our internal network, pulls very basic point-in-time counts for message processing backlog... and then pushes that info with a timestamp out "somewhere" for visualization.
Any ideas what I can use for this in Azure?
Thanks,
Andres
You can use the TrackMetric API in Application Insights SDK.
https://learn.microsoft.com/en-us/azure/application-insights/app-insights-api-custom-events-metrics
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 want to deploy Kentico 9 site on Azure and want to use shared file system for my media content, can you please suggest which Azure configuration (Azure Cloud Services or Azure Web Apps) I should referred?
I'd highly recommend going with Web App over Cloud Services. Mainly because Web App is almost like running on a regular server where Cloud Services is quite a bit different and harder to work with in my opinion.
Check this article out regarding some issues with Kentico and Azure Blog storage as well as how to setup your storage provider to only store media files.
http://www.kehrendev.com/blog/brenden-kehren/may-2016/problems-with-azure-and-kentico
Could you describe what do you mean by shared file system for my media content?
From my experience - it`s (a little bit) easier to deploy (and maintain) Kentico to Azure Web Apps but they do not provide so many customizations - in my humble opinion - the biggest one is you are not able to connect via remote desktop (but this is supported by Azure Cloud Services).
Please note - if you are using Cloud Services you must use Azure Blob Storage - source - which could be in conflict with your requirements.
You can find more information about Web Apps vs Cloud Services vs Virtual Machines on the mentioned page.
TL;DR; - if you do not need customizations, remote desktop and startup tasks - go for WebApps. If not, try to specify more requirements.
You can also check comparinson of the technologies from the Microsoft`s point of view here.
It's not clear who you want to share the media with...
If you want to share the assets amongst more Kentico instances or with a 3rd party system, I'd probably use the Azure Blob Storage. Kentico comes with a dedicated file provider for this exact use out of the box. It's called CMS.AzureStorage.
Using the blob storage is not a limiting factor in terms of hosting your app. You can still use all available options: Web Apps, VM or Cloud Service. There are some technical implications, of course. But they're all described in the documentation.
I recommend checking the comparison matrix to find a hosting option that suits your need best. Kentico recommends using App Service (Web Apps) for most projects as it's easiest to maintain. However, you can't use certain features like Kentico Windows services, for instance. Question is, do you really need them?
I've recently been asked to redevelop an .Net 2.0 WinForms application with a back end SQL Server Express DB.
One of the requirements is to allow remote users access to the application, so I've been considering hosted options to avoid VPN setup. The data is not sensitive and does not fall under data protection act, so a basic security approach for the web will cover me.
I like the idea of using Azure for a few reasons, but I'm not sure if a good fit for a users base of 5 or 6 with no real scope to grow. I've never used Azure and I plan to develop using MVC and a SQL backend as this is my main skillset.
A few points in favour of Azure in my mind are:
Tight integration with the TFS preview that I'm using for this project
Easy to setup a sandpit and a live version
Easy maintenance as I expect other hosted options will require more knowledge of underlying OS
Sticking to a full Microsoft stack should hopefully make things simpler
From what I find on the Azure site the message is all about scalability, which is great if you need it.
My question is simply, do you need a large user base, or plans to grow quickly, to use azure or is it how we should be hosting apps now?
What you're asking here is the perfect case for Windows Azure Web Sites:
You get 10 web sites for free (no custom DNS, but this is perfect for your 'sandpit'/test version). The shared mode supports custom DNS and is very cheap.
Tight integration with TFS preview and GitHub
You don't need to worry about the underlying OS, you simply publish from Visual Studio or with TFS Preview.
Sticking to the Microsoft stack is the easiest solution, but other technologies work great aswell. Since you're talking about MVC I'm assuming you are considering ASP.NET MVC, which is a perfect match with Windows Azure. Take a look at the training kit for some good examples.
The day you'll need a solution which more scalable (meaning you'll have more users and more income) you can easily upgrade to a reserved instance or to a Cloud Service (Web/Worker Role).
About your question: "My question is simply, do you need a large user base, or plans to grow quickly, to use azure or is it how we should be hosting apps now?"
Windows Azure is a cloud service platform (includes PaaS as Cloud Services, IaaS as Windows Azure Virtual Machines and also Websites suggest by Sandrino above), and with cloud services you have ability to start very small and grow as much and as quickly as your user requirement is, so you can use Azure with both cases. On the other hand there are some advantages using certain offering depend on your which service you are going to use to run your application.
I think article (Section: "What Should I Use? Making a Choice") will explain the strategy about how you make a selection among various services.
This SO discussion does talks about the difference between cloud Services and Azure WebSites as well.