RightScale Conference: Talk to the Experts About Cloud

Posted on May 16, 2012 by

Cloud is here and cloud is now. RightScale has led the way in cloud management, with more than 4 million servers launched in the cloud to date. We know that cloud is a strategy, not just a tactical solution. It’s not simply about moving to the cloud and doing business as usual. Cloud is about transforming IT. Cloud is about making business more agile. Cloud is about enabling completely new business models.

To be successful with cloud, IT decision makers must first ask themselves:

1. What do I want to achieve with cloud computing? Agility? Scalability? Cost savings?
2. How do I select the best clouds for my use case?
3. How do I correctly architect my systems for the cloud?
4. What tools and solutions do I need to make it happen?

Over the past six years, RightScale has developed a deep expertise in cloud. RightScale engineers have worked with forward-thinking IT leaders from companies like Pearson Education, Fox Media, and CareCloud to help them develop and implement their cloud management strategy.

We’ve built a cloud management solution that will continue to serve companies as cloud adoption accelerates and as they build out their multi-cloud portfolio to include public, private, and hybrid cloud technologies.

RightScale now gives users the ability and choice to manage their cloud applications on 7 public clouds (Amazon Web Services, Rackspace Cloud, and SoftLayer among them) as well as with 3 private cloud providers, including Citrix CloudStack, Eucalyptus Systems, and OpenStack.

At RightScale, we’ve developed the expertise to solve the problems that plague corporate data centers, from managing VM sprawl and underutilized hardware to enabling self-service provisioning and metered chargeback, and we’ve built solutions for managing them into RightScale.

When the sixth RightScale Conference kicks off in New York City on June 13, some of the most progressive minds in cloud computing will be there, among them our engineers, our customers, and our solutions partners such as Zend, 10gen, and Riverbed who provide the expertise and the enabling technologies to help you design and develop applications for the cloud. You’ll have the chance to talk with these experts and take advantage of their collective knowledge to jumpstart your cloud project or fine tune your existing systems architecture or deployments.

Following a keynote from RightScale CEO Michael Crandell, we’ll feature presentations from RightScale customers including Pearson Education, Fox Media, and CareCloud. The afternoon will be devoted to breakout sessions on a variety of topics, including a track each on Private and Hybrid Clouds, HA/DR, and Big Data.

Private and Hybrid Clouds

We’ll be holding several breakout sessions on multi-cloud strategy, including one by RightScale Professional Services Architect Brian Adler who helps many of our enterprise customers custom design their architectures. He’ll share key considerations for building a private or hybrid cloud as well as selecting hardware, cloud infrastructure software, hosting vendors, systems integrators, and reference architectures.

Peder Ulander with the Cloud Platforms Group at Citrix will demonstrate how CloudStack, CloudBridge, and RightScale can enable Enterprise IT to extend resource pools beyond physical datacenter boundaries and leverage additional private clouds or public clouds to meet peak usage requirements and smoothly manage planned or unplanned capacity spikes.

Jeff Dickey, Chief Cloud Architect at Redapt, will provide specific use cases and examples for creating a hybrid cloud that can accommodate legacy applications while providing flexibility for future architectures and applications. He will also cover securing and segregating data, ensuring elastic demand, and accommodating mixed workloads on bare metal and hypervisors, as well reducing data center waste while increasing application to hardware efficiency.

HA/DR

Some view the cloud as a silver bullet to solve performance issues. If only it were that simple. Although the cloud does provide a superior way to scale hardware on demand, performance must be optimized at the application level to realize maximum gains. Apica COO Craig Irwin will present key strategic elements employed by innovative companies and share actionable insights on how they are leveraging technology to proactively identify bottlenecks, improve performance, and optimize their environments. Learn from high-profile crashes and common mistakes that enterprises make — and how not to become another headline.

Once you’ve optimized your application performance, you need to make sure your database can keep up. Senior Systems Architect Josep Blanquer will demonstrate how RightScale uses SQL and NoSQL databases such as mySQL and Cassandra to provide a scalable, distributed, and highly available service around the world that is designed to recover from failures of an entire cloud region.

Big Data

Because it exceeds the processing capacity of conventional database systems, big data is proving to be a popular use case for deriving huge benefits from on-demand, unlimited compute resources on a pay-as-you-go basis. In a Big Data 101 session led by RightScale Engineer Vijay Tolani, you’ll find out what others are doing with big data in the cloud and how to get started. He’ll cover solutions from RightScale technology partners IBM BigInsights, Couchbase, and MongoDB in the context of storing large data sets with NoSQL solutions and performing data analytics using Hadoop. Vijay will demonstrate the IBM BigInsights ServerTemplateTM and how it can be used to deploy analytics clusters for companies of all sizes. IBM offers free database and Hadoop courses through BigDataUniversity.com, which has more than 20,000 registered participants.

RightScale Zero-to-Cloud™ Training

If you’re looking for training on either RightScale fundamentals or advanced concepts, such as using RightScale with Chef or using RightScale to set up a hybrid cloud, we’ll be offering instructor-led hands-on courses onsite at the Javits Convention Center the two days prior to the conference. Our training classes sold out last conference, so get more details and sign up soon for RightScale training.

Get Your Free RightScale Conference Pass

So if you’re looking to move to the cloud — or you’re already there — we think you’ll find the RightScale Conference to be the place for expert advice on cloud computing and managing your cloud strategy. We’ll see you in NYC.

Posted in Cloud Management, RightScale Conference | Tagged , , , , , , , , , , | Leave a comment

Four Steps to Achieving High Availability in the Cloud

Posted on May 9, 2012 by

Constructing a high-availability application in the cloud can seem like a daunting process. The key is to assume that every component of a system will fail at some point and to prepare for that eventuality. Then you can build for failure and automate processes to handle it. Fault-tolerant systems designed for high availability are achievable in the cloud.

At the upcoming RightScale Conference in June, high availability (HA) and disaster recovery (DR) strategies will be one focus of discussion as this is a challenge that many companies are attempting to manage. When we advise our customers on designing their architectures for HA in the cloud, there are four tried-and-true steps we typically recommend:

1. Build for server failure

Instances in the cloud — just as in a typical data center — are ephemeral. You need to be prepared for server failure. Building for server failure begins with designing stateless applications that are resilient through a server or service reboot or relaunch.

  • Set up auto-scaling so that your application can respond to dynamic traffic patterns based on a set of performance metrics.
  • Set up database mirroring, master/slave configurations, and/or priming to ensure data integrity and minimum downtime.
  • Use dynamic DNS and static IPs so that components of your application’s infrastructure always have the right context.

2. Build for zone failure

Sometimes more than just single servers fail — there are power failures, network outages, and lightning strikes. You need to make sure that your applications are prepared for zone failures. Zones (Amazon Web Services refers to them as “availability zones”) are distinct locations that are engineered to be insulated from failures in other zones.

  • Spread the servers in each of your application tiers across at least two zones.
  • Replicate data across zones. Note that this is usually cheap, though not free.

 Cloud Regions and Zones

3. Build for cloud failure

On rare occasions multiple zones in a region can experience outages due to system-wide issues — the April 2011 Amazon Web Services (AWS) outage is a notable example. Each region is an independent system of resources with its own API endpoint — which is how we define cloud here.

To achieve multiple 9s of availability, you will need to have a process in place for cloud failures. Building across clouds can be difficult: APIs, services, and configurations differ. You will need to design your architecture using generic concepts (durable storage) yet deploy using cloud specifics (EBS volumes).

Cloud management systems abstract away these differences and make it easier for you to implement a fault-tolerant strategy by providing reusable building blocks. These building blocks can be used to not only withstand moving across different regions of the same provider, but also across different infrastructure providers.

  • Back up or replicate data across regions or providers. Make sure you secure and authenticate your communications across these regions as the traffic will traverse the open Internet.
  • Maintain sufficient capacity to absorb zone or cloud failures, using reserved instances if necessary.
  • Remember to crawl, then walk: Build high availability across zones and then expand to multiple clouds.

4. Automate and test everything

As you set up your infrastructure to handle server, zone, and cloud failure, you should be automating your processes in the event such a failure occurs. Cloud management systems allow you to execute pre-planned failover processes across servers, zones, and clouds. In an emergency, time is precious, so automate everything.

  • Automate backups so that your data is ready whenever disaster strikes.
  • Set up monitoring and alerts to identify and pinpoint problems as they occur because you may not receive timely information from your cloud providers.
  • Your disaster recovery plan is only good if you test it to make sure it works. By directing high loads to your production servers and disabling your various servers, services, and zones, you can test the ability of your infrastructure to withstand failure.

Cloud infrastructure has made DR and HA remarkably affordable compared to other options. Despite recent highly publicized failures, many organizations successfully run critical services on the cloud when they architect correctly and use the right management tools. For a reference architecture and additional best practices, check out this white paper on HA and DR scenarios.

Posted in EC2 | Tagged , , , , , , | Leave a comment

Private and Hybrid Clouds: Like Sex in High School

Posted on April 19, 2012 by

RightScale CEO Michael Crandell recently explained to a journalist at The Register  that “the hybrid cloud is a little bit like sex in high school  — everybody is talking about it, but not everybody is doing it.” While that may be true for the IT industry as a whole, Michael also rightly points out what we in the RightScale Professional Services trenches see everyday: The majority of RightScale customers (87%) are leveraging the services of two or more cloud providers, which are often a public cloud and a separate, single-tenant private cloud.

Our customers run the gamut from the classic “two guys in a garage” success story all the way up to large enterprises, and many have already started to look at the private cloud for a lot of different and interesting use cases. What was once seen as an interesting science project has now been proven as a viable (and scalable) IT delivery model. Some companies are building “IT vending machines” that allow their internal users to quickly spin up pre-configured software stacks for use in siloed test and development environments.

Others are using their private cloud in combination with one or more of the public cloud offerings to create a hybrid cloud  in which workloads are assigned to one side of the fence or the other depending on the characteristics of the applications they are looking to deploy.

And as the cloud outages over the last year or so have sent companies searching for viable disaster recovery solutions, the hybrid cloud has proven time and again to be up to this task for many of our customers.

In my role within the Professional Services group, I have the opportunity to talk to lots of our customers, and the trend continues to point more and more down the private/hybrid path. And as each of these customers have their own distinctive application workloads, they also bring to the private cloud their own unique set of requirements, desires, hopes and dreams. And while we in Professional Services do our best to say yes (as opposed to our Sales guys, who *always* say yes :) ) there are technical considerations that need to be considered, along with the normal practical ones like budget and schedule.

The companies I see that are the most successful at building private clouds are doing it for a few typical reasons, the first of which is workload/infrastructure interaction. In this case, the private cloud is being built for a very specific workload, and the hardware being procured is appropriate for the task(s) at hand. For example, one of our customers has an application with very high CPU demands. To most efficiently handle this workload in their private cloud, they are purchasing high-end compute hardware that has the horsepower to service the high demand. While there are public cloud resources out there that might be able to handle the load (such as cluster compute, high bandwidth instances), the quantity of the data involved is also quite substantial, and the cost (and latency) of pushing this data around, along with the security complications of shipping this data across the public Internet, has shown that the public cloud is a more costly solution over the long run.

Other customers have applications that demand (well, “very strongly desire”) high IOPS rates from their storage devices, and anyone who has run benchmark tests on the current selection of cloud-based storage systems knows that “your mileage may vary” doesn’t just apply to your choice of automobile and driving style. In order to get a higher (and much more consistent) IOPS rate, some customers are building out their private cloud with solid-state drives (SSD) for the nodes that require super-fast reads and writes. For the other parts of their application with more pedestrian needs in regard to storage, they have more traditional disk subsystems in place, and launch nodes in the appropriate pool of resources (segregating by zone or cluster).

Still other customers are using the private cloud to meet their security compliance needs. Since all the data stays within their own infrastructure, and never even sniffs the public Internet, they are able to run cloud-based workloads that still meet all of their stringent regulations. Basically, if you can keep your packets local and eliminate the need for them to travel out into the Wild, Wild West of the public Internet, you are going to have happier packets and unhappier bad guys who are out looking for those packets.

All of these use cases, the considerations surrounding them, and lots of other related and relevant bits can be found in our recently published white paper on architectural best practices for designing private and hybrid clouds.

Much like sex in high school, the prospect of having a private or hybrid cloud can be exciting, but if you’d never done it before, it can be reassuring to have that mentor who can tell you what to expect. We’re here when you need us. ;-)

Posted in Cloud Computing | Tagged , | Leave a comment

Cloud APIs: It’s the Architecture that Matters

Posted on April 3, 2012 by

Lack of excitement is not something the cloud market can be accused of! Citrix just announced a bold roadmap for its CloudStack platform coming right on the heels of a Eucalyptus and Amazon announcement to extend API compatibility and just two weeks before the OpenStack summit. My prediction for 2012: we will exit the year with as many cloud APIs as we had when we entered, and it doesn’t really matter!

Railroad gauges & compatibility...
(Source Wikipedia)

Citrix’s announcement is interesting because it is the first bold move around CloudStack coming after the acquisition of Cloud.com by Citrix. Over the past year the CloudStack team and Citrix have worked with the OpenStack project, contributing code and adopting the Swift storage service. I know that the CloudStack team was always quite open around adopting OpenStack technology but at the same time it always seemed like they would take a big step backwards if they adopted the compute portion. After all, CloudStack has powered some of the most successful large scale private cloud deployments in production and is powering a good number of large public cloud service providers too. From that point of view it only makes sense for Citrix to stick to its proven technology and continue to develop the CloudStack codebase, pulling-in parts of OpenStack where appropriate, such as for the storage service, and using its own technology for other parts. With this move to make CloudStack an Apache Foundation Project, Citrix puts a stake in the ground around its commitment to CloudStack as an independent technology, and its roadmap to remain competitive on the API front.

Last week Amazon Web Services and Eucalyptus jointly announced a partnership to enhance the compatibility of Eucalyptus with AWS APIs. This announcement is a great validation of Eucalyptus’ strategy which has always been to be API compatible with AWS instead of trying to establish yet another API. It’s also interesting from the point of view of how AWS’ strategy around its API has played out over time. When Eucalyptus first gained momentum and RackSpace first worked on their cloud offering there was a lot of speculation whether AWS would try to prevent API clones, even possibly with legal means.  It was clear at the time that the issue had been discussed internally at Amazon but AWS never said anything publicly one way or the other. This wait-and-see approach let them observe the market’s evolution and start playing their cards when it suited them (which they have now done). At this point we can only speculate whether an earlier play would have been beneficial — for example, to support Mark Shuttleworth’s appeal half a year ago to the OpenStack community to adopt the EC2 API. In any event, now that Citrix has announced that CloudStack will be AWS compatible (they do mean API compatible even if their press release doesn’t state it verbatim), it’s clear that AWS API compatibility will become increasingly common in the IaaS market.

But what does all this mean? How important is Cloud API compatibility? What should Cloud API compatibility even mean?

The pitfalls of Cloud API compatibility

I’ve said it many times and I’ll repeat it again: it’s the semantics of the resources in the cloud that matter, not the syntax of the API. This means that “API compatibility” has to reach very, very deep to be meaningful. Let me give you a couple of examples around EC2.

#1: EC2 has a number of discrete instance types, from a fractional core to 8, from 512MB to 64GB of memory, from no local disk to 4 spindles, from shared network bandwidth to dedicated 10Gps ports, etc. While all these instance type can be replicated in a local cloud, it’s not an easy task. This means that moving workloads to local clouds where instance types differ could well require some non-trivial architectural adaptations. And even if it is possible to exactly replicate the AWS configurations, it turns out that doing so may actually not be desirable! Some of our large hybrid (public + private) cloud customers report achieving significant cost savings precisely because they are using customized instance configurations specifically tuned for their applications.

#2: EC2 EBS block storage devices have quite peculiar performance characteristics (that are not universally liked…) both for regular I/O as well as for snapshots. It would seem rather crazy to try to duplicate those characteristics and not benefit from improvements that are possible in a smaller purpose-built private cloud. But by doing so the operating procedures for deployments may change rapidly making the notion of “compatibility” questionable. Put differently, should one retain compatibility if compatibility is worse?

#3: The AWS clouds are divided into regions that are independent of one another and all resources are bound to a region. This means that if you create an image in the us-east region and want to have a DR set-up in the us-west region you need to copy the image explicitly to us-west and keep maintaining any updates you make. Some of the more interesting innovations being pioneered by other cloud providers allow the ability to publish images and even volume snapshots worldwide across regions. Does something like that break the EC2 API? Not necessarily, but it certainly changes tools and the way one would maintain DR set-ups. So, API compatibility doesn’t help much here either.

#4: Along those lines it’s interesting to see how Softlayer leverages their worldwide network infrastructure to offer each customer a worldwide private network: the 10.* addresses of all instances worldwide are interconnected (on a customer-by-customer basis). That makes operating servers across multiple regions a lot easier than in EC2. If Softlayer were to use the EC2 API they could offer these benefits without being “API incompatible”, yet global deployment architectures and tools to manage them would be radically different between Softlayer and AWS.

The point of all this is that API compatibility is not a panacea for cloud portability or interoperability. For a simple tool that launches a few servers, API compatibility is helpful. But at the same time the amount of work to port that tool to a different API is minimal as well. When it comes to more important aspects of cloud appeal — real elasticity, high performance, cost efficiency, better governance and control, failure isolation & resiliency — then API compatibility is simply not a ticket to portability across clouds.

The bigger compatibility picture

The bigger picture around Cloud API compatibility starts with the observation that there are really many AWS APIs, and the EC2 API is really only a relatively small portion of the pie. And even there, I would claim that there are actually two EC2 APIs: the “EC2 classic” API and the “EC2 VPC” API for the virtual private cloud. They are very similar to one another, but have significant differences beyond what you might imagine the VPC differences to be. This ranges from VPC security groups having egress rules which “classic” security groups don’t all the way down to little trip-me-ups like being able to move IP addresses from one instance to another using one EC2 classic call but requiring two EC2 VPC calls.

But to get back to the bigger picture: to me “Amazon compatible” really brings all 20 services offered in the AWS cloud into view (+/- a couple depending on how you count). Many AWS deployments use features that are close to EC2, such as Elastic Load Balancing, features that are further removed, such as the Relational Database Service or the Simple Queue Service, and features that are not very private cloud amenable, such as the CloudFront content distribution service. For many organizations, if the services they use aren’t included in an “Amazon compatible” cloud, then it’s not really compatible, and loses attractiveness — hence the long-running claim of “lock-in” around this proliferation of services.

My prediction is that increasingly cloud users will look for equivalent portfolios of services in clouds and less for strict API compatibility. For example, RackSpace added load balancing as a service support to their offering not too long ago. SoftLayer offers a content distribution service. And if one looks at the services around Google AppEngine there are Task Queues, Email services, various SQL and NoSQL storage services, and more. It’s clear that other cloud providers also see the portfolio of cloud services as being key. Currently these various services are somewhat equivalent to what AWS offers and for many of them the semantics beyond the API veneer are even more important than for EC2. It will be really interesting to see how the cloud compatibility — or should we say cloud “equivalency” — landscape evolves around these cloud service portfolios.

Summing it up

I have to say that Citrix’s three-fold statement that ‘our technology is the best’, ‘we’ll open source it under the apache foundation’ and ‘we’ll make it AWS compatible’ is bold. Since I’ve commented mostly on the AWS compatibility aspect, I should add that their increased ‘open sourcing’ of CloudStack does open the door for others to complement anything Citrix does with more AWS compatible services. It’s still a wide open game at this level of the cloud market, with, as I said at the beginning, no lack of excitement!

My recommendation to cloud users, however, is twofold: 1) do continue to dive in with these technologies and expand your use of different cloud offerings for more & more sophisticated projects, 2) don’t get too hung up on the compatibility debate and fail to see the cloud automation forest for the API trees.  The issues of portability and interoperability are being addressed well at higher levels of the stack – that’s what we do at RightScale, after all :-) .

Posted in AWS, Cloud Computing, CloudStack, EC2, Eucalyptus | 1 Comment

Build a Private Cloud in your Garage

Posted on March 28, 2012 by

A few weeks ago, this brilliant idea crossed my mind. Why don’t I build a private cloud at home, in my garage, so that I can get the experience of setting up the technology?

Vijay told me I was crazy, so to prove just how easy it would be I did it anyway, and as a result I’ve had a private cloud running in my garage since early March.

Continue reading →

Posted in Cloud Computing, CloudStack | 10 Comments

RightScale in Japan with IDC Frontier

Posted on March 22, 2012 by

Last year we announced a bunch of new clouds to the RightScale dashboard.  Each of those clouds brought a differentiated offering to our user base.  Recently, we announced public availability of a new cloud – IDC Frontier Cloud.  Analyst Agatha Poon recently wrote about IDC Frontier’s progress in IaaS and gave an overview of how their cloud is positioned in the Japanese market.

IDC Frontier Cloud is one of two clouds RightScale supports in Japan.    Over the past several years, IDC Frontier has been delivering managed public cloud solutions to the Japanese market.  Recently, they added self-service cloud products to their portfolio which is the focus of our integration.

IDC Frontier Cloud, as integrated with RightScale, is built on top of Citrix technology.  In particular, they have deployed CloudStack and CloudPortal.  CloudStack is the technology layer powering compute, network and storage that exposes the cloud API that RightScale uses to control, manage and orchestrate resources within the cloud.  CloudPortal provides a web based user interface that enables users to interact with IDC Frontier for things like customer support (ticketing, help desk, forums), payment and account management.  It is integrated with CloudStack and also gives users abilities around virtual machine provisioning.  The combination of RightScale on top of the Citrix technology gives users the ability to control more than their virtual machines and raw cloud resources.  They can provision dynamic application workloads using the power of RightScale’s cloud management solution.  With our pre-configured application stacks and our automation engine complete with application monitoring, alerting and scaling, users focus their efforts on deploying and maintaining their applications in the cloud.

RightScale adds ‘Scale’ to IDC Frontier

With the popularity of social gaming and web applications in APAC and growing need for resource pools in e-commerce, e-publishing and advertising, IDC Frontier and RightScale provide a complete solution for businesses looking to leverage cloud.  RightScale’s ServerTemplates provide the basis for server configuration that enable customers to run production web-scale architectures in the cloud.  Day 1, IDC Frontier has ported many of our ServerTemplates on their cloud and customized them to leverage web services that are available within the IDC Frontier cloud.  Those services include their own file storage solution, called Contents Store, and an internal dynamic DNS Service called NSUpdate.  Both of these services, along with advanced networking settings such as Firewall rules and LoadBalancer policies are available for configuration with the combination of RightScale and IDC Frontier Cloud.  You can read more about this offering on our support site, including how to set up a three tier application stack using RightScale ServerTemplates here.

RightScale continues to partner with the best clouds around the world, and continues to focus on helping our customers access the optimal resource pool for their cloud workload.  As some of us here at RightScale like to say…it’s a cloudy world :)

Give IDC Frontier and RightScale a go, and as always, let us know what you think.

Posted in Cloud Computing, Cloud Partner, CloudStack, Releases | Tagged , , , , , | Leave a comment

Big Data: Big Pain or Big Profits?

Posted on March 12, 2012 by

A recent O’Reilly Radar article on big data in the cloud included a mention of RightScale and its ability to orchestrate server management across multiple clouds. It prompted me to think about the role of RightScale in supporting the implementation of big data solutions for our users. But first, what exactly is big data? Edd Dumbill, a contributor to O’Reilly Radar, offers this explanation:

“Big data is data that exceeds the processing capacity of conventional database systems[because it] is too big, moves too fast, or doesn’t fit the structures of your database architectures.”

A commonly accepted way to identify big data is to determine if it meets any of these three key criteria:

Volume – The quantity of data is too large to fit into conventional database structures. There is a tremendous amount of information that can be gained by analyzing data stored on social networks, for example, but you have to analyze all of the data to extract the portion for your need at hand. Here are a few examples of the volume of data stored in social networks:

  • Facebook is expected to have more than 1 billion users by August 2012, handles 40 billion photos, and generates 10 TB of log data per day.
  • Twitter has more than 100 million users and generates some 7 TB of tweet data per day.

Velocity – Data is being generated at a meteoric pace. In many cases, data needs to be processed in real time or its value is diminished tremendously. Example use cases include:

  • Sensor Networks – A single airplane engine generates more than 10 TB of data every 30 minutes. In the past, this data was deleted at the end of each flight. How would you feel if you knew that your airline was instead using this data to proactively monitor the health of its engines and replacing them before they failed?
  • Stock Market – For every trading session, the NYSE captures 1 TB of trade information. In this case, processing stale data is worse than processing no data at all.

Variety – Did you know that 80 percent of the world’s data is unstructured? This data does not easily fit into the structures of a relational database, so storing and analyzing it requires a new approach. Two examples of unstructured data mining are:

  • Transaction Records – A recent Forbes article highlights how Target tailors marketing campaigns to pregnant women. The company accomplishes this by analyzing customer transaction records and assigning each shopper a “pregnancy prediction.”
  • Social Media Accounts – There is invaluable data contained in Facebook and LinkedIn users’ posts, emails, and text messages. But conventional data analytics platforms do not easily allow for storage or analysis of free-form text.

What is the connection between big data and cloud computing?

Analyzing big data can potentially lead to big profits, but is it worth the time and money? I recently attended a seminar where cloud computing was described as “the democratization of software.” I think this is particularly apt to any discussion of big data because, historically, analyzing a large data set required significant investments of both time and money. By using servers on a pay-as-you-go basis, you not only can reduce your costs but also benefit from increased compute resources to faster analyze your data. For example, let’s say you want to run a monthly report with Hadoop that takes 100 compute hours to complete.

Option 1: Build a 10-node Hadoop cluster

  • Your job will take 10 hours to complete.
  • Your cluster will be utilized for 10 hours out of each month and will remain idle for the remaining 720 hours.

Option 2: Build a 100-node Hadoop cluster in the cloud

  • Your job will take 1 hour to complete.
  • Your cluster will be terminated after the job is complete, and you will only be charged for the compute resources used.

With Option 2, you can gain access to the same tools everyone else has at a fraction of the cost. There is no need for a multi-million dollar data warehousing solution. RightScale and our partner, IBM, offer a solution for performing intensive business analytics, batch processing, and grid computing in the cloud of your choice. IBM has developed a set of RightScale ServerTemplatesTM for its Hadoop-based BigInsights product. The best part is that the BigInsights Basic Edition ServerTemplates are available at no charge for data sets up to 10 TB. IBM also offers BigInsights Enterprise Edition ServerTemplates, which include many additional tools and features. These ServerTemplates are available in the RightScale MultiCloud Marketplace.

Want to learn more? Here’s a tip: There is a wealth of training available for free at Big Data University. If you are currently using big data (or plan to), we’d be interested in learning how you plan to use it. Let us know.

Posted in AWS, EC2 | Tagged , , , , | 1 Comment

Managing Cloud At Scale: Configure Systems not Servers

Posted on March 6, 2012 by

RightScale works with customers that manage some of the world’s largest public and private cloud deployments –understanding their needs to manage at scale is what drives the development of many our automation features. These valuable features don’t necessarily make it front and center on our marketing website because they are complex and hard to explain to people who are new to the cloud. But they’re just as important, if not more important for the regular day-to-day operations of a cloud admin. I’ll review a few below, including some items that were just released last week.

Making the System Adjust Itself

First, let’s look at one that’s been out there for a little while on version 5.7 of our RightLink agent – the ability for a server to call a script on a different set of servers. Let’s say I’m running this command from a boot script on an application server:

% rs_run_right_script -n "Register App Server" -p "IP_ADDRESS=text:10.100.250.200" -r "provides:type=proxy"

In layman’s terms, this means “find all the proxy servers out there, and run the ‘Register App Server’ script passing my IP address.”  The script will run on the proxy server and register that new app server’s IP address to the available app server pool. On the flipside, the application server can call a “Deregister App Server” script when it is terminated to remove itself from the pool.

So if you need an army of new app servers, you can simply click a few “launch” buttons (or adjust the size of a RightScale array), and voila, the system adjusts itself as the servers become operational. In other words, we don’t just spin up new instances, we help you code how the overall system should behave. (Oh, and this works on Windows too!)

Pushing a Single Change to the Whole System

I know you sysadmins out there write bug-free scripts.  But let’s just say you found a bug in a script one day (we’re talking hypothetical here), and realized that script was being used by 10 images, and these images were behind 100 servers. Now you have to create all new images and cycle all those instances at some point. There is a high possibility for mistakes when you have to manually hunt down and update all these images and instances.

With last week’s release, we completed a request that was at the top of our feedback forum to help with just this (see requests here and here). Now, with a click of a few buttons in our UI, you can queue up this change for all your servers, and have a complete record of what each ServerTemplate and Server is now using.

Here’s a glimpse into this “bulk update” capability. Just click “Update Selected” on both screens below:

Bulk Update ServerTemplates - Managing Cloud at Scale

Bulk Update Servers - Managing Cloud at Scale

…and then you’re done.

Configuring Systems

Finally, and also with last week’s release, we made it even easier to configure your entire system at once. As you specify the variables you need to define for your system, you can also specify the categories these variables belong to (see original feedback here). Furthermore, you can even specify that some variables are advanced – hiding them from view for most users who may never need to manipulate them. This allows you to focus on just the area you wish to change within your system when editing the configuration, and not on some giant list or JSON file.

Edit Inputs at Deployment - Managing at Scale

More to Come

Since RightScale is a SaaS platform, we can continue to evolve our ability to manage cloud computing at scale and roll out new features to all of our customers with each release.  Please keep the feedback coming, and we’ll keep making your cloud life easier.

Posted in EC2 | Tagged , , , , | 1 Comment

RightScale Server Orchestration and Amazon SWF launch

Posted on February 22, 2012 by

The launch of Amazon’s SWF (see also Werner’s blog) is a good opportunity to talk about some of the exciting new automation features that we have in the works and we will make available with the coming releases. We’ve been using SWF as one of our back-end services for a number of months and it’s a pretty awesome service that greatly accelerated the development of our orchestration features. In my mind, automation is the most fundamental innovation in cloud computing. It enables all the business benefits (pay as you go, scale on demand, resiliency, predictability, etc.) and it lets us increase the scale at which we use computing as well the reliability of services. Cloud computing is inconceivable without automation throughout the entire stack.

RightScale has focused on automation from day one. We provided auto-scaling of server arrays early on: automatically launching and terminating servers based on monitoring metrics, such as cpu load. Something most newcomers don’t appreciate is that making the call to launch the next server when the cpu load goes up on the running ones is not the difficult part. The difficult part is bringing the new servers into full operation. That involves loading all required software, configuring everything, and connecting the server with other services, such as load balancing and the databases. This is why a big piece of the RightScale functionality concerns itself with configuration management and automating the entire boot process all the way to the point where the application is in production.

With coming releases we are continuing to build on top of this platform and introduce server orchestration. Server orchestration uses a workflow language that lets you automate at the level of RightScale resources, such as servers, deployments, etc. The first functionality we implemented is to let you customize the three key pieces of auto-scaling: (1) deciding when to scale up or down and by how many servers, (2) launching new servers, (3) terminating existing servers.

The way this works is that the RightScale system calls a user-defined decision function every minute to find out whether the server array should be scaled up or down and by how much. The decision function simply returns an integer that indicates how many servers to launch (value >0) or to terminate (value <0), or a value of zero to keep the server count the same. The decision function can retrieve monitoring data using our API and do a calculation similar to the built-in one or it could do something completely different. An interesting example would be to use knowledge of application specific state and metrics to better predict requirements. You may be able to tell early that a flash event is coming and that you need to launch a large number of servers all at once. That’s just one example, the sky is really the limit and I know some of our customers have pretty cool ideas in this area!

When the decision function asks for more servers, RightScale runs a scale-up workflow to actually launch the servers. This puts you in control of how the servers are to be launched and creates an interesting opportunity to carefully manage where the servers are launched. For example, you may want to ensure your servers are equally spread across a number of datacenters for availability reasons. Or you may want to launch where it’s the cheapest. Very similarly, the scale-down workflow can be picky about which servers are being terminated. In the built-in auto-scaling we terminate the oldest servers to ensure a continuous refresh of the running stock. But for some applications it’s preferable to terminate the youngest servers. In addition, the scale-down workflow can gracefully shut down the application, take a last backup, save away log files, and then terminate the server.

As we designed the orchestration functionality we kept coming back to two key requirements: concurrency and fault tolerance. We need to express concurrent activities with ease because, when one operates on many servers, it’s the only way tasks complete in a reasonable amount of time. For example, to perform a rolling upgrade on a number of servers the orchestration ought to grab a set of servers, run them through the upgrade process in parallel, and then move on to the next set.

Where orchestration becomes really exciting is when it is used to recover from failures and automatically relaunches failed resources, possibly in a different datacenter or cloud. That immediately raises the question about the resiliency of the orchestration process itself: what if it is affected by the same broader failure and can’t perform the recovery? Similar concerns arise when an orchestration process runs for a long time. The array auto-scaling example above could be implemented using a “parent” workflow that runs forever and invokes the decision function and scaling sub-workflows periodically. And again, this execution must be resilient to failures.

In order to provide good support for concurrency and to offer a fault-tolerant execution environment we decided to base our orchestration system on a workflow language that is built around the open source Ruote workflow system. Ruote offers a multitude of very nice structured concurrency constructs. For example, you can express strategies such as “run concurrently and wait for all” or “run concurrently and wait for the first, then cancel the rest”. The latter may sound unusual but it’s useful when you need a resource and you want to try multiple avenues and pick the first one that succeeds.

Amazon SWF came in very handy to ensure fault-tolerant execution of the Ruote workflows. We retargeted Ruote to leverage Amazon SWF as an execution back-end with the result that workflows are executed by many servers distributed across multiple availability zones. SWF takes care of scheduling the execution of workflow actions, collecting the results, and then atomically handing the results back to Ruote so it can schedule the next wave of actions. The result is a highly resilient orchestration system that can continue the execution of workflows in the face of major failures.

We’re obviously very excited about the upcoming features and can’t wait to make them available to our customers. Now that Amazon SWF is live we’re on the home stretch and hope to be ready for a private beta shortly after the upcoming release. If you’re interested in early access, please send me an email.

Posted in AWS, Cloud Computing, EC2 | Tagged , , , , , | 14 Comments

Get more out of your cloud with RightScale and Citrix CloudStack 3

Posted on February 13, 2012 by

RightScale has been integrated with CloudStack since 2010 and we jointly run many of the world’s largest production cloud deployments. Last year’s acquisition of Cloud.com by Citrix marked a new beginning for a relationship that, coupled with the RightScale multicloud management platform, would provide unprecedented value to our end customers. We are pleased to see this morning’s release of CloudStack 3, which brings an integrated offering towards that vision.

RightScale cloud management provides a ‘single pane of glass’ to private and public cloud resource pools where administrators can provision and launch servers in a matter of minutes. In June of 2011, we launched our hybrid cloud product called RightScale myCloud to further deepen our integration with CloudStack’s private cloud infrastructure solution. With today’s announcement, myCloud will incorporate the CloudStack 3 enhancements and make the process of implementing and building a private cloud easier while offering more choice.

Let’s examine a few key features of the CloudStack 3 release and what they mean for RightScale customers using Citrix CloudStack technology.

Storage

Before, most customers were either using off cloud storage mechanisms in their CloudStack deployments, or using a public cloud storage engine, such as Simple Storage Service from Amazon or Cloud Files from Rackspace. Now, with Swift integration, customers will have the option to use their own storage with RightScale.

Networking

We often see our customers require complex and custom networking configurations within their deployments and clouds. Having more flexible networking configurations, specifically the catalog of networking services along with NetScaler integration, when constructing their deployments will enable additional use cases and capabilities that can be automated with RightScale.

Our integration with private cloud infrastructure partners gives RightScale the ability to focus solely on multicloud management. With RightScale myCloud you can manage multiple private clouds in your data centers and link these with public clouds. You can scale across your clouds and back up or failover among them. You can configure, monitor, and operate all of your cloud resource pools from one Dashboard and API — choosing from global public clouds such as Amazon, Rackspace, SoftLayer and many others.

To find out more, view our webinar with Forrester Research about how to get started managing a private and hybrid cloud. We also offer a free trial of myCloud with CloudStack, to get started you can contact us here or visit us at the Cloud Connect show this week in Santa Clara – we’re at booth #604.

Posted in CloudStack | Tagged , , , | 7 Comments