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.
Related
My web project uses an software, which need to be installed on destination PC. So, I have to use Azure VM and no way to use Azure Cloud Service, right?
Also, can I use SQL Azure with Virtual Machine?
You can install any third party software on Azure Web/Worker roles (Cloud Services), as long as the installer supports a quiet/unattemded install from a command line with switches. Learn more how to do this via StartUp tasks here.
As for Azure SQL Database - you can use with any combination of services. Even with on-premises only solution. You have to take care of Firewall rules.
Azure SQL Database tends to be much less expensive than a VM with SQL Server installed. It won't run on a VM but you can access an Azure SQL database from an VM or web application in the same way you access local databases - You just set the connection string to the Azure SQL connection string.
There is an excellent post that can help you with in order to understand how to configure customization with cloud services.
microsoft-azure-cloud-services-part-4-lifecycle-and-customization-of-your-vm
As the link explains there is nothing persisted on a cloud service VM but this is not a limitation instead a good practice which allows easy scaling out by adding more instances if required.
You can use Azure PaaS SQL just like a SQL server installed on a different server then your web server with some limitations. Please have a look at the link below from MSDN to understand these limitations.
sql-database-transact-sql-information
I'm interested in the new proposal from Microsoft. And before I do something I'll ask some important questions.
Because I haven't found direct contact with Microsoft support I'm here.
What we have now
It's 4 virtual machines:
Windows Server with SQL Server;
Windows Server with 4 our services (.net 3.5);
Windows Server with our services (Bitrix(Apache on Windows with some features));
Linux as vpn server.
Questions
Main question is what's the best way to migrate our infrastructure to Microsoft.
It's some considered aspects
performance
easy setup
reliability
cost (it doesn't matter now)
Details
Will it be better to stay on virtual machines or try to migrate in azure as app services?
Will it be difficult to migrate from windows service app on .Net 3.5 to cloud app?
As I know Microsoft has its own offer for data storage and I don't need to get virtual machine for it do I?
Can it be private access to SQL DB only from my services or virtual machines (just paranoid)?
Ok... here we go...
Q:Will it be better to stay on virtual machines or try to migrate in azure as app services?
A:Depends on your application. If your application is cloud ready then azure services is your answer, if not, go for traditional hosting...
Q:Will it be difficult to migrate from windows service app on .Net 3.5 to cloud app?
A: Impossible to say without checking your source code. Thumb-Rule? No, it wont be a problem...
Q:As I know Microsoft has its own offer for data storage and I don't need to get virtual machine for it do I?
A:Depends. If by data storage you mean blobs then no you don't but be careful because the storage on the machines are not expansible! You should consider refactoring your code to use blob storage. BUT if by data storage you mean SQL Azure storage you have to be extra careful because of the 150GB limit... consider major refactor for database "sharding" in this case...
Q:Can it be private access to SQL DB only from my services or virtual machines (just paranoid)?
A: Depends. If by SQL DB you mean SQL Azure then YES, this is a native thing BUT if by SQL DB you mean the one that you're going to host on your VM, you CAN too but it's not a native solution. You'll have to get your hands dirty messing with the virtual network...
EDIT1: My personal recommendation is: Migrate your app to a cloud native app, specially if you have a multi-tenant scenario or you want to better deal with usage peaks or save on hardware/infra-structure investments. Remember "your business is to build and run software, not hardware"! (I don't know if that's your case... but its mine...)
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.
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.
I have a BizSpark account and I get some Azure freebies from Microsoft. But, I'm forced to create a live SQL Azure database to use in my local development. This slows me down a bit because I have to read/write over the wire when I'm developing, and I must remain connected at all times.
Is there a way, or a technique, to build locally and have my deployments access the express edition of SQL Server on my machine? I'm using EF4 to access the database.
First of all, as a part of Bizspark, you get 3 SQL Azure databases for free. http://msdn.microsoft.com/en-us/subscriptions/ee461076.aspx
This will allow you to have 1 DB for testing, 1 for dev, and 1 for production
If this does not work out for you, you CAN develop on your local SQL Express and keep deploying your changes to SQL Azure as you deploy your application to Azure. There are two tools that help you here:
1) open-source SQL Azure Migration Wizard: http://sqlazuremw.codeplex.com/ -- we personally do not use this for deployments, so I am not super knowledgeable to comment on this. It is a decent tool to back your SQL Azure database.
2) You can use Red Gate's SQL Compare product, as of v9.0+, they support synchronizing cross SQL Azure and on-prem SQL servers. We use this for AzureWatch and are very happy. It is commercial product and is somewhat pricey.
HTH
+1 to Igorek's answer - plenty of good suggestions there.
In addition to his advice, if you are a BizSpark licensee then I suggest you deploy full SQL Server 2008 R2 to a local box and develop against that.
There are differences between full SQL Server and SQL Azure - you should read around to be aware of these - http://social.technet.microsoft.com/wiki/contents/articles/comparing-sql-server-with-sql-azure.aspx
As long as you are aware of the differences (especially the SQL Azure limitations) then migrating back to SQL Azure later, should be reasonable.