SQL团队的抉择。这是一段有趣的话题，当微软的数据库团队面临要将SQL服务器放在云端的时候，也碰到了跟上述话题同样的问题，是应该以提供各式服务接口让用户容易的存取，靠着强大好用的服务接口彻底的将SQL服务器隐藏起来?还是拿掉这个便利存取的抽象层，让SQL服务器直接面对外部的程序接口呢?

　　最后的结果是，微软选择了让SQL服务器直接面对外部的程序接口，也就是让程序能够运用T-SQL直接对数据库作存取的动作。
 

　　SQL Azure开发团队使得SQL服务器直接面对程序开发人员，能够在客户者端的程序中运用传统的TDS(Tabular Data Stream)与位在云端的SQL服务器沟通，但基于安全与横向扩展服务器数量的考虑，特别在中间设计了一层Gateway层，如图2所示的Security Boundary 所指的就是Gateway层。

　　如图2所示，我们隐约可以看出SQL Azure分成了好几个层次，如果再参考图3一起来看的话，就看得出来它实际上能够分成四层，最下面是基础架构(Infrastructure)这是架构底层的服务程序它掺杂着软硬件的I/O配合，也就是处理大量CPU群组的地方，它负责横向的多重架构作业(Fabric)、故障移除(Failover)、复制(Replication)及负载均衡(Load Balancing)，当然还包含软件版本的自动更新维护(它也负责实时侦查软件或是硬件所产生的异常现象并能自动采取相对的措施)等作业，这是一般云端架构的基础层。对于云端应用程序而言，它提供一些自我管理的机制，目前仍然相当神秘并没有对外开放，不过一些基本的API将会在近期内公开出来。

 
图3 SQL Azure架构

　　SQL Server层是以SQL 2008为基础上，修改成适合云端作业的数据库层，所谓的“云端工作”指的是高可适用性(High Availability)及快速复制等配合功能。它可以接受传统的Transact-SQL(T-SQL)指令，但从网络端传送过来的资料并不会直接进到SQL服务器内，而是透过更高一层的Gateway层传入。

　　Gateway层的较完整名称应该是TDS Gateway，当程序进行SQL Azure联机时，实际上是联机到Gateway层，在这里进行防火墙及安全验证的安全性的计划后，联机才会真正进入到SQL服务器内，真正进行联机的建立(所有的恶意攻击、或非法的Login企图都依靠Gateway层来做阻挡过滤)。但一旦通过Gateway建立联机之后，就会由另一个通用管道负责后续的传送作业，这样做的目的则是为了减少通信上不必要的耽搁作业。

　　另外，网络的再因特网的入口处，图中在云的下方写着LB的方块，是整个SQL Azure中唯一面对因特网的部分，也就是程序唯一可以看得懂URL地址的部分，在网下就Gateway中存有的相对地址，它负责均衡分配进入点到各个Gateway层。如果你的程序是由Windows Azure呼叫进来的话，也是依循这个相同的端点来进入的。如图2所示，最上方则是你的应用程序，当然你可以采用SQL client Libraries，或是ADO.NET Data Service或是其他更高阶的程序语言来做开发，例如PHP等程序语言。这是由于开发团队决定采用传统的TDS(Tabular Data Stream)作中间的传输协议，造成使用这可以运用许多原有的或是标准的公具来做连线工作，甚至是侦错或监看的动作。

　　SQL Azure选择以传统的TDS为传输协议，而不是将SQL Server使用了一大堆的服务包装起来，让程序设计师十分容易延续对SQL SERVER的开发功能，这算是微软成功的第一步，当然SQL Azure为了适合云端的环境，也拿掉了一些不适合的功能，包括安全性、绝对路径等API功能，参考图2的上半部可以看出，ODBC及ADO.NET是标准的入口，因此，原本在ASP.NET端的大部分功能都能顺利的运用在这里，使得Windows Azure能够成为真正执行云端运算(Cloud Computing)的关系数据库服务，这是一种云端储存(Cloud Storage)的实作，成功的提供网络型的应用程序数据储存的服务，让许多既有的程序只要少许的修改就能存取云端数据资源。

　　facade设计模式可以将杂乱或设计不好的应用程序编程接口(API)再加上一层，把它包起来并提供一个容易看懂的新接口。简单的接口可以让复杂庞大的程序接口隐藏起来。模式与SQL Azure的共同关系既是“目的相同”，也就是考虑到提供使用者一个易读易写的应用程序编程接口，这样使得微软从数据库平台架构演变中，获得更合理的设计抉择。