I am new to Windows Azure and need help with deploying my Azure application, which is correctly deployed to Azure, to a local server.
My application consists of one Web Role, which contains a Silverlight client for a Silverlight application.
I installed and configured windows server appfabric on the server and the server is actually ready. But I don't know how can I deploy/publish the application.
To deploy to Azure, i created the .cspkg file using the publish option in the right click on Azure application. And then deployed the generated files to Azure using azure management portal. how can i do something like that for the local server?
Windows Azure provides an emulator environment that runs on your development machine. You may either run a Windows Azure app in that emulator, or publish to Windows Azure. There's no option to deploy a Windows Azure application to Windows Server.
While some of the services offered are similar (such as cache), Windows Server AppFabric is not equivalent to the services provided by Windows Azure, and there's no equivalent fabric controller that runs on Windows Server.
EDIT: Adding clarification per #Asmaa's comments.
Building a private cloud is not the same as creating a local version of Windows Azure. The Private Cloud you reference is essentially a set of Windows Servers running virtual machines managed by Hyper-V, and some type of local storage. You'd be fully responsible for replication, disaster recovery, durable storage (where storage survives even with a disk crash), scaling, etc.
Windows Azure provides the abovementioned features, but only within its data centers. As #Avkash mentioned, there is a Windows Azure Appliance, but it there are only a handful in existence and they're huge (as in made for a data center).
If the objective is to run your code either locally or in Windows Azure, this can be done, but not by pushing the Windows Azure package to your Windows Servers. You'd need to build separate solutions to run your code in the two environments. You can reuse your core code if it's packaged correctly, but the notion of the Role Environment, Diagnostics, and other Windows Azure features would need to be replaced with something else.
One last thing: if you want to build a hybrid app, where some of it is deployed locally and some to Windows Azure, then there are certainly ways to bridge the two. See this article for more info.
The bottom line is that you can not deploy Azure Application to Windows Server machines in your own data center and David added all the info needed on this context. However, I just want to add little more as you are new to Windows Azure. I can understand why you are trying to do something like this and because I have had similar conversation with other partners in past, I believe this information is useful.
The main why you couldn't do it because Windows Azure main components i.e. Compute, Storage, Networking and other value added services which are built upon main component are just not available in your machine however, there is a lot more to it.
Windows Azure Appliance is a product which can be deployed to any Data Center and currently used by Dell, eBay, Fujitsu and HP as described in this link. Windows Azure and Windows Azure Appliance are not exactly same, however, Windows Azure Appliance does have a similar model of Compute, package deployment, Storage, Management portal and functionality. So when available to general public this could be a choice for data centers to have something similar to Azure running in their premise however it is currently available to only very limited partners.
Related
(Note that I'm using the new "blade" Azure Portal exclusively and use the new terminology, so avoid words like "Azure Website" as they do not apply here).
In the Portal I created two Azure App Services, "foo-production" and "foo-staging" - both exist in the same Subscription and Resource Group, and share the same App Service Plan. These App Services represent the production and staging deployments of a straightforward ASP.NET web application, which runs as a normal website.
The App Service Plan is "Basic: 1 Small".
My understanding is that when you use Azure App Services with a Basic or higher App Service Plan, that the Plan represents a VM which I'm able to host as many IIS websites as I want on - these IIS websites are represented in Azure as Azure App Services.
Given this, one would assume when I access the filesystem of the VM in Kudu ( https://yourwebsite.scm.azurewebsites.net/DebugConsole ) that I would be able to see each website's files under some common root directory.
However when I access the Kudu console for the foo-production website, I see that its files are in D:\home\site\wwwroot and files for foo-staging are not to be found.
If I'm understanding this correctly, it means that Azure actually created a whole new VM just for each website and that websites cannot share a filesystem - and that I cannot have a more advanced Azure-managed IIS configuration - I'd have to create my own self-managed Windows Server VM.
I can understand the motivation behind a separate VM for each website, it just seems wasteful - Windows Server requires at least a gigabyte of memory for each VM, yet my website is largely just static files (but I can't use a Shared App Service Plan because I need some of the more advanced functionality). That can't be economical for Microsoft then.
How can I have multiple Azure App Services in an Azure-managed environment share the same VM? Or am I thinking about it incorrectly?
To avoid an X/Y problem: I'll state that my primary concern is the persistence of files. The web-application I'm deploying stores uploaded files to a subdirectory of the webroot and those files should be there permanently. There is ambiguous information out there: some people suggest websites (and all their files) are actively destroyed and recycled and that Azure Storage Blobs should be used. I would like to use Azure File Shares, unfortunately I get ACCESS_DENIED errors when using WNetAddConnection2 and some users report that Azure File Shares cannot be used from within Azure App Services - though I cannot find anything authoritative from Microsoft about this.
If they are in the same App Service Plan, they are running in the same VM. Try typing hostname in Kudu Console for each and you'll see the same machine name.
But note that they each run in a different sandbox, which prevents them from seeing each other's files. Folders like d:\home are virtualized, and are actually pointing to network shares. So you can't use that to make conclusions as to the machines are the same.
As I answered here, all app services within a plan run in the same set of VMs, sharing all compute resources.
You assumed each app service within a plan shares files with all other app services. This is incorrect: Each app service will have its own set of files, in d:\home for each app service. If you need to share files, you'll need to use something external to App Services, like Azure File Service (an SMB share). Azure File Service is separate from the space created for you on a per-app-service basis.
An Azure "App Service" is analogous to a "Container" (Docker terminology). Although it's based on a VM, it's much lighter weight than a VM itself. For example, you cannot RDP into it.
An Azure "VM" is a full-fledged virtual machine. The OS can be Windows or any of several different flavors of Linux.
You can get more information here:
Azure App Service, Cloud Services, Virtual Machines, and Service Fabric comparison
Here is an excellent article that compares Web Sites (one example of an App Service), Cloud Services, and VMs:
http://www.c-sharpcorner.com/UploadFile/42ddd2/azure-websites-vs-cloud-service-vs-virtual-machines/
Azure Websites
Azure Websites has very little responsibility to complete, and
relatively less control. It is the best choice for most web apps.
Deployment and management are integrated directly into the platform we
get.
Azure Cloud Services
If you want more, web server like environment you might want to go
with Azure Cloud Services. You can remote into your cloud services and
configure startup tasks. Cloud Services provide you more Ease of
Management and Agility than Azure Websites
Azure Virtual Machines
Provides you rich set of features; however, correctly configuring,
securing and maintaining VMs require much more time and more IT
expertise compared to Azure Cloud Services and Azure Websites.
I am writing an application that will be deployed both to the cloud and to on-premise data-centres (for those clients who, essentially, don't yet trust the cloud with their data.
If i choose to go MS Azure I can use the new cloud project types with their Web and Worker roles. But how can I get the worker roles running for the on-premise variant?
Do I have to write my own host (say as a windows service)? This is not ideal as it requires additional code and deployment.
Is there an Azure compatible approach, say in the Windows Azure Pack or the App Fabric stuff (is App Fabric still current?) that doesn't require the full setup of the private cloud ?
This doesn't exist in Azure Pack.
There is no need to try and have a Worker Role on premise. All you need to do is to have a Virtual Machine that you install a Windows Service on.
It's easy to create a Windows Service using Topshelf.
Deployment of a Windows Service with Topshelf is actually much easier than deployments for Worker Roles because you just run the .exe you create with the install and then with the start arguments.
Because of this you actually need less code than for a Worker Role since you don't need a second wrapper project.
While I haven't used Windows Azure Pack before it does seem capable of providing this functionality in house, however the requirements and setup procedures are intense and it is certainly geared towards enterprise.
A better option is for you to create a console app that triggers the OnStart() and Run() functions for your WorkerRole based on your OS Task Scheduler.
Not too much work in my opinion and you get to keep your WorkerRoles as is but just add the console app for any on premise solutions.
We are starting to build out some new tech and I want to know if it is possible to cross develop a web app to run natively in Azure (ie, use Azure specific stuff like storage) but also run locally on our test servers and accommodate internal deployments natively on IIS?
I know I can host them from a dev box in a simulated Azure environment and I know that I can interface the Azure parts out and write in non-azure counterparts. It just seems like this should be a solved problem.
If you want to run Azure applications on-premises (and using non-development Azure storage), you must run a Microsoft Private Cloud. It requires special hardware and licensing costs, so don't expect it to run on what you have today.
I have a webrole I'd like to host in IIS for the time being.
Does anyone know how involved this is, considering that I still want Azure Storage functions of the IIS site to still work?
Azure Storage (tables, blobs, queues) only run on the actual Windows Azure environment in the cloud. There is a simulated development environment that runs a facsimile on a local SQL Server database, but that is only meant for development purposes and cannot be used for running an actual site.
Theoretically, you could run your webapp locally and connect to Azure Storage over the internet (e.g. by using the REST api), but latency would almost certainly be too high for any interactive site.
So, if you want to be able to run your site on premise on your own IIS environment, you will need to remove all the specific Azure platform dependencies and build in non-Azure alternatives. For Azure Storage, you could either do a relational database (SQL Server, mySQL) or look at a nosql/document database.
If you want to move it to IIS then tijmedvdk's answer is correct.
If your goal is to run it in your data center then you should consider Azure Appliance http://www.microsoft.com/windowsazure/appliance/ this allows you to run Azure applications on premise, without making any changes.
This answers seems misleading. Windows Azure is a platform that provides several services and you can choose from the services that you want to use.
In essence a Windows Azure is just a Virtual Machine with
*Windows Server 2008 R2
*IIS 7.5
So can if you have an application that you are currently hosting in Azure and you want to host it in IIS I don't see much of a problem there.
If you are using Storage, the only problem might be that the Storage account settings were in the WebRole or Service configuration files, but you can change your app logic to take the appropiate settings from other config files.
I have created Windows Desktop applications that for several reasons use Azure Storage and i also think of that as a great advantage of cloud computing.
I'd just like to know if its possible to deploy a web project, that usually runs on the windows azure cloud, to a normal windows server 2008 pc for testing purposes?
It depends what you're trying to test - if it's just the web app, why not map a virtual directory to the folder? If you're not using any of the Azure features (eg Queues), then can run it standalone as a normal asp.net application through IIS
No. There is no 'on premise' version of Azure and the only way you could do it is if you ran a dev environment on the server and ran the app in the Azure dev fabric.
I would suggest that for testing you should test on the cloud anyway as it is somewhat different to the local fabric. The big advantage of testing and the cloud is that you can spin up and shut down instances whenever you need, so it only costs money while you are actually testing. You might even be able to do most of your testing within the 'free' 25 hour allocation
Microsoft provide emulators to test a lot of the azure functionality locally including:
Compute emulator: very nice as allows you test app with multiple instances running
Storage Emulator: provide emulation of blob, table and queue storage
SQL Express can be used inplace of SQL azure but you need to be aware it is a superset of SQL Azure
The parts that arent emulated are:
Caching Service (very annoying really)
CDN (again a bit annoying)
So it depends on which azure services you are using as to how well you can test locally.