Hi everyone! Let's continue configuring the Microsoft Azure Recovery Services. Last time, we finished with loading the certificates necessary for working with the service. Now, let's finally set up the Microsoft Azure Backup Agent for performing the backup.
Greetings, readers! Last time, we looked at the costs of storing backups with the help of Microsoft Azure Recovery Services and compared them to the costs of using Microsoft Azure Storage Services.
Oftentimes while working with the Microsoft Azure cloud platform, clients require a backup service for data stored either in the cloud or on the local servers. If we are looking at the SQL Azure database, then the answer is simple - SQL Azure Data Sync. But what do we do if this functionality is required, for example, for virtual machines? Or maybe for data that is not relational or is not stored in a relational database?
The previous post was devoted to configuring SQL Reporting in Microsoft Azure. We've looked at two alternate configurations for report publishing services: as a service (SQL Reporting), and using an SQL Server virtual machine (SSRS). Now, let's have a look at the SQL Reporting services and the SQL Server configuration method which supports multi-tenant scenarios, when a single reporting service can be used for different data sources.
Last time, we compared the cost of using the reporting services that are available as a service in Microsoft Azure (SQL Reporting) with the option of virtual machine deployment with an SQL Server (SSRS).
Customers increasingly want to move their existing solutions into the cloud, and the Microsoft Azure platform is becoming more and more popular in the field of cloud calculations.
Greetings to all the Internet dwellers out there, and a happy beginning of a new week! We continue migrating the database using SQL Azure Federations. As you may remember, previously we selected the table and the field we will be using to divide our database into shards. Let’s do it!
Last time we've covered some theory about SQL Azure Federations, including what you should give a thought and what you should keep in mind when migrating. Importantly, it's not only about technology. The first thing to consider is always the database architecture, regardless of the scaling out method you choose - Federations, MySQL Cluster or anything else. The database you scale out must be always architecturally oriented.
Scaling application in cloud is a burning issue. The very concept of cloud technology implicates on-demand application scaling. Any decent cloud provider supports respective functions. Why is scaling out so important? What are the ways to do it effectively?