Introducing Azure SQL Database

Editor's Notes

• #2: So you have been running on-prem SQL Server for a while now.  Maybe you have taken the step to move it from bare metal to a VM, and have seen some nice benefits.  Ready to see a TON more benefits?  If you said “YES!”, then this is the session for you as I will go over the many benefits gained by moving your on-prem SQL Server to an Azure VM (IaaS).  Then I will really blow your mind by showing you even more benefits by moving to Azure SQL Database (PaaS/DBaaS).  And for those of you with a large data warehouse, I also got you covered with Azure SQL Data Warehouse.  Along the way I will talk about the many hybrid approaches so you can take a gradual approve to moving to the cloud.  If you are interested in cost savings, additional features, ease of use, quick scaling, improved reliability and ending the days of upgrading hardware, this is the session for you!
• #3: Fluff, but point is I bring real work experience to the session
• #5: One of the first things to understand in any discussion of Azure versus on-premises SQL Server databases is that you can use it all. Microsoft’s Data Platform leverages SQL Server technology and makes it available across physical on-premises machines, private cloud environments, third party hosted private cloud environments, and public cloud. This enables you to meet unique and diverse business needs through a combination of on-premises and cloud-hosted deployments, while using the same set of server products, development tools, and expertise across these environments. As seen in the diagram, each offering can be characterized by the level of administration you have over the infrastructure (on the X axis), and by the degree of cost efficiency achieved by database level consolidation and automation (on the Y axis). When designing an application, four basic options are available for hosting the SQL Server part of the application: SQL Server on nonvirtualized physical machines SQL Server in on-premises virtualized machines (private cloud) SQL Server in Azure Virtual Machine (public cloud) Azure SQL Database (public cloud)
• #8: The SQL Database service was designed to build cloud designed applications. What do I mean when I say cloud-designed? I am talking about applications that can scale dynamically across multiple nodes during peak demand and have the ability to scale down to fewer nodes during normal demand, dynamically. SQL Database service is a scale out relational database and ideal for cloud applications, where demand often times in not predictable. It offers the ability to architect your database application to use database sharding for dynamic scalability across multiple nodes. This is a unique design point that lets customers gain the full benefits of cloud scalability. 3M did just that by building Visual Attention Service (VAS) software, which measures marketing effectiveness of products, on SQL Database service. This VAS application has seen over 400x growth in demand and SQL Database was able to scale out to meet demand without problem and reduce in capacity during nominal demand. 3M not only realized infrastructure and data platform management cost saving, but also 50% revenue growth by being able to scale dynamically to capture all demand. They view SQL Database as a providing cost effective scalability and with an SLA for the infrastructure and the database, it less they have to manage and worry about, as they highlight in their quote. This all adds up to faster time to market for 3M’s VAS software. http://www.microsoft.com/casestudies/Windows-Azure/3M-Informatics/3M-Unit-Boosts-Revenue-by-50-Percent-with-Choice-of-Cloud-Service/710000002636
• #9: You can also use the SQL Database service to create hybrid applications like BetonSoft has done. Betonsoft is an online gambling company that wanted to build a highly resilient gaming platform, so the implement SQL Server AlwaysOn on-premises for synchronous replication and used the asynchronous replicas for off loading BI and reporting. To ensure even higher resiliency they decided to move gaming platform error reporting and metric monitoring system off-premises to Microsoft Azure SQL Database so that if there is an issue with the gaming engine the errors and metric can easily recovered from Microsoft Azure. They also decided to move their application marketing engine that needs dynamic scalability during viral marketing pushes to SQL Database as it offered the dynamic scalability they were looking for so they did have to build infrastructure for peak demand. In addition by taking advantage of the many Microsoft Azure data centers they were able to improve their global reach and performance of their marketing applications that promote their gambling platform to users worldwide. http://www.microsoft.com/casestudies/Microsoft-SQL-Server-2012-Enterprise/BetOnSoft/Online-Gaming-Firm-Implements-Real-Time-Analytics-and-Scales-for-Planned-Growth/710000000130 Situation: BetOnSoft develops and manages more than 110 online casino games, played every day by thousands of players worldwide. The company needed to ensure that its games are highly available, and the company wanted to prepare for business growth by scaling its database without impacting application responsiveness. Solution: The company deployed a hybrid application solution that takes advantage of the high-availability features in Microsoft SQL Server 2012 AlwaysOn and runs several critical services on Microsoft Azure SQL Database for its high availability and fast provisioning. For example, BetOnSoft maintains its error-reporting service in the Microsoft Azure cloud with data stored in Microsoft Azure SQL Database. Benefits: The solution helps BetOnSoft enhance the services it provides to the operators that run the company’s games. Using the monitoring service in SQL Database, the company says it can see where the problems are and if there are certain trends, enabling them to use these metrics to enhance services and improve the overall user experience. The company is also seeing dramatically improved availability and scalability—its infrastructure can exceed 10 times its previous peak loads while running intensive real-time data analytics. BetOnSoft also says the solution helps simplify administration for BetOnSoft database administrators, with the ability to check the database frequently and easily, as well as offload reporting, helping to reduce time and effort.
• #13: Resource & tenant administration. With Elastic Database Pools, you gain automatic management and administration of compute and storage across an unlimited number of databases – helping cap your spending, maximize utilization, and effectively scale multitenant apps.
• #16: http://www.jamesserra.com/archive/2016/01/hadr-for-azure-sql-database/
• #17: By storing your data in Azure SQL Database, you take advantage of many fault tolerance and secure infrastructure capabilities that you would otherwise have to design, acquire, implement, and manage. Azure SQL Database has a built-in high availability subsystem that protects your database from failures of individual servers and devices in a datacenter. Azure SQL Database maintains multiple copies of all data in different physical nodes located across fully independent physical sub-systems to mitigate outages due to failures of individual server components, such as hard drives, network interface adapters, or even entire servers. At any one time, three database replicas are running—one primary and two or more replicas. Data is written to the primary and one secondary replica using a quorum based commit scheme before the transaction is considered committed. If the hardware fails on the primary replica, Azure SQL Database detects the failure and fails over to the secondary replica. In case of a physical loss of a replica, a new replica is automatically created. So there are always at minimum two physical, transactionally consistent copies of your data in the datacenter.
• #23: Azure Active Directory authentication is a mechanism for connecting to Microsoft Azure SQL Database by using identities in Azure Active Directory. With Azure Active Directory authentication, you can centrally manage the identities of database users and other Microsoft services in a single location. Central identity management provides a single place to manage Azure SQL Database users and simplifies permission management. Benefits include: An alternative to SQL Server authentication Help in stopping the proliferation of user identities across database servers The ability to perform password rotation in a single place Management of database permissions using external Azure Active Directory groups Elimination of the need to store passwords: it enables integrated Windows authentication and other forms of authentication supported by Azure Active Directory Azure Active Directory authentication uses contained database users to authenticate identities at the database level. Azure Active Directory members created in the managed domain or with a federated domain can be provisioned in Azure SQL Database. Limitations: Microsoft accounts (for example outlook.com, hotmail.com, live.com) or other guest accounts (for example gmail.com, yahoo.com) are not supported. Only one Azure Active Directory administrator (a user or group) can be configured for an Azure SQL Database at any time. Only an Azure Active Directory administrator can initially connect to the Azure SQL Database using an Azure Active Directory account. The Azure Active Directory administrator can configure subsequent Azure Active Directory database users. Some tools like BI and Excel are not supported. Azure Active Directory authentication only supports the .NET Framework Data Provider for SQL Server (at least version in .NET Framework version 4.6). Therefore SQL Server Management Studio (available with SQL Server 2016) and data-tier applications (DAC and .bacpac) can connect, but sqlcmd.exe cannot connect because sqlcmd uses the ODBC provider. Two-factor authentication or other forms of interactive authentication are not supported.
• #24: Row-Level Security is a programmability security feature that can be implemented on databases to enable fine-grained access to rows of data in a table for greater control over which users can access which data. This allows for more flexibility and data protection when multiple logins need to access various records in a database and can help organizations more easily support organizational or industry compliance policies. Row-Level Security is managed at the database level and requires SQL Server Management Studio (SSMS) or SQL Server Data Tools (SSDT) to implement and manage. Generally, any application which has multiple users accessing various data records can benefit from Row-Level Security; here are a few key examples: A hospital or medical clinic could implement a security policy that allows nurses and doctors to only see data rows for their own patients. A bank might implement a security policy to restrict access to financial data rows based on the employee's business division or based on her role within the company. A multi-tenant application might store multiple customer records within a single database to achieve cost efficiencies. To ensure greater data security and isolation, a security policy can be implemented to further create a logical separation of each tenant's data rows from other tenant's rows.
• #25: Dynamic Data Masking is a Security service of Azure SQL Database that enables Azure Administrators to restrict access to sensitive data on productive databases. The sensitive data is persisted in the database in its original format. Based on a Data Masking policy, mask function (full mask / partial mask) is applied on specific fields. You may use either the Azure Management Portal, the new Azure Portal, PowerShell or REST API to configure data masking. For the Azure Management Portal, the configuration is under the Auditing & Security Section. For the new Azure Portal there is a dedicated section in the Database Tile. Dynamic Data masking is supported across the V12 versions of the Basic, Standard and Premium tiers and is included at no extra cost.
• #26: Transparent Data Encryption leverages the long-time trusted encryption technology found in SQL Server and brings it to SQL Database V12 databases for encrypting a customer’s database at rest to help further protect against the threat of malicious activity. Transparent data encryption (TDE) performs real-time I/O encryption and decryption of the database, associated backups, and transaction log files. We have leveraged the latest hardware technology in the V12 service architecture to help minimize any performance impact TDE may impose on a customer’s database. It is very similar to TDE for SQL Server in that encryption/decryption is completely transparent and requires no changes to an application using a database that is protected by TDE. Unlike TDE for SQL Server, the first version of TDE for SQL DB is completely “service-managed” meaning TDE is on by default and all keys incl. rotation, backups are managed by the service. TDE for SQL DB currently does not offer an EKM option which will be provided in version 2 (see below). Currently, TDE uses a database encryption key (DEK) protected by a TDE certificate. The certificate is stored in the SQL Database service on separate physical hardware for availability during recovery. We will explore additional key storage options at a future date.
• #27: Always Encrypted is a feature designed to protect and extra measure of protection to sensitive data, such as credit card numbers or national identification numbers (e.g. U.S. social security numbers), stored in SQL Server databases and in Azure SQL Database. This feature protects data while it is most vulnerable: while it is being used.   Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to SQL Server. As a result, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should have no access). By ensuring on-premises database administrators, cloud database operators, or other high-privileged, but unauthorized users, cannot access the encrypted data, Always Encrypted enables customers to confidently store sensitive data outside of their direct control. This allows organizations to encrypt data at rest and in use for storage in Azure, to enable delegation of on-premises database administration to third parties, or to reduce security clearance requirements for their own DBA staff.   Always Encrypted makes encryption transparent to applications. An Always Encrypted-enabled driver installed on the client computer achieves this by automatically encrypting and decrypting sensitive data in the SQL Server client application. The driver encrypts the data in sensitive columns before passing the data to SQL Server, and automatically rewrites queries so that the semantics to the application are preserved. Similarly, the driver transparently decrypts data, stored in encrypted database columns, contained in query results. Data is thus encrypted even during transactions and computations.
• #30: https://azure.microsoft.com/en-us/documentation/articles/sql-database-get-started-sql-data-sync/ https://www.mssqltips.com/sqlservertip/3062/understanding-sql-data-sync-for-sql-server/ https://msdn.microsoft.com/en-us/library/hh868047.aspx Compare SQL Data Sync to Active Geo-Replication
• #37: Based on customer feedback, Azure SQL Database is introducing new service tiers to help customers more easily innovate with cloud-designed database workloads. At the heart of this change, the new tiers deliver predictable performance across a spectrum of six performance levels for light- to heavy-weight transactional application demands. Additionally, the new tiers offer a spectrum of business-continuity features, a stronger uptime SLA, larger database sizes for less money, and an improved billing experience.
• #38: Migration tools Tools used include SQL Server Management Studio (SSMS), the SQL Server tooling in Visual Studio, and the SQL Azure Migration Wizard (SAMW), as well the preview of the new Azure management portal. Be sure to install the latest versions of the client tools as earlier versions are not compatible with the preview of the latest SQL Database Update. The role of each tool is summarized below together with a link for installing/accessing the latest version. Preview Azure Management Portal The preview Azure management portal (http://portal.azure.com) is required to create servers using the latest SQL Database Update or to migrate existing servers and databases. You can find out more about migrating existing servers here: http://azure.microsoft.com/en-us/documentation/articles/sql-database-preview-upgrade/. SQL Server Management Studio (SSMS) SSMS can be used to deploy a compatible database directly to Azure SQL Database or to export a logical backup of the database as a BACPAC, which can then be imported, still using SSMS, to create a new Azure SQL Database. You cannot use the preview portal to import a BACPAC yet. You must use the latest version of SSMS to work with the preview of Azure SQL Database Latest Update which is available in CU5 of SQL Server 2014 or by downloading the latest version of the tools from http://msdn.microsoft.com/en-us/evalcenter/dn434042.aspx. SQL Azure Migration Wizard (SAMW) SAMW can be used to analyze the schema of an existing database for compatibility with Azure SQL Database, and in many cases can be used to generate and then deploy a T-SQL script containing schema and data. The wizard will report errors during the transformation if it encounters schema content that it cannot transform. If this occurs, the generated script will require further editing before it can be deployed successfully. SAMW will process the body of functions or stored procedures which is normally excluded from validation performed by the SQL Server tooling in Visual Studio (see below) so may find issues that might not otherwise be reported by validation in Visual Studio alone. Combining use of SAMW with the SQL Server tooling in Visual Studio can substantially reduce the amount of work required to migrate a complex schema. Be sure to use the latest version of the SQL Azure Migration Wizard from CodePlex at http://sqlazuremw.codeplex.com/. SQL Server tooling in Visual Studio The SQL Server tooling in Visual Studio can be used to create and manage a database project comprising a set of T-SQL files for each object in the schema. The project can be imported from a database or from a script file. Once created, the project can be targeted at the latest preview of Azure SQL Database; building the project then validates schema compatibility. Clicking on an error opens the corresponding T-SQL file allowing it to be edited and the error corrected. Once all the errors are fixed the project can be published, either directly to SQL Database to create an empty database or back to (a copy of) the original SQL Server database to update its schema, which allows the database to be deployed with its data using SSMS as above. You must install and use the preview of the SQL Server database tooling for Visual Studio with support for the preview of Azure SQL Database Latest Update V12. Make sure you have Visual Studio 2013 with Update 4 installed first. See this blog post for more details of this preview release and how to install it: http://blogs.msdn.com/b/ssdt/archive/2014/12/18/sql-server-database-tooling-preview-release-for-the-latest-azure-sql-database-update-v12-preview.aspx. You can keep track of updates to this software on the team blog at http://blogs.msdn.com/b/ssdt/.