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
Related
I am using SSRS report in my web application now, I want to deploy SSRS report on azure, I found one option using azure VM but its costly as I am using free account, Is there any other option?
Please suggest me the proper way.
Now spinning a SQL Server VM might result in costs way higher than you might expect (due to licenses), so always make sure you run it on a version of SQL Server Developer, which has all the features of the highest SQL edition, but it is free (not to be run in production). See here.
If you use one of the SQL Gallery Images, then you don't need an additional SQL Server license. See Azure VM pricing here
You can try Pay-As-You-Go option
You need to be more specific - the cost of licensing what? Azure SQL Reporting? Virtual Machines? SQL Server licensing?
you would have to set up SSRS somewhere. Azure-hosted VM depends on a lot of factors such as your budget, on-premise infrastructure capacity, overall cloud strategy of your organization.
Licensing - Azure lets you pay directly for VMs that include SSRS. For example you can get SQL Server Standard 2012 (which includes SSRS) on a "Small" Server 2012 vm for about
Using Dynamics 365 for Operation Could VM (deployed in scope of the LCS subscription), there is a requirement to access the SQL DB directly using ODBC connection from excel. Customer is not happy with implementation via Odata or custom service.
Current problem: can't connect to AX DB using ODBC
Please, could You correct me, if I'm wrong: in case there is cloud D365 VM, deployed in scope of the LCS subscription, the VM deployed against client Azure subscription, but VM is hosted on the Microsoft Azure site, thus there is no way to maintain VM from Azure (only RPD connection for non-production systems) and even we manage to open the required port on the VM site, the connection is not able to reach the DB because of Azure environment. Production system is even less manageable as required MS service requests. Following my logic, the appropriate way is to use one of the supported by AX frameworks \ protocols as it's always accessible regardless of system type and etc
You do not have direct SQL connection possibilities for D365fFO production environment located in Azure. Consider to use OData feeds, Logic Apps (MS Flow) or PowerApps (CDS Projects) instead.
If you planning to use direct connection for reporting purposes (read only), you able to configure copying the production DB to Sandbox and to another DB instance sequentually.
Also you able to restore DB on to production environment from Sandbox before Go-Live.
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...)
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.
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.