I am trying to port my Android application into a Cloud based one. Where I wanted the data stored in cloud. I am a .NET guy so looking into Azure. I see Azure Mobile services which allows me to create tables and ability to authenticate. I also Looked into Azure SQL database.
I would like to know what is the difference between these two services and what are the scenarios using mobile services gives values than using Azure SQL database
Actually, the tables you see listed in Azure Mobile Services are actually tables that are in an Azure SQL Database instance. The Mobile Services provides an abstraction layer on top of the tables in SQL Server. If you use the current JavaScript back-ended mobile services you'll see the table in the management portal and it uses the dynamic nature of JavaScript to provide what appears to be a NoSQL like experience with Azure SQL DB in that you can send in an object and properties it doesn't recognize will be added to the table schema (you turn this off when you ship to production :) ). The big thing to remember is that under the hood the database is an Azure SQL DB, so you should have access and do anything via the one created by Azure Mobile Services as you can with the raw Azure SQL DB.
By using Azure Mobile Services you get an API hosting layer that you can use to do direct access to the tables (based on the permissions you hinted at) but also to just about anything utilizing the custom API feature.
If you chose to bypass the Azure Mobile Services you'd likely want to have some API layer between your Android app and the data for a variety of reasons (security, abstraction of data location, etc.). In which case you'd have to write and host that API layer somewhere. Other options within Azure would be a Web API site in Azure Web Sites, an API hosted in an Azure Cloud Service or all the way up to an Azure VM; however, as you slide up that scale you're taking on more and more responsibility and work.
The scenario that is useful to use Azure Mobile Services over the Azure SQL DB is pretty much the scenario you have. You don't have to maintain your own hosting API layer, just the code the API layer executes. You can scale an necessary (to a very large scale indeed) and also get features like the push notifications and web jobs (though those are also things you can do via other services in Azure if you'd like). Thinks of Azure Mobile Services as a higher level grouping of Azure services that are helpful to mobile developers.
Mobile services provide you with built-in push notification features and other such mobile friendly features too. They are more mobile oriented in a way.
Related
I can't find an example code for publishing ASP.NET Webforms websites to Azure Functions. Months ago I tried to replicate the C# example but I ended up with only being able to use the precompiled batch function type.
I want to publish VB.NET web apps - any framework version, using Web Deploy...
Here are some important concepts you should know about Azure Web App and Azure Function:
Azure Web App:
Azure Web App is a sand box. The only way an Azure web app can be accessed via the internet is through the only two already-exposed HTTP (80) and HTTPS (443) TCP ports.
For Nodejs App deployed to Azure, Azure will create a named pipe for your server to listen, and pass the request from 443 port(as you use https) to the named pipe.
Azure Function:
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)
Deploy:
Use ftp to deploy your web form to Azure Function. There will be no problems with the deployment, but the webpage will not display.
Note:
Although Azure Function and Azure Web App are very similar in many cases. But if you choose to deploy web form app, you will still find differences. Even if you can deploy your project to Azure Web App, it won’t display any webpages.
Is it better (best practice wise) to use the Azure Blob Storage APIs from an Azure Web App (server side code) or make the API calls from an Azure function.
I think using the functions way is better for 'separation of concerns', more maintainable - in that multiple apps could use the same azure function - one place instead of many, can be monitored from within Azure (metrics) and dashboard. During a data breach a function can be turned off without shutting down the web app. Are there other reasons to use the API from a function vs the Web App backend?
Thanks
all the tutorial videos of azure shows the data tab in mobile services but in real it is not present there.
https://drive.google.com/file/d/0BxhoXvChLA34dDB1Mm1KVFIwRUU/edit?usp=sharing
When using the .NET backend, creating tables and custom APIs are done code first and you can't control them via the portal.
For tables start here: http://www.windowsazure.com/en-us/documentation/articles/mobile-services-dotnet-backend-windows-store-dotnet-get-started-data/
I don't see any tutorials up yet on the custom API path yet but I may have missed them.
Context:
Building new multi-tenant application using Azure SQL, Azure Table Storage, EF, Web API, MVC, Azure Cache, Possibly Worker Roles -- all the usual suspects:
Please see prior question asked/answered a while back (Jun '12): What is the difference between an Azure Web Site and an Azure Web Role
Side Note:
I'm leaning towards Web Role/Worker Role for Web API and Web Site for MVC/CMS frameworks (i.e., DotNetNuke)
I understand Web Sites are out of beta and have closed the gap with the Web Role in some respects.
Question:
I'm looking for an updated answer to the following:
What are the material differences between the new Azure Web Sites and the traditional Azure Web Roles for an ASP.NET MVC and an ASP.NET Web API application? What reason would I choose a "web site" over a "web role" or vice versa?
Nowadays you have the following execution models:
-Web Sites
-Cloud Services (Worker Role / Web Role)
-Mobile Services
-Virtual Machines
What are the differences between Cloud Services and Web Sites.
-Cloud Services:
You could integrate with Team Foundation Services and allow it to publish to Azure. (Continuous Delivery). With Cloud Services (Web Role), you have two environments in Azure, staging and production. You can use Staging to validate, and with one click (swap option), apply the new deployment package to production environment.
-Web Sites:
Web Sites is the right option when you want to create a simple web site. It is also a good choice for creating a low-administration web application, even one that must be quite scalable, or moving an existing IIS web app to the public cloud.
Cloud Services, which was the initial execution model provided by
Windows Azure, is an explicitly PaaS approach. While the line between
PaaS and web hosting is blurry, Cloud Services differs in some
important ways from Web Sites, including the following:
Unlike Web Sites, Cloud Services gives you administrative access to
your application’s VMs. This lets you install arbitrary software that
your application needs, something that’s not possible with Web Sites.
Because Cloud Services offers both web roles and worker roles, it’s a
better choice than Web Sites for multi-tier applications that need
separate VMs for their business logic. Cloud Services provides
separate staging and production environments, making application
updates somewhat smoother than Web Sites. Unlike Web Sites, you can
use networking technologies such as Windows Azure Virtual Network and
Windows Azure Connect to hook on-premises computers to Cloud Services
applications. Cloud Services lets you use Remote Desktop to connect
directly to an application’s VMs, something that’s not possible with
Web Sites.
http://www.windowsazure.com/en-us/manage/windows/fundamentals/compute/
More info:
http://www.windowsazure.com/en-us/manage/services/cloud-services/how-to-create-and-deploy-a-cloud-service/
I have SOAP services with data. I want to download all data from that service and upload it to my own server and then use these data from my server (don't worry I have permission for that). I want to do it because now I don't have function from that service which I need.
I want to use Windows Azure for this and I think SQL Database scenario would be best. Now I have classes for previous SOAP service so I think EF Code first would help me with creating database and I upload data somehow. But what about API? How can I access my data from windows phone or tablet? Is azure database enought or I must create more? Is there any good article for that?
I think what you are saying, is that you are aggregating data from several sources and storing the information in your own database. And, you would like your database to be Azure Database. Then, you want to build an API to expose the data you retrieved.
If this is indeed your goal, then yes, Azure will do everything you need. I'd recommend checking out Web API in conjunction with your Azure deployment. I've used this scheme with some success over the past year.
Warning: You should know that Azure Database does not have an SLA which means that Microsoft does not guarantee any level of performance including transactions/second. This means that if your API has a high load, you could end up getting throttled heavily in an unpredictable way. I've been bitten by this before and ended up moving my data to Azure Table Storage instead.
Windows Azure gives you a few options to expose an API to your mobile clients:
You could build an API yourself with the ASP.NET Web API (and use SQL Azure as backend): Mobile-friendly REST service using ASP.NET Web API and SQL Database
You can use Windows Azure Mobile Services, this does all the heavy lifting of building a backend for you