A few years ago, the Microsoft SQL Server product team introduced a new cloud Platform-as-a-Service (PaaS), Azure SQL Database, which shares the SQL Server code base. Running a cloud-first service required significant changes to the legacy SQL Server engineering model which took years of investment in order to fully enable. With these engineering model changes came big benefits which positively impacted both Azure SQL Database and SQL Server.
Even if you are a SQL Server database administrator who isn’t using Azure SQL Database today, you’ll still be seeing benefits from Microsoft’s investments in the cloud. This blog post will review how engineering model transformations, driven by cloud requirements, resulted in several improvements in how we build, ship and service SQL Server.
Features arrive faster
In the earlier days of SQL Server (2005 through 2012), SQL Server had roughly three-year long engineering cycles. For each planned release of SQL Server, a significant amount of planning would go into the up-front design, using a waterfall-like software development process coordinated across different teams. This included the generation of functional specification documentation by program managers, design specifications by developers and automated testing code developed by testers.
Once SQL Server finally shipped, customers could take years to upgrade or adopt the associated new features. With this legacy engineering model and the extended periods between the original planning and actual customer adoption, it would take years overall to understand if the feature “landed” properly and met the needs of the originally intended scenario. For any new feature being discussed, the SQL Server engineering team had to think several years ahead of the market.
The development of a Platform-as-a-Service, Azure SQL Database, shifted the SQL Server engineering team’s focus into working within significantly shorter time frames. The SQL Server engineering team made a few key changes in order to make this happen:
• The build and test loop for SQL Server was automated using thousands of machines to run tests in parallel. Tests are run all the time. This took the build and test process from weeks in the legacy engineering model to hours for the average case in the new model.
• The SQL Server engineering team realized that the original SQL Server code surface area was very large and thus difficult to deploy in its monolithic state. Therefore, the team looked for ways to break apart the architecture into overall smaller micro-services wherever possible. This change in architecture allowed separate deployments and servicing for each component.
• Features are now required to be built more incrementally and delivered via monthly Community Technical Previews (CTPs).
These changes allowed us to shorten the release cycle and get features to Azure SQL Database and SQL Server faster than ever before. Most recently, the SQL Server engineering team managed to ship SQL Server 2017 along with new cross-platform support only 15 months after the release of SQL Server 2016. Contrast this with the legacy three to five-year SQL Server shipping cycles of the past.
