Recent Posts
Using CloudSwitch to Create a Public IP Gateway to the Cloud
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Pavan Pant
We recently talked about the latest release of CloudSwitch Enterprise and since that blog post went live we have garnered a lot of interest in our public IP gateway to the cloud - the ability to provide secure access from the public Internet to servers in the cloud. There are many cases in which customers want to deploy Internet facing applications to the cloud to help reduce bandwidth constraints within their data centers and improve performance by moving compute resources closer to their customers. In order to accomplish this, customers needed a firewall in the cloud to ensure secure Internet access to their servers in the cloud which is exactly what CloudSwitch delivered.
As Director of Product Management at CloudSwitch I have had the pleasure of speaking to our customers to understand their use cases and have found that they are talking about things beyond just the migration of servers to the cloud. Customers have started thinking about adding servers to the cloud in a scalable fashion to handle surges in traffic and have frequently requested public connectivity to their servers in the cloud via a firewall. This shows a broadening of the use cases and growing adoption of the cloud. Given that our most popular feature so far is related to our public IP feature I thought it would be useful to dive into some use cases and how our firewall in the cloud can be configured to meet those use cases.
Use Cases
Use Case 1: Hosting Infrastructure in the Cloud
One of our customers was seeing heavy traffic spikes during major holidays and marketing campaigns. Rather than provision new equipment or rent more space in its colo – both expensive options – this company now leverages the cloud and CloudSwitch to handle peak overflow traffic easily, giving website visitors secure, public connectivity to cloud resources through public IP addresses, while managing these same resources through CloudSwitch’s secure data center connections. With the public IP gateway in the cloud our customers can now securely host a multi-tier application in the cloud.
Other things we have heard about include the ability to use the cloud for peak capacity for surges in traffic when the market opens and closes. The idea is to use a firewall for public connectivity to the cloud and a load balancer to have overflow traffic automatically routed to the appropriate server in the cloud.
Consider a scenario where you have two front-end web servers in the cloud, Sharepoint 2007 server, a SugarCRM server, and database servers running SQL 2008. These servers have been migrated to the cloud using CloudSwitch which means that they have the same IP addresses as they did in the data center. This diagram shows how CloudSwitch can deploy a colo-type footprint in the cloud by host a multi-tiered application in a secure fashion with public connectivity.
Once you have your servers in the cloud, the next step in allowing public connectivity to the cloud is to move our SmoothWall firewall (in the “Network Library” folder) to the cloud. Our network library only has one firewall at the moment but we intend to add many more network related infrastructure components in the near future.
You will notice that the new public IP access feature has one interface (red interface) that is assigned a public address while another interface (green interface) can be placed on the network LAN for your servers in the cloud. Once you have moved this firewall to the cloud and started it there it connects to the Internet through the red interface and acquires a public IP address (eg: Amazon Elastic IP). It then connects to your data center through the green interface on the same subnet as the CSA. The public IP address is reserved in Amazon for as long as this appliance is in CloudSwitch – the IP address is released when you delete the appliance in CloudSwitch. This means that you can power off the appliance and still keep the IP address. All this can be configured by opening a console window through CloudSwitch:
Once you have the firewall in the cloud configured, you can create firewall rules in SmoothWall to determine what type of traffic from the public Internet should be sent to your servers in the cloud.
In addition to this, you can also configure the firewall to send traffic to specific subnets or exclude traffic from going to specific servers on a subnet. Once these firewall rules have been configured you will be leveraging a cloud provider’s bandwidth for public connectivity and have the flexibility to increase your footprint in the cloud instead of being limited by a traditional data center footprint.
Use Case 2: Remote Office Scenario
Another use case we hear about is related to getting remote users access to shared resource pools in the cloud. Instead of having remote users go through a VPN server in the data center and then out to the cloud, customers would like to conserve bandwidth by providing them with direct access to cloud resources via a secure, layer 3 tunnel.
This is also a scenario that is possible via CloudSwitch’s firewall in the cloud. It is possible for SmoothWall to inter-operate with any VPN product that supports IPSec and standard encryption techniques such as 3DES. As a result of this, customers can now have their employees accessing their servers in the cloud from a remote office over a secure layer 3 tunnel.
Full Feature Set for Firewall in the Cloud
Unlike the simplistic firewalls provided by cloud providers our SmoothWall firewall has some useful features that CloudSwitch allows customers to leverage in the cloud. It is probably worthwhile to go through some of these:
1. Timed Access
CloudSwitch’s firewall in the cloud has the ability to create firewall rules that allow or disallow access at certain times of the day, for a specified group of servers in the cloud. The timed access controls are only performed on the listed machines. Customers can enter one IP address or network with netmasks per line in the supplied text box. e.g. 192.168.168.0/24 will block/allow the entire range of 192.168.168.0 through 192.168.168.255; alternatively it can be entered 192.168.168.0/255.255.255.0
2. QoS
SmoothWall is able to decide if some of the network traffic is more urgent than others. Imagine your network connection is like a multilane freeway or motorway and allocate specific bandwidth to specific servers.
3. Logging
Logging for CloudSwitch’s firewall in the cloud includes reports of who was trying to do what. Much like any standard log viewer, customers can select the date they are interested in viewing using the drop-down boxes at the top of the page. The body of the page displaying the log files is made up of a table of packets that were dropped by the firewall. Included here are the Source and Destination IP addresses and ports, as well as the protocol involved.
4. IP Block Configuration
This page enables the administrator to selectively block external IP addresses from accessing the SmoothWall and any machines behind it.
5. Dynamic DNS
If our customers have a connection with dynamic IP, the dynamic DNS section of SmoothWall allows you to use dynamic DNS service provided by dyndns.org, no-ip.com, hn.org, dhs.org and/or dyns.cx. These services allow people without a static IP address to have a subdomain name pointing to their computer, allowing them to run services like a web server, VNC, etc.
The first step for using dynamic DNS with SmoothWall is, of course, to subscribe to this free service with one of the supported providers. Once this is done, you just have to fill in the following configuration information on SmoothWall's dynamic DNS configuration page.
While all these capabilities are great it does beg the question of why customers would not just use firewalls provided by Amazon or Terremark? As mentioned earlier, cloud providers typically only have firewalls with simplistic rule sets. Customers do not need to be constrained by a cloud provider’s firewall anymore – with CloudSwitch they now have the ability to define a rich set of firewall rules, services and policies that controls public internet access to their servers in the cloud.
I hope that the use cases and feature set outlined in this blog post helps customers grasp the details of what it takes to provide secure, public connectivity to resources in the cloud.
We recognize that security is of paramount importance in the cloud especially when it comes to allowing users to access servers through the public internet. Our goal at CloudSwitch has always been to provide customers with a secure, simple way to leverage the cloud. Stay tuned for more exciting new enhancements as we continue to make it easier for customers to take advantage of the cloud.
"Cloud in a Box" Gets Boxed In
By John Considine
Just a week after our blog post on the telcos, we find another big company joining the cloud computing tsunami – Oracle’s announcement of its “cloud in a box” offering as well as new offerings of Oracle software running on Amazon’s EC2.
For a company whose leader shunned the term “cloud” last year, this is a lot of cloud announcements in one week. Oracle’s new Exalogic Elastic Cloud is perhaps the first 
“cloud in a box” solution that is actually delivered in a box (of hardware). Unlike the offerings we have seen from Eucalyptus, Nimbula, Azure, and VMware, the Exalogic product contains the control software as well as the hardware components to make a virtualized resource pool. The other vendors have focused on delivering a software solution that can be combined with the users’ choice of servers, storage, and networking gear to build a cloud.
Oracle, powered by Sun’s server and system technology, has decided to deliver a complete cloud solution that contains up to 360 CPU cores, 2.8TB of RAM, and 40TB of storage in a single rack of equipment. This big box is reportedly priced at just over $1M. Oracle’s motivation for this box is to deliver on the promise of building an entire stack of both hardware and software that has been engineered to work together to deliver better performance, reliability, and scale. Overall, the Exalogic system has impressive performance characteristics and may be a great solution for data center consolidation, but…
Placing the term “Elastic” in the name of this offering is stretching the accepted definition of the term as it relates to cloud computing. The Exalogic server is a contained set of resources that is purchased, operated, and maintained as part of the enterprise infrastructure. You can scale your applications up and down within this solution, but in the end, you are limited to the number of cores, amount or RAM, and size of the storage you purchased. While you can add more racks to the solution, you are stuck paying for the whole thing independent from what you really use – not exactly elastic or pay for only what you use. My only other problem with Exalogic is the range of supported operating systems – we like the Linux and Solaris support, but a quote from Rick Schultz of Oracle – “There is no demand for Windows at the moment” – makes me wonder who they are talking to. More than half the enterprise workloads CloudSwitch has deployed to the cloud are Windows-based; how can there be no demand for Windows in Exalogic?
The other interesting difference in the Exalogic solution as compared to the big (public) cloud offerings is the design center for the hardware. Clouds like Amazon and Google were developed around “stripped down” servers to act as generic compute components. The redundant components normally used to improve the reliability of a server are removed from the compute nodes to reduce the component cost, and software and other application-level techniques are used to make up for the fail-able components. Each of the servers in the Exalogic solution has redundant power supplies, 2 solid state disk drives, and redundant Infiniband controllers. This more expensive hardware allows the system to survive component failures with minimal disruption to the running applications – a traditional enterprise infrastructure design, with high reliability to support a lot of VM’s packed on a single piece of hardware.
The difference between the two approaches highlights the upcoming battle between architectures in the cloud – stripped down commodity servers versus highly available high-end servers as the basis for cloud computing. The early leader in this space is the commodity server approach because of the types of applications initially targeted to clouds – stateless horizontally scalable web applications. But as we start putting more core enterprise applications into the cloud, the HA architectures become more interesting, and thus we expect this architecture to gain ground. We see these architectures gaining ground already with clouds like Terremark, BlueLock, and Savvis.
The other announcement this week from Oracle is expanded support for running Oracle software in Amazon’s Elastic Compute Cloud. Oracle has provided templates (AMI’s) in Amazon for its database software since 2008, and this week they have expanded the number of applications they will support in Amazon to include Oracle E-Business Suite, Oracle's PeopleSoft Enterprise, Oracle's Siebel CRM, Oracle Fusion Middleware, Oracle Database, and Oracle Linux. In addition to expanding the software supported on AWS, Oracle has taken the step of “certifying” the software for operation in Amazon. This means that customers can now get support from both Oracle and AWS for those applications. Although Oracle’s lead cloud story seems to be about the Exalogic box, I believe that this announcement does more to advance cloud computing for enterprises. Support for these key Oracle products in Amazon’s cloud adds credibility to public cloud computing, as it allows enterprises to really use the cloud for their core applications. This is one of the areas that a cloud provider cannot fix, it is up to the software vendors to expand their horizons to embrace the cloud and Oracle is blazing the trail.
I think the only downside to the Oracle-Amazon announcement is the lack of integration with Oracle’s control software. The FAQ’s from Amazon and Oracle emphatically state that the management controls for Oracle deployments to the cloud is exclusively the Amazon console and tool set. This is a shame since we believe that seamless integration between the data center and the cloud is key to a successful enterprise cloud deployment; creating a disjointed environment just adds work with no value for the enterprise and ultimately leads to cloud lock-in. Our enterprise customers have told us consistently that they want a “single pane of glass” from which they can manage pools of resources both internal and external.
Finally, while I like the architecture of the Exalogic Elastic Cloud, and believe that it could form the basis of a new class of cloud computing offerings, it too may be missing a critical point. If an enterprise decides to deploy their private cloud on this technology, there is no connection or relationship between the applications deployed to the private cloud and those running in the public cloud. This, once again, highlights the importance of cloud federation – you will never break the cycle of buying more hardware and infrastructure if you don’t embrace technology that allows you to access the public clouds.
Where Are the Telcos?
By Ellen Rubin
This week’s Verizon announcement about their new CaaS offering for SMBs highlights a strange situation in the cloud computing market. While Amazon has been growing explosively and MSP/colo providers like Rackspace, Terremark and Savvis have rushed to embrace cloud in their business models, the telcos have been slow to enter the fray.
Telcos in many ways seem like the most likely players to lead and ultimately win in the land-grab of cloud computing. They’ve got the huge scale, geographic coverage, existing enterprise relationships and experience in service delivery that would appear to give them unfair advantage. As noted in the Verizon announcement and some recent blogs, telcos have a “unique opportunity to position cloud computing as an extension of their managed networking solutions (such as MPLS-based VPNs), by offering ‘on-net’ cloud computing capabilities backed up by end-to-end service-level agreements (SLAs).” In fact, the networking infrastructure and ability to offer dedicated and secure access is one of the telcos’ greatest strengths since it addresses some of the key concerns about cloud security and bandwidth.
So it’s worth considering why the telcos aren’t yet a dominant force in the industry. To a certain extent, it’s taken a couple of years for them to perceive the threat of Amazon et al to their core businesses. The response has been primarily a defensive one, as noted by IDC’s Melanie Posey: “Right now they’re concerned with, ‘If our existing customers want cloud in addition to the traditional hosting we’re offering them, we have to have something too or they’ll take that incremental business to somebody else.’” Marketing announcements and pricing model changes have so far been the fastest and lowest-cost response to this threat. For example, some telcos are now offering per-month pricing instead of the traditional annual or multi-year structures.
In parallel, the telcos are doing the heavy lifting required to build new cloud services. A lot of the real spending so far in the cloud market is being done by these players: buying new gear from the server, storage and networking vendors; installing new software and management tools from the hypervisor and service management players; designing new architectures with the help of consulting firms; leveraging existing infrastructures from Terremark, OpSource and others, etc. This all takes significant time and money.
While this investment is taking place, there’s relatively little to see in terms of live customer deployments. But in the meantime, the first-mover cloud providers and customer early adopters are moving full-speed to test and improve their offerings and cloud footprints. They’re shaping and defining cloud requirements and best practices based on real-life customer engagements. The risk for the telcos in being late to the party is that they’re not getting the customer insights first-hand and are missing the direct experience needed for successful scale-out and service delivery. Without this, they could end up delivering too little, too late. Still, given the size and projected growth of the cloud market opportunity, there’s no doubt it would be a mistake to count the telcos out.
CloudSwitch Enables True Cloud Federation
By Pavan Pant
As with any transformative technology that is new to the market, both public and private clouds have generated massive amounts of hype, bold predictions, a whole lot of confusion and raging debates amongst the cloud cognoscenti. Opinions vary across the spectrum with some experts claiming that data centers will be rendered obsolete by the public cloud, while others are dismissive of the public cloud but support private clouds. It’s clear to us at CloudSwitch that a more likely scenario lies squarely in the middle of those two extremes. This week at VMworld (where we were exhibiting with our partner, Terremark), we were pleased to hear that VMware believes that “hybrid cloud is the tide coming in.” From Paul Maritz’s keynote through many sessions and product announcements (including the release of the long-awaited vCloud Director), the message was all about hybrid clouds.
One of our previous blog posts discussed the notion of hybrid clouds and the fact that most enterprises will follow such an approach in the future. Amazon, Terremark, Rackspace, Savvis, Blue Lock and other public cloud providers give customers elasticity, better service delivery and low CapEx costs. Meanwhile, there are solutions such as Eucalyptus and VMware’s vCloud Director that provide the interface and management tools to help organizations build private clouds while interfacing with public clouds to create hybrid cloud models.
Both use different APIs for their hybrid models with Eucalyptus delivering tight integrations for EC2 using Amazon’s APIs and VMware vCloud Director working with vCloud DataCenter Services (VMware’s terminology for public cloud providers) such as Terremark that leverage vCloud APIs. However, these technologies do not assist with creating an environment that spans hypervisors and cloud providers without changing the applications. If customers build private clouds that are not using the same virtualization infrastructure as their preferred public clouds then what does it really mean to hybridize their clouds?
Consider a scenario where a customer builds a private cloud using Eucalyptus or VMware vCloud Director. That private cloud still ends up being different from your data center (much like a public cloud) - the networking may be different, versions of virtualization technology may be different and the storage infrastructure may be different. All this means that applications in the data center will need to be changed before moving to the private cloud. As an example, if your QA team runs servers on their own subnet in the data center how can this be transitioned to a private or public cloud without incurring additional costs to change those servers?
CloudSwitch’s core value proposition lies in the ability to securely transport a customer’s existing virtual infrastructure to the cloud provider of their choice, independent of the provider’s underlying virtualization infrastructure (VMware, Xen, etc.). This effectively allows customers to securely move and operate servers from their data center across hypervisors to private cloud providers without requiring them to make any modifications to their application – we maintain the same IP address, MAC address, storage controllers, subnet information, etc. Once customers have moved their servers to the cloud they can operate and manage them just as they would in their data center. CloudSwitch has an intuitive web based interface which gives customers server lifecycle management options such as start, stop and clone.
Similarly, if customers have a private cloud which uses either Eucalyptus or VMware vCloud Director CloudSwitch can speak to those APIs and facilitate the transfer and management from these private clouds to public clouds. This enables a hybrid model where private clouds leverage public clouds for spikes in usage (cloudburst), or lab-on-demand use cases for training and POCs. CloudSwitch does all the work of integrating the environments across these private and public cloud hypervisors, merging networks and transferring servers without modifying them in any way.
Many years ago, I had the privilege to work on the first iterations of RSA’s identity federation product both as an engineer and as a product manager. Federated single sign on enabled the portability of identities across security domains and allowed for the secure exchange of sensitive data outside the firewall without requiring any changes to the identity itself.
While the markets for Identity Management and cloud computing are unambiguously different, the notion of federation to make portability and interoperability easier for enterprises is a common theme. CloudSwitch is in a unique position to help enterprises with true cloud federation by moving workloads seamlessly from the data center to the cloud (private or public), between private and public clouds (hybrid), across public clouds and back to the data center without requiring customers to make any changes to their applications. Regardless of the starting point, CloudSwitch offers customers an easy, effective method to leverage the benefits of the cloud while ensuring portability across clouds.
