Government 2013

Volume 28 Number 10A

Azure Insider - Choosing a Cloud Network for Government-Compliant Applications

By Bruno Terkaly, Ricardo Villalobos | Government 2013

Cloud Deployment Models

It’s important to differentiate the cloud deployment models that government agencies around the world are following, because they determine how compute resources are provisioned, managed and consumed. There are basically two: public and private clouds. Microsoft defines the public cloud as a pool of compute and data resources that can be shared among multiple users, offering a pay-per-use economic model that clearly differentiates from the traditional purchase-in-advance approach to servers and storage mechanisms. Individual developers, companies, and organizations can self-provision IT infrastructure around the world by following simple steps, based on different usage patterns that usually present high variations in traffic or required compute power. Private clouds, on the other hand, are operated solely for one organization, may be managed by a third party, and are traditionally hosted either on-premises or isolated from other tenants in datacenters, providing a higher level of control and flexibility, but also requiring more maintenance and up-front investment.

According to the inaugural IDC Government Insights Report, “Perspective: Growth and Slight Contraction – Government Cloud Spending by U.S. Federal Agency,” released July 15, 2013, spending on public clouds for government agencies is currently only about 10 percent of that for private cloud solutions, mostly because of security, privacy and compliance concerns. As a reference, federal private cloud services spending in the United States will reach $1.7 billion during FY2014, with an expectation it will reach $7.7 billion by FY2017. We believe the factors that motivate the adoption of private over public clouds will dissipate over time, as cloud vendors prove their efficacy in terms of privacy and data protection. It’s a familiar trend in technology—trust takes time, despite the fact that government servers are frequently compromised by hackers.

Microsoft is committed to providing Windows Azure customers with detailed information about its security compliance programs to help them make their own regulatory assessments. Among the certifications that Windows Azure has obtained are the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 27001:2005, the Statements on Standards for Attestation Engagement (SSAE) 16/International Standard on Assurance Engagements (ISAE) 3402 Attestation, and the Health Insurance Portability and Accountability Act (HIPAA) Business Associate Agreement (BAA). More information about security, privacy and compliance for Windows Azure can be found at the online trust center, windowsazure.com/trustcenter.

Other factors that will accelerate the adoption of the public cloud by government organizations are the available tools and infrastructure that enable the deployment of hybrid architectures (public and private), particularly for scenarios where some of the data resides on-premises, such as secured locations owned by government agencies. Windows Azure offers four ways today to enable these situations, as shown in Figure 1.

Figure 1 Cross-Premises Connectivity Using Windows Azure

The first option, data synchronization, is directly related to solutions using Microsoft SQL Server as a service in the cloud (known as Windows Azure SQL Database), which can be synchronized with both on-premises or private databases for backup or replication purposes. To synchronize the data, sync groups—which define the databases, tables and columns—are created to specify synchronization schedules. Each sync group must have at least one SQL database instance that serves as the sync group hub in a hub-and-spoke topology. This is an easy way to maintain relational information deployed in multiple locations, either public or private.

The second option is the use of the Windows Azure Service Bus, which supports the implementation of messaging patterns to securely exchange information between distributed components of the solution. These endpoints are usually machines located in remote locations (behind private firewalls) or mobile personal devices. Different patterns are supported, including queues where receivers compete for a single message, or a publisher-subscriber model, where messages are sent to topics that distribute information to multiple receivers. More information and specific implementations of the Windows Azure Service Bus can be found in our December 2012 Windows Azure Insider column, “Windows Azure Service Bus: Messaging Patterns Using Sessions” (msdn.microsoft.com/magazine/jj863132).

The third and fourth options are based on a recent commercially released component, the Windows Azure Virtual Network, which offers two types of cross-premises VPN connections: site-to-site and point-to-site. A site-to-site VPN creates a secure connection between private facilities—such as a government-owned building—and resources in the cloud. Once the VPN connection is created, resources at both ends can communicate directly and securely, as shown in Figure 2. However, there’s an extra requirement: the government office must provide an externally facing IPv4 IP address on a VPN device. The beauty of this site-to-site configuration is that it isn’t necessary to individually configure each client computer that wants to be part of the VPN. Moreover, Cisco Systems Inc. has released a VPN device called the ASA Model 5505 for less than $300 that has the functionality of devices that often cost more than $1,000. Leveraging the Windows Azure Virtual Network service makes it a simple four-step process to create a VPN. This amazing combination of technologies has really democratized VPNs.

Figure 2 Using Windows Azure Virtual Network VPN Functionality to Connect On-Premises Resources

The point-to-site approach, in contrast, requires IT staff to individually configure each client computer, but with the benefit that no VPN device is needed. Instead, a VPN software client is installed on the individual computers. This makes sense for specific scenarios, but IT departments are not particularly fond of this solution because it requires more maintenance in the long term.

The Windows Azure portal makes it trivial to establish a VPN. Naturally, there’s some homework to be done before the Windows Azure portal can be used. You need to know the details of your network and define subnets for the different machines that will be connecting to it. Once the requisite information is defined and collected, you can set up the VPN via the Windows Azure portal or by using Windows PowerShell/command-line interface (CLI) scripts.

Here’s what you need to know before using the Windows Azure portal:

• The location of the datacenter where the VPN service will be hosted.
• The name and IP address of the on-premises or cloud-based DNS server.
• The IP address of the government, on-premises VPN device.
• The various on-premises subnets that are in place.

The following steps, also shown in Figure 3, outline the basic process:

1. From the Windows Azure portal select Networks | Create a virtual network.
2. Provide the name and region where you want to host your VPN service. This step also includes potential affinity groups you might want to use.
3. Enter the name and IP address of your on-premises or cloud DNS server.
4. Specify the IP address of your VPN device (that is, the IP address of the Cisco VPN device, for example), as well as the address space of the on-premises network, including the address count. The usable address range is then calculated and displayed.
5. Add the necessary subnets pertaining to your on-premises network.

Figure 3 Creating a VPN

After creating your Windows Azure Virtual Network, you can use the detailed, step-by-step directions described at msdn.microsoft.com/library/azure/dn133795.aspx to configure the virtual network gateway in order to create your site-to-site VPN. There will be VPN device-specific configuration scripts you’ll need to get from the Windows Azure portal to simplify administration. You’ll also need to indicate a gateway IP address and a shared key.

Cloud Service Models

Another way of differentiating the cloud is by service model: Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS). The models simply define how much of the technology stack is delegated to the public cloud vendor (see Figure 4).

Figure 4 Cloud Service Models

In the SaaS model, the consumer simply accesses an application hosted in the cloud through a Web browser or thin client, as is the case with social networks such as Facebook and Twitter, productivity tools such as Office 365 and communication/collaboration hubs such as outlook.com. The PaaS model is used mostly by developers, who can provision compute resources in the cloud using different programming languages and tools provided by the cloud vendor. Finally, IaaS allows IT pros to deploy, manage, and control fundamental computing resources such as virtual machines (VMs) and networks. IaaS requires more maintenance time and planning, but it yields more flexibility and control over the lower layers of the technology stack.

Typically, government agencies are more comfortable with the IaaS model due to the level of control it provides. According to the IDC Government Insights report mentioned earlier, between now and 2017, IaaS spending will grow to $5.4 billion, SaaS will grow to $2.4 billion, and PaaS will grow to $1.1 billion for U.S. government agencies.

One of the features of the Windows Azure Virtual Network is that, in addition to the combination of public and private cloud deployments, it allows the combining of multiple service models, resulting in rich architectures that can take advantage of different platforms without compromising control or flexibility. As an example, Web portals can be deployed using the cloud services (PaaS) component of Windows Azure, while the database engine (which might require customized settings or configuration) is deployed to a VM (IaaS), keeping the communication between them exclusively and securely internal to the datacenter. This means there’s no need to expose endpoints to the Web or to open external endpoints enabling the solution on the Web server to extract, update or remove information from the database (Figure 5). This particular feature, which provides high levels of connectivity without compromising security, is one of the biggest differentiators of the Windows Azure platform compared to other cloud platforms.

Figure 5 Combining PaaS and IaaS Deployments in Windows Azure Using Virtual Networks

The process of provisioning a hybrid service model (IaaS and PaaS) with Windows Azure is similar to the one mentioned earlier for creating VPN connections, requiring the definition of a virtual network, and then the addition of VMs (IaaS) and cloud services (PaaS).

For the PaaS components, the configuration file needs to include information about the virtual network. If you aren’t familiar with the deployment process for PaaS in Windows Azure, you’ll want to read the official documentation and concepts at bit.ly/17YKcym. Figure 6 lists the basic network configuration schema for cloud services.

Figure 6 Network Configuration Schema for Adding Cloud Services to Virtual Networks

<ServiceConfiguration ...>
  <NetworkConfiguration>
  <Dns>
    <DnsServers>
      <DnsServer name="name1" IPAddress="IPAddress1" />
      <DnsServer name="name2" IPAddress="IPAddress2" />
      <DnsServer name="name3" IPAddress="IPAddress3" />
    </DnsServers>
  </Dns>
  <VirtualNetworkSite name="name1"/>
  <AddressAssignments>
    <InstanceAddress roleName="roleName1">
      <Subnets>
        <Subnet name="name1" />
        <Subnet name="name2" />
        <Subnet name="name3" />
      </Subnets>
    </InstanceAddress>
    <InstanceAddress roleName="roleName2">
      <Subnets>
        <Subnet name="name4" />
        <Subnet name="name5" />
        <Subnet name="name6" />
      </Subnets>
    </InstanceAddress>
    <InstanceAddress roleName="roleName3">
      <Subnets>
        <Subnet name="name7" />
        <Subnet name="name8" />
        <Subnet name="name9" />
      </Subnets>
    </InstanceAddress>
    </AddressAssignments>
  </NetworkConfiguration>
</ServiceConfiguration>

You’ll find that many of the virtual network configuration elements we mentioned that need to be defined in advance for VPN connections are also included in the cloud service configuration file schema. Keep in mind that if the cloud service role is already running on Windows Azure, it will need to be redeployed with the new configuration file information before it can be added to the virtual network. Detailed descriptions for each of the schema elements can be found at bit.ly/162xahL.

Adding VMs (IaaS) to virtual networks can be accomplished through the Windows Azure Management Portal, or by using Windows PowerShell or CLI scripts. The process is fully described on the Windows Azure page, “Add a Virtual Machine to a Virtual Network,” at bit.ly/KHUixg. Similar to cloud service roles, VMs already deployed need to be stopped and re-provisioned before they can be added to virtual networks.

Combining PaaS and IaaS models in the same solution allows you to choose the right model for each architecture component. Government agencies using IaaS today as their primary deployment model can start identifying areas that can benefit from PaaS without losing control over specific servers in their architectures. We see PaaS growing in significance as developers learn the advantages of this deployment model—easy scaling, automatic updates and rolling upgrades, among others.

Wrapping Up

Hybrid cloud networks—both from a deployment and service perspective—provide different advantages to government agencies designing solutions that need to follow specific privacy, security and compliance policies. Sensitive compute and storage resources can be kept on-premises or in private clouds, while being securely connected to less-critical components running or stored in public clouds, such as Windows Azure. At the same time, government applications that are based only on IaaS can start taking advantage of other service models such as PaaS, which require less maintenance and support time.

Bruno Terkaly is a developer evangelist for Microsoft. His depth of knowledge comes from years of experience in the field, writing code using a multitude of platforms, languages, frameworks, SDKs, libraries and APIs. He spends time writing code, blogging and giving live presentations on building cloud-based applications, specifically using the Windows Azure platform. You can read his blog at blogs.msdn.com/b/brunoterkaly.

Ricardo Villalobos is a seasoned software architect with more than 15 years of experience designing and creating applications for companies in the supply chain management industry. Holding different technical certifications, as well as a master’s degree in business administration from the University of Dallas, he works as a platform evangelist in the Globally Engaged Partners DPE group for Microsoft. You can read his blog at blog.ricardovillalobos.com.

Terkaly and Villalobos jointly present at large industry conferences. They encourage readers of Windows Azure Insider to contact them for availability. Terkaly can be reached at bterkaly@microsoft.com and Villalobos can be reached at Ricardo.Villalobos@microsoft.com.

Thanks to the following technical expert for reviewing this article: Dennis Velázquez (Microsoft)
Dennis Velázquez (dennisve@microsoft.com) is Director of the Windows Azure CSV team in the Developer Platform Evangelism group at Microsoft. A 12-plus year Microsoft veteran with over 20 years’ experience in the retail, manufacturing and pharmaceuticals industries, Velazquez is a worldwide lead of compliance and information risk assessment with Windows Azure and cloud computing.