Cloud Strategy
Dealing with the Cloud's Latent Tendencies
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedInBy John Considine
One of the frequent questions we get when we engage with customers moving applications to the cloud is: what about the latency issues when using a cloud? This question arises because most IT departments have had to struggle with application performance issues and the idea of adding a big chunk of latency when integrating the cloud is very troubling. Here is how we address this:
1. Move the whole application to the cloud. We have been working hard to allow you to move all of the components of your application to the cloud. With this capability, you are not adding the latency between your data center and the cloud to the interactions between the servers in the cloud. A simple example is moving both the presentation tiers and database tiers to the cloud. The front-end servers talk directly to the database in the cloud, and they experience “data center” level latencies (i.e., nearly the same as in your DC). This often leads to a related question: if I move the whole application, where is the hybridization and integration? Simple, there are a collection of other services and data that your applications depend on – things like name servers, identity servers, domain controllers, ancillary databases, etc. Often access to these services is not latency-sensitive because it’s not part of a high transaction rate process.
2. Use a cloud that is “nearby.” Latency is a function of distances and “hops” across routers. The closer you are to a cloud, the lower the latency. This is one of the reasons we have architected for multi-cloud support, and are so focused on zero modification of your servers and applications. If you have the freedom to use a cloud that is “closer” without having to change your configurations, then you can take advantage of resources that make sense to you. We’re excited to see more players creating and expanding cloud offerings; more clouds in more locations means that we can help customers integrate cloud with their data center infrastructures, taking advantage of lower latency, higher SLA’s, and better pricing. With Amazon opening more regions, Savvis and Terremark supporting more than a dozen data centers each, specialized players like BlueLock focusing on security and compliance, and folks like Microsoft and AT&T getting into the mix, we expect that there will be “nearby” resources available for most companies in the near future.
3. Take advantage of WAN optimization. You cannot defy the laws of physics, the speed of light is a real limit, and thus the distance to the cloud you are using will determine the minimum amount of latency. Given this, however, there are things that can be done to minimize the impact of latency and bandwidth restrictions. There are a number of products out there that help with Wide Area Networking optimization and CloudSwitch can take advantage of these in two ways. The first is that we work with your existing network infrastructures so that if you have optimized links available between your data center and a cloud provider, we can take advantage of them. The second is something we are working on – integration with these products such that they can be deployed with or alongside of CloudSwitch to optimize cloud communications.
The bottom line is that latency issues are part of your decision process when you determine which applications (or parts of applications) will get moved to which cloud, and you should test the results early in your cloud evaluations. With CloudSwitch you have some good options for dealing with the inherent latency issues in cloud deployments so you can successfully integrate the cloud into your IT infrastructure.
Get off the Bus - Explore the Cloud TODAY!
By 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.
The Hidden Costs of Internal Clouds
By Ellen Rubin
A public cloud can provide access to computing resources that many companies would otherwise never be able to afford. The arguments for the cloud are well-known by now, but remain compelling—no up-front costs, virtually unlimited computing power on demand, and highly efficient pricing where customers pay only for resources used. There’s also less pressure on corporate IT departments that are charged with managing the infrastructure and budgeting for new equipment to keep up with demand.
But concerns about security and loss of control in public clouds have led to an alternative model—the internal cloud—that replicates the cloud environment inside the corporate firewall. Within these boundaries, enterprise users can provision computing resources as needed, using the cloud’s self-service capabilities while leveraging data center services. Internal clouds are often referred to as private clouds, but since private clouds can also be found in external environments, the “internal” designation is a more precise term for what we’re talking about here. (RightScale's blog post provides helpful definitions of the different cloud variants.)
With servers, applications and data within the enterprise walls, internal clouds can provide many of the benefits of cloud computing without the potential risks when the computing environment is provided by a third party. Unfortunately, the economics of internal clouds makes them inherently less efficient than the public cloud, especially as new technology makes the public cloud safer and more reliable. Here are some of the reasons why:
- Infrastructure costs: Deploying an internal cloud requires building out the infrastructure to support the needs of all enterprise users. In addition to acquiring the necessary hardware and software, this includes things like configuring the network, allocating storage, paying the electric bill, and providing square footage for the equipment. Plus, all of this infrastructure has to be managed and supported on an ongoing basis.
- Over-provisioning: Just as with traditional IT infrastructure, anticipating resource requirements for an internal cloud is difficult since applications run at varying usage levels. Some applications consume resources fairly steadily while others require occasional bursts of massive computing power. Companies may have no choice but to over-provision, where some equipment sits idle most of the time in order to have resources available for peak periods. (Meeting these short-term usage needs is one example where the elasticity of public clouds really pays off.)
- Building the management plane: As Jon Brodkin points out, building an internal cloud is about more than just virtualization. One of the key benefits of cloud computing is the self-service aspect, where users can access resources as needed via a self-service portal, which then execute in the cloud automatically without administrator intervention. Building this control plane is another substantial step when implementing an internal cloud.
For all of these reasons, the internal cloud carries a cost overhead compared to leveraging the resources and self-service framework already provided by public clouds. Ironically, much the same protection and control offered by internal clouds is becoming increasingly available in an external public environment. So enterprises may find that a public cloud may provide a more cost-effective home for many (or even most) of their applications.
Internal clouds can make sense for the most business-critical requirements or those that need specialized hardware or have regulatory compliance issues. Focusing internal resources on these types of applications would greatly reduce the investment required to build, sustain and grow enterprise infrastructures. While some applications may always need to run internally, many companies have dozens of others that could run more cost-effectively today in a public cloud, providing computing power on demand along with required security, agility and scalability.
At CloudSwitch, we provide technology that allows companies to take full advantage of the resources and savings that the public cloud has to offer, while integrating seamlessly with their internal environments. Applications deploy automatically, are free from lock-in, and stay tied into internal data center services. In short, the enterprise gets the protection and control formerly found only behind the firewall, and can combine the best of internal and external cloud offerings with maximum agility and value.
Why an 'Apps' Guy Moved to the Cloud
I have spent most of my career involved in the development of software applications. For the past seven years, I had the honor of leading SolidWorks, the # 1 mainstream 3D CAD company in the world. When I left in 2007 we had over 750,000 users and tens of thousands of companies using our software. They were designing products that you and I use in our everyday lives.
Through a lot of hard work of hundreds of employees and some luck we helped create a lot of value for these customers as well as our investors and business partners. In addition to good luck (which we admittedly had a lot of), we capitalized on a fundamental platform shift: Unix to Windows. This platform shift, combined with a business model shift (direct sales to indirect sales) created a significant amount of value. I sense the same opportunity with the cloud.
After taking some time off, I spent time with some local venture capital firms looking at a lot of new technologies, new products and business ideas. All of the start-ups (not just some, but all) were using the cloud for their infrastructure. Like canaries in a coal mine, this to me validated what I was observing: the cloud really is a new platform. Also, the cloud requires a business model shift in enterprise software sales since cloud services by their nature are low-cost and on-demand – unlike the traditional sales model of large, costly enterprise purchases.
I spent several months more looking at companies in and around the cloud space and became intrigued by the perspective shared by Ellen Rubin and John Considine, founders of CloudSwitch. They had a clear view of how they felt companies would want to take advantage of the cloud. This was evident in their approach: rather than try to take the clouds to the data center (which everyone appears to be doing), they wanted to start from the data center and help them extend out to the cloud.
Combine this simple, yet profound insight with a platform shift and a business model shift and you understand why an apps guy would be so excited to join the CloudSwitch team.
Opscamp Austin: IT Ops and the Cloud
Going to a conference focused on IT on a Saturday sounds like a really geeky way to spend a weekend, but thanks to an “alternative” venue, the “un conference” format, and a group of really good people, it was a great day. I just got back from Opscamp Austin, a meeting of IT professionals, system administrators, tools vendors, cloud providers, and people who spend their time building and keeping the computing infrastructure of business running. Many thanks to those who built this un-conference especially John Willis, Mark Hinkle, Damon Edwards, and all of the sponsors and presenters – you pulled together a great event.
Opscamp was created to allow an “open exchange of ideas around next generation technologies and strategies for IT Operations.” The big topics at this meeting (as measured by both passion and interest) were Monitoring, Configuration Management, and DevOps. I was particularly interested in these topics because we added the phrase “in cloudy environments” to the sessions.
I came away from this conference with a few conclusions:
1. IT operations is currently messy, and “cloud computing” is exposing some of the problems. One problem is that when the cloud delivers on the notion of allocating resources in minutes, the pressure switches from raw provisioning to the speed of configuration; with the timescale compressed from days to minutes, there is nowhere to hide. The other big issue is the dynamic nature of cloud computing – with servers, networks, and storage showing up and disappearing from your environment, it becomes difficult to model and manage. The manual or loosely connected processes that worked because there was time while you waited for hardware to arrive no longer work in a highly dynamic environment.
2. There are very different views about what monitoring in the cloud should be – deep and consistent with current processes, or “just hide the messy parts,” to quote Amazon. Some wanted the cloud providers to give them deep access to the “normal” monitoring data – think cpu temperatures. Others think that the value in the cloud is getting rid of the support and detailed attention to the infrastructure, so who cares about that data, it is for the infrastructure provider to manage. The issue is that the current cloud offerings are quite opaque about what is happening in the infrastructure.
After talking with Bret Piatt from Rackspace it seems that the problem is not collecting the data (they have to do it anyway), but storing it, processing it, and doling it out to the customers. There is real expense here, and for those customers who don’t want it, they would have to carry the burden of the extra cost in a market that is sensitive to price. The fundamental choice here is whether we are going to carry the current detailed monitoring practices into the cloud, or give up on the low level monitoring of the remote resources. In order to carry forward the current models, the cloud providers will have to provide API’s to get at the internal data. In order to change the model, developers and tool providers will have to increase the capabilities of the applications around fault tolerance and providing useful monitoring data that can be measured from the application level.
3. We are still in the early days of cloud computing. This should not be a surprise to anyone, but since at CloudSwitch, we’ve been so fully integrated with the cloud since the beginning – with everything from our build servers, bug database, large number of QA servers, code repository and web site –it’s easy to think that everyone is already comfortable using the cloud. What became clear in the discussions is that many of the organizations are still working though server virtualization and how to take advantage of the advanced features enabled by that technology.
What was really exciting for me was to see the people who actually have to make IT work thinking through what is needed to build a dynamic data center and integrate with cloud computing. With these guys on the case, I know that cloud computing is taking real steps forward.
Five Things to Do Before Moving to the Cloud
Before moving an enterprise application to the cloud, you need to be sure that your expectations are realistic and your objectives match what the cloud can deliver. In this post, I’d like to share what we’ve learned from working with our beta customers, from their initial exploration of cloud possibilities to going live with a specific application they’ve migrated to the cloud. The following steps can help guide the thought process when considering a cloud deployment, and provide a starting point for moving forward.
1. Determine your cloud objectives. What are you trying to accomplish? Is the cloud a solution for reducing costs, faster provisioning, data center consolidation, all of the above? Sometimes all goals align, where the cloud allows you to save money, be more responsive and avoid huge infrastructure investments all at the same time. But it may not be possible to realize all the benefits for a given organization or use case. For example, if there’s extra capacity in your data center there may be no obvious consolidation advantage to putting an application in the cloud. However, there could be other issues at play that justify the move, such as high operating costs or an infrastructure that makes it difficult for users to get the support they need.
2. Pick an application that makes sense. For example, how much latency is acceptable to users? The laws of physics slow things down over the Internet and network performance will vary, so if you need millisecond response the cloud may not work for your application. How critical is the application? You may not want to put an application in the cloud upon which the business depends even if infrastructure limitations (scaling, support, response time, etc.) make it seem like an attractive option. Get your feet wet before diving in -- a safer approach might be to start with a low-risk, back office (not-strategic) application before setting your sights on more ambitious targets.
3. Involve the CSO/risk management team from the beginning. The cloud, perhaps even more than other technology shifts, has raised red flags about security since your applications and data will potentially be moving outside of the enterprise firewall. Engage your company’s security experts and decision makers from the beginning to understand their perspective and address their concerns directly. Get them involved in the discussion early so they’ll understand why the cloud is important to the business and how you want to use it. Give them a chance to review their security concerns with potential vendors before you sign up.
4. Decide which cloud(s) are acceptable. Finding a cloud that’s best suited to your needs is as critical as identifying the right target applications. Cloud offerings vary widely—in their APIs, configurations, storage infrastructure, networking options, pricing structures and SLAs. Some of the variables will be essential for your requirements, while others are simply nice to haves. The process is like evaluating any other technology offering, except the environment is probably new and unfamiliar. You may want assistance from a partner with cloud expertise who can help you qualify the various cloud options to make sure you make the right choice.
5. Create a sandbox where people can experiment. All of the different user groups should be able to see how a cloud-based application compares to a traditional one. Give business users, administrators and developers a chance to evaluate the benefits of the cloud from their perspective, as well as the limitations. Application experts can use the sandbox to run functionality and performance testing on the application in the cloud to see how it behaves compared to the traditional environment, and if any differences are acceptable.
Get Your Hands Dirty
Once you’ve done the necessary due-diligence, you’re ready to get started with beta testing and proof-of-concept pilots with vendors. In an area as hyped as the cloud there’s really no better way to learn than hands-on, and these basic best practices will help lay the foundation for a successful cloud strategy. CloudSwitch can help address the security concerns and make it “point-and-click” easy to move to the cloud, using your existing management tools and applications.
RSS Feed