Recent Posts
Moving to the Cloud: Key Considerations for Cloud Networking
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedInThis 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
Moving to the Cloud: Key Considerations for Cloud Storage
This post is part of a series examining the issues involved when moving applications between internal data centers and public clouds.
The true challenges in storage and data management in the cloud result from the diverse and often unfamiliar processes and infrastructures offered by the cloud providers, including: new provisioning methods, storage properties, data population and transfer, and systems for data management (snapshots, clones, replication, backup). The cloud providers define the relationship between servers and storage and often impose constraints on everything from allocation size limits to the ways in which storage is managed. These are just some of the things you’ll want to consider as you start to think about integrating cloud computing into your existing IT environments.
I’d like to focus in detail on the complexity and variability of cloud provisioning and storage properties. There are different models for storage in existing compute clouds, with the most common being an “inclusive” storage model. In this model, each server comes with a certain amount of storage attached to it. The storage is a fixed capacity that is provisioned when you create the server from the pre-existing templates.
For example, Rackspace gives you disk space that is proportional to the memory (RAM) size you select. The smallest memory/disk combination is 256MB of memory with 10GB of disk. With each doubling of memory, the disk space is also doubled until you get to roughly 16GB of memory and 640GB of disk. With the new Terremark vCloud Express, you get a system disk that is predefined for each “template” server you select. For a standard Linux distribution, you get a 10GB system disk, for Windows 2K3 you get a 20GB disk and for W2K8, you get a 40GB disk. Terremark’s vCloud Express allows you to add additional storage as new disks, while others (like Rackspace) allow to “resize” your servers and storage to create a new server with a larger disk and copy your data into it.
Amazon offers several distinct types of storage within EC2. The default storage you get with each server you create in the cloud is called “ephemeral” storage. You then have the option of allocating and attaching Elastic Block Storage (EBS), and there is also an object store system called Simple Storage Service (S3). Ephemeral and EBS are standard “block storage” devices – meaning they are viewed and used as disks attached to your server (/dev/sdg in Linux, D: in Windows) while S3 requires an API or other tools to integrate with your systems. The good part about the EC2 storage offerings is that you have some powerful options as you build for the cloud; the hard part is mapping the proper resources to your applications and integrating this with your existing processes. Specifically, the base storage is ephemeral, which means that if you power-off the server, or it has a hard fault, all the data on that storage is lost. This means that everything on these drives (boot parameters, application updates, user data, logs, etc.) is subject to loss when you power off the machine. There are several methods of handling this situation: 1) Build your servers every time you start them from a formula or other sources such that you don’t depend on the base storage being persistent; 2) Use Amazon or third party tool sets to periodically “bundle” your servers into S3 (effectively taking a snapshot of the server); or 3) Attach EBS storage to your image and store your important data on persistent storage.
Turning to granularity, we find a wide range in the units or increments of available storage in the various cloud providers. There is the “included” storage mentioned above that is often based on the size of the server and the requested OS type. To add storage, we find cloud providers (such as Amazon) allowing 1GB increments up to 1TB, and others (like Flexiscale) allowing only fixed increments of 50GB/100GB/250GB. For Rackspace, you can resize both the server and storage according to the defined fixed ratios, but these are bound to memory and CPU so there is no independent scaling of storage. The bare-metal cloud provider NewServers allows iSCSI storage to be attached to your servers in 250GB increments. In the cloud these varied increments really matter, because you are paying by the GB/month and if you need just a little more storage, you could end up having to purchase 10x more storage than you need, or having to pay for more memory and compute than you need.
The conclusion we can draw is that there are numerous storage configuration options in the cloud, and these options become linked to the server “flavors” defined by individual cloud providers. Because you don’t have the same control or even mechanisms in the cloud as you do in the local data center, the manner in which you allocate, populate and manage data in the cloud will be different. The work you do to understand and map your applications’ requirements into cloud-based storage requires changing your processes to match those of the cloud, and often this work is cloud-specific.
Beyond configuration issues, of course, there are many other concerns. For example, with data management, you have to determine how you will get your data into the system, how to grow your systems and how to protect your data. Right now most clouds use template servers that you have to build up from a pre-installed base operating system using update mechanisms and then re-installing the application components. As for protecting your data, there are also many cloud-specific options available – from RAID-protected EBS in Amazon, to data snapshots and cloning, to backup services offered by companies like Rackspace.
The bottom line is that cloud storage can be simultaneously simple and complex – just like cloud computing in general. It’s simple to use if you just want to try something new; complex if you want to integrate cloud storage into your existing processes and infrastructures.
Next: Networking in the Cloud
Moving to the Cloud: What's Really Required
When we started talking with a wide range of IT managers and companies in early 2008, we quickly encountered a fascinating dichotomy – Cloud Computing is really easy / Cloud Computing is really hard. What made this so interesting is that the casual users were saying cloud computing was easy and the hard-core users were claiming that it was hard. Amazon and a number of other cloud providers have made major advancements since this time, but the “it’s easy / it’s hard” split still exists.
Today, if you want to use the cloud and deploy a server, it is really quite easy to “build” a server from the base templates offered by the cloud providers. There are consoles available to launch servers including providers' control panels (Amazon, RackSpace, Terramark), plug-ins for Firefox (ElasticFox), and third party products like RightScale. Start from a predefined image, add your edits, and poof – you have a server running in the cloud.
It becomes a lot more complicated when you try to integrate an application with multiple servers running in the cloud with your existing data center infrastructure. When I say infrastructure, I mean all of your existing networking, services (DNS, DHCP, LDAP, Identity), build processes, third party applications; basically, the whole of your IT environment that you depend on to make things work.
When you deploy applications in the cloud, they are running on an infrastructure built and maintained by the cloud provider. This means that there is a certain amount of control that is transferred to the provider –the underlying control and assignment of resources they require in order to manage their environment. You need to understand this new environment, select the appropriate resources, and adapt your application to it. But moving an application that’s been running in your enterprise infrastructure, with all its associated processes and relationships, to a cloud provider that has its own way of doing things is where using the cloud gets hard.
To highlight some of the difficult areas, we’ll examine a set of issues across a variety of cloud providers out there. Because there’s a lot of ground to cover, I’ll break up the posts into multiple parts dealing with storage, networking, management, performance, and security. We’ll start with storage since it represents the real identity of the server and all that is important to your application and business. Stay tuned.
Next: Key considerations for cloud storage
Dynamic Cloud Fitting - The Future in Automated Cloud Management
The cloud computing landscape is evolving rapidly, with more and more players introducing cloud products and services of all kinds. Most recently we’ve seen the announcements by VMware partners including Terremark, BlueLock and others, as well as the introduction of Rackspace’s Cloud Servers. EMC is planning to offer a compute cloud in addition to its existing Atmos storage cloud. As the proliferation of offerings continues to accelerate, IT managers have questions about how to proceed: How can you evaluate the range of potential cloud offerings to find the right match? How do you route an application or workload to a target cloud and make sure that it works? How do you integrate it with other applications running back in the data center?
Cloud Brokers
As Gartner Group points out, getting the most out of the cloud will ultimately require the assistance of a knowledgeable and reliable expert: the cloud service broker. Cloud blogger John Willis feels strongly as well about the importance of this emerging category. Even within a single cloud, deploying an application requires learning the provider’s operating environment, management tools and business terms and conditions. Doing this for every cloud provider you may wish to utilize is likely to prove daunting and not cost-effective. In a cloud environment characterized by multiple providers, each with its own service terms, operating platforms, management systems, security levels and disaster recovery approaches, the specialized expertise and value-add of a cloud service broker will help IT managers find the right cloud offering, deploy their application in the cloud and manage it properly.
Effective cloud management will not only require technical expertise but also the business savvy and leverage necessary to negotiate the best deals and relationships between cloud consumers and cloud providers. This specialized knowledge, as well as access to the latest cloud management tools and services, will make the cloud broker a strategic partner for companies that want to use the cloud (broadly defined) to full advantage — especially as a wave of new cloud services come to market and the environment becomes still more heterogeneous.
Going Dynamic
Within the next few years, the cloud will become a much more dynamic environment, with the cloud broker playing a leading role. In the early adoption phase, enterprises will still want to “fit” their computing needs to a cloud manually. But over time, at least some cloud applications will be managed using an automated, rules-based approach, both for initial deployment and also for periodically reviewing performance and evaluating alternatives. For example, when the cost of running an application reaches a certain threshold, other cloud options will be evaluated automatically. If a more attractive offering meets established policies, the changeover can occur in real time.
The benefits of this dynamic cloud fitting will soon become apparent, whereby cloud service brokers use specialized tools to identify the most appropriate cloud resource, and then map the requirements of an enterprise application to it. Cloud service brokers will be able to automatically route data, applications and infrastructure needs based on key criteria such as price, location, latency needs, SLA level, supported operating systems, cloud scalability, backup/disaster recovery capabilities and regulatory requirements. IT managers will be able to run applications where they truly belong, while the broker takes care of the underlying details that make the cloud so compelling.
Legacy Apps: The Next Frontier in the Cloud
Although cloud computing momentum continues to build and scarcely a day goes by without a new cloud announcement or study, there’s been little real enterprise adoption and almost no meaningful case studies. In part, that’s because early cloud providers and vendors were focused on developers and technology start-ups when they designed their offerings, and larger, more established organizations were rarely on their radar screen. While start-ups can easily embrace new technologies and architectures, enterprises have far more constraints and have been largely limited to “tire kicking” the cloud with small applications that aren’t particularly meaningful for the business.
Cloud computing is now entering a new stage as CIOs and IT managers recognize that cloud computing is going to become an integral part of the enterprise computing environment. For it to be strategic as opposed to experimental, they need to know that the cloud can integrate with their existing data center infrastructure and incorporate the legacy applications that reside there. That’s where the major pain points, complexity, and costs have always been, and where the cloud can potentially offer its greatest returns. In our discussions with CIOs, we hear this theme over and over.
Legacy apps cover the entire installed base of applications running on a company’s internal infrastructure. They include everything from highly-used apps that are optimized for particular hardware to older versions of apps that must be maintained for specific customers as well as test and development environments, and apps used for internal purposes such as training. The true enterprise payoff for cloud computing will come from the ability to offload a wide range of legacy apps that don’t need to run in the data center to a cloud environment where they can be managed more cost-effectively. Not all legacy apps will make sense to move to the cloud initially (or perhaps ever), so the trick will be to select the right ones.
As Bernard Golden points out, the conundrum is that while putting legacy apps into the cloud can provide huge value for the enterprise, it’s also where the biggest hurdles lie. While a new application designed specifically for a cloud can usually be rolled out fairly easily, legacy apps come with a whole new set of challenges. Many of today’s cloud offerings were built for serving up web apps and Amazon-type storefronts, and have attributes that were not originally designed with the enterprise in mind (non-standard storage, isolated networking, and multi-tenancy are some examples). The result is lots of manual re-configuring, complex engineering, and trial and error before the enterprise application is able to run in the cloud. And once the app is in the cloud, it’s completely separate from the existing management tools and policies, and potentially locked-in to the cloud for which it has been re-architected. This lack of fast, incredibly simple ways to migrate legacy apps to the cloud and back without modification is one of the major factors holding back enterprise cloud adoption today.
CloudSwitch is focused on eliminating the barriers to moving legacy apps to the cloud. We believe applications should be able to run in the cloud “as is”, without worrying about the technical hurdles that today makes cloud deployments complex, time-consuming and expensive. We’re excited to be part of the “next frontier” in cloud adoption, working closely with enterprise customers and cloud providers.
RSS Feed