cloud networking
Get off the Bus - Explore the Cloud TODAY!
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy George Moberly
A year ago I attended a session at Cloud Expo in New York. The presenting company told the audience that “cloud exploration services” were now available. Enterprises could purchase these packaged services to discuss, probably at length, how to identify candidate applications for cloud usage.
I’ve been there and done that – as a former professional services manager for such a “Big 4” data center automation company, I’ve participated in many such “school bus” campaigns. Often the end result is that everything is said, and little gets done.
According to this philosophy, you can’t just go out and try the cloud for yourself – instead, professional services are needed, and plenty of them. After the expenditure of months of time and large sums of money, you might be lucky enough to get a report of some applications that would be suitable to move – to their specific cloud.
While this approach well serves the interest of the vendor, there is a better way.
The premise of the cloud is that there is almost no penalty for trying something and failing. Move some applications and try them out. You didn’t get the SLA or characteristics you were looking for? You’re only out a buck or two.
Of course the premise I’m making is that you don’t have to change anything in your services, applications, networking, or infrastructure to give this a try. I make the further premise that the cloud enablement software doesn’t require a services engagement to acquire, install, set up and configure, and manage operationally over time. This week, we made CloudSwitch available. Give it a try. You can acquire, install, configure, move and run your applications today. No services required. You point us to your virtual machines, our software will automatically show you if they fit in the cloud, and after we’ve transferred them to the cloud, they will look and feel just like they do now, running in your on premise virtualized infrastructure. No engineering. No changes. No agents. No “additions” to your servers. No funny installers.
All this said, there are physics involved. I recommend a simple process that will result in immediate positive results in selecting candidate applications to move and run in the cloud, as well as in the confidence that comes from a “real test” involving complex multi-tier applications which are tied to both premise-naming services and other network services that cannot be moved out of your data center.
For a first application, I suggest finding something that has servers with relatively small disks. Moving disks over the internet can take time. Some ideas include an internal project server running a program management application, Wiki, or SharePoint. Or perhaps a development environment for a JBOSS application, or anything else based on an open source stack. Move and run this, and run the same load testing or characterization/acceptance tests you use today, and see how they perform.
For a second application, I suggest taking the web and application tiers of the three-tier application and moving them, leaving the data tier on-premise. Leave your management agents on those servers, and leave them joined to the same domain if they are Windows servers, or using the same naming services. Don’t be concerned if the servers have NFS or CIFS mounts to on-premise NAS storage.
For a more in-depth test, go ahead and move development environments for applications such as PeopleSoft, Siebel, or SAP into the cloud and develop your applications there. Extra desktops for developers make a good initial application to move, as do development support servers such as continuous build, defect tracking, and source code repositories.
Our focus on providing a zero-friction, packaged appliance-based product makes this possible. Our automatic CloudFit process will tell you up front if your application will fit and run successfully in the cloud prior to incurring any cloud spend, and how much it will cost per hour to run.
Sign up for our Beta and move and run your first application in the cloud TODAY! School bus not included.
Moving to the Cloud: Key Considerations for Cloud Networking
This post is part of a series examining the issues involved when moving applications between internal data centers and public clouds.
Every enterprise has a unique network infrastructure for accessing servers and allowing applications to communicate between components. Various layers support the management of network addressing, deliver critical services, and ensure security. The infrastructure includes specific addressing (sub-nets), address services like DHCP/DNS, identity and directory services like LDAP, and firewalls and routing rules – all reflecting the specific requirements and evolution of the given enterprise.
Clouds are not different from the enterprise in this respect; they have unique networking infrastructures that support complex and flexible multi-tenant environments. Remember that the cloud providers have to control their networking so that they can route traffic within their infrastructure. More important, their design is completely different from your enterprise networking architecture, design, and addressing. This is not a problem if you’re doing something stand-alone in the cloud because you don’t care what the network structure is as long as you can access it over the internet. However, if you want to extend your existing networks and use your existing applications, there are serious discontinuities that have to be addressed.
First, you have to deal with addressing. The typical cloud provider will assign you a block of addresses as part of your cloud account. For example, Flexiscale and GoGrid essentially give you get a block of assigned addresses that you can attach to the servers you create. In some cases these are external addresses (meaning that they are public addresses that can be accessed from the internet), while in others, they are internal. In either case, they are not assigned as part of your addressing. This means that even if you manage to connect these resources to your data center, you need to build new routes and alter your services to allow these “foreign” addresses into your system. Amazon originally took a different approach by providing a dynamic system where an address is assigned every time a server is started. This made it hard to build multi-tier applications, requiring developers to design systems able to pass changing address information between application components. The new VPC offering partially solves this problem for connecting to the Amazon cloud, although some key challenges remain. Other cloud providers are investigating similar networking capabilities.
The next major issue with networking in the cloud is data protection. In your data center, there is a secure perimeter defined and developed by your IT organization that is comprised of firewalls, rules, and systems to create a protected environment for your internal applications. This is important because most applications need to communicate over ports and services that are not well protected and certainly not safe for general internet access. Since applications are developed for the protected environment of the data center, it can be dangerous to move them unmodified into the cloud. Under normal circumstances, the application owner or developer has to build protection on a per-server basis and enact corporate protection policies.
The loss of control of the infrastructure mentioned earlier has additional implications – in most clouds you can’t control the physical interface level. That is, in addition to assigned IP addresses, you get MAC addresses assigned to you as well. These addresses can change every time a server is started which means that the identity of the server (and associated IP addresses) cannot be based on this familiar attribute.
All of these networking issues are at play whenever enterprise applications require the support of your data center infrastructure – things like identity services, naming services, and access to internal databases and other resources. Because of this, your cloud resources need a way to connect to your data center, of which the easiest approach is a VPN. In building this solution, you need to design for routing to the cloud and provide a method for cloud applications to “reach back” to the applications and services running in your data center. Ideally, this connection would allow Layer-2 connectivity because a number of services require this level to function properly.
To wrap up this segment, networking, like storage, is a very important part of your IT infrastructure, and the cloud adds a number of interesting new variables to the design and operation of your data center environment. What’s needed is a well-constructed architecture and a good understanding of the limitations imposed by the cloud if you want to integrate successfully with the public clouds. Today, this can be a major barrier to cloud adoption since enterprises are understandably reluctant to re-architect their network environments or become knowledgeable about the complexities of each cloud provider’s underlying infrastructure. When designing your cloud strategy, make sure to select a migration path that addresses these issues and protects you from costly engineering projects and cloud risks.
Next: Key Considerations for Cloud Management
