Systems administrators who have lived through this conversion process often ask us whether RightScale offers any virtual-to-cloud tools that similarly forklift servers from a virtualized environment to a cloud. We don’t, and a better question is what the business benefits of such a tool would be.

Image credit: @VRider

The big benefit of forklifting physical servers into a virtualized environment is utilization. Virtualization allows organizations to share a physical server across many applications that formerly each underutilized their own physical box. The result was a significant savings thanks to increased utilization (and standardization) of hardware. Unfortunately there is no similar one-to-one gain to be had from forklifting servers from a virtualized environment to the cloud.

The benefits of the cloud are at a different level. Drawing from the NIST definition of cloud computing, the essential characteristics of a cloud are on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. But these are benefits for provisioning net new workloads – the cloud provides minimal value for migration of existing applications that run in a static fashion 24x7x365.

Cloud computing puts more of the decision-making, such as when to launch servers, closer to the end users of the compute resources. At a technical level, it shifts more of the responsibility for handling failures to the application architecture level. No conversion tool is likely to be able to help you take advantage of these benefits. In fact, forklifting virtual servers to cloud instances would most likely result in a reduction in the service quality because there would be a mismatch between the assumptions made by virtualized application deployments and the properties of the cloud.

Clouds allow for infrastructure resources to be provisioned on demand with dynamically assigned IP addresses based on application load. However, data center operators are used to being able to choose the exact hardware they want to provision, down to the exact clock frequency of the CPUs. In addition, they have historically been able to choose specialized hardware such as GPUs and high-speed network and storage subsystems based on application needs. Clouds typically do not offer this level of flexibility. They are designed to provide generic, commodity hardware resources for broad consumption. Things as simple as assigning multiple network interfaces, static IP addresses, VLAN isolation, and shared storage have been commonplace in data centers for years, yet are not available from most clouds today.

One of the primary drivers for moving to cloud infrastructure is hyper-standardization of infrastructure configurations. Unfortunately, this does not come without a cost. Clouds offer predefined configurations with specified amounts of CPU and memory resources, which requires application architectures be designed for the infrastructure resources available, rather than allowing the infrastructure to be customized to fit the needs of the application.

As an example of how the cloud demands a new kind of planning, consider network addressing. Applications have historically been provisioned in data centers using static IP addresses. The assumption was that the infrastructure would be designed for high availability and would rarely fail. If an app required additional resources, an admin would add them to the existing VM without changing IP addresses. By contrast, clouds assign IP addresses to VMs dynamically by default, and VMs must be re-created to add additional resources.

On the flip side, applications that are designed with a loosely coupled architecture can benefit significantly from cloud infrastructure – we have a white paper on this. A loosely coupled architecture typically includes many tiers of applications with load balancers and queues in between. This allows for dynamic, horizontal scalability, without requiring high-performance, highly reliable, and ultimately expensive hardware resources. This architecture works well with any application that takes advantage of a queuing system, or anything designed to leverage automation to take advantage of ephemeral infrastructure resources. If the service you want to access is not available, the data or work object sits in a queue until the appropriate service is available. The rest of the system can continue to function without coming to a standstill due to the outage of a single component. Thus the cloud provides much more potential than VMs on demand. With the proper level of automation, the infrastructure can actually be application-aware and adjust as application requirements change over time. This is the true power of the cloud, and is a key driving force behind the DevOps movement.

You can get the greatest benefit of cloud from applications designed with a loosely coupled architecture, and your time will be best spent focusing there. As we saw during the transition from mainframes to client/server, a new generation of applications will be designed to take advantage of cloud infrastructure. The benefits the cloud provides will appeal to users, who will migrate to the new apps over time.

As for your legacy applications, I recommend the “if it isn’t broken, don’t fix it” approach. If they run well today, why move them to the cloud? Let them continue to run where they do today – but plan to provision new apps in the cloud.

In the previous post in the series, I described automating a build and deployment process using Team Foundation Server, Windows Azure, and RightScale to establish a base process that’s automatic and repeatable and that yields a working test environment. Now, using that same process, I’ll push the envelope and show you how to stay up-to-date with the latest OS images and patches, and how to test a wide variety of configurations. Although there are a number of ways to manage this process, including custom RightScripts^TM, I’m going to focus on the process of managing updates via the RightScale-provided scripts and via RghtScale ServerTemplate^TM versioning.

Patch-Level Testing Made Easy

RightScale ServerTemplates for Windows include a number of Windows Update and patch-level processes that you can utilize while a server is running. For instance, looking for a way to figure out what was released when? Check out kbupdate.info, which catalogs updates per OS by time and alphabetically.

RightScale includes a number of scripts that are included in the Base ServerTemplate for Windows that you can leverage to handle general Windows patching and updating:

Out of the box you’re able to control Windows Update policies (Set Policy and Install All Updates) as well as Windows Firewall configurations (enable and disable). With these you can pull all of Windows’ major levers related to security. Perhaps the most interesting script gives you the ability to apply specific KB article updates to your machines. This is immensely helpful when you update to a new base image and things break from an operational perspective, or if you run Windows Update and you encounter issues with your custom application. To address this issue you can roll back to the latest known good configuration and reapply each update one by one via the Sys Install Microsoft update by KB number RightScript. You can add this script to your ServerTemplate’s boot sequence too if you need to apply specific patches in your next ServerTemplate revision.

Image Upgrades and Image-Level Testing

Using the All-in-One ServerTemplate that I introduced in the dev/test process, it’s simple to test OS and configuration-level changes by swapping out MultiCloud Images^TM (MCI) behind the scenes. Here’s how it works:

When you launch a server within RightScale, the ServerTemplate has a default MCI, but you can specify another one:

When new OS versions and patch levels are released (not only for Windows but also for Linux), the RightScale engineering team releases new revisions of the affected MultiCloud Images that include the latest patches and security updates. You can even use unrelated OS images within the Advanced Options section to test new or different images:

With this self-service feature, you can provide solid, approved, and hardened assets via committed and versioned ServerTemplate configurations, and also test new patch levels, different images, and even new and different operating systems with ease.

Taking It to the Team

Whether you’re meeting a request from the dev team or you’re looking at implementing a new set of custom security patches, you’ll want to take your patch or image-level updates and codify them in a new revision of the ServerTemplates that your teams use. The RightScale Support site has great documentation on managing updates to ServerTemplates, which will get you started in building out a structured infrastructure development lifecycle that works within your company’s IT process and software development lifecycle. For more information on managing your own ServerTemplates, we have another excellent guide that outlines the process of getting started and managing the assets moving forward.

As I’ve mentioned in earlier posts, I’m presenting a webinar to demonstrate some of the key points in this process using Visual Studio, Team Foundation Services, Windows Azure Virtual Machines, and RightScale. I hope you’ll sign up for the webinar and join me on May 21.

To try customizable pre-built RightScale ServerTemplates for dynamic configuration, including an out-of-the-box scalable three-tier .NET deployment, get a free trial of RightScale.

Organizations, Appleby suggested, need to consider an efficient approach that includes bringing high-performance applications close to users, and taking non-performance-critical applications to “the hinterlands, where power’s cheap and costs are down.”

In today’s interconnected world you can choose where to host your applications. At the edge, close to users, Appleby said you should put the deployments that require minimal latency, using highly distributed network nodes placed globally. The rest of the data center architecture becomes multi-layer, with compute farms located where power is cheap, and aggregation nodes somewhere in the middle.

Application delivery network providers such as Riverbed and Akamai that deliver optimized IP VPNs to the edge of the network are key drivers for onramps to the cloud, Appleby said. Instead of bringing the last mile of the network to an organization’s site, the new model becomes one of using the data center campus as a hub for applications that need to provide sub-millisecond responses.

Merging the cloud with data center infrastructure is where things are evolving, Appleby said. Data center campuses are becoming hubs for legacy networks and data centers, offering 10G inter-campus cross-connects, where anyone coming into the campus can connect directly to anyone else that’s there. Appleby said old-style colocation data centers have transformed into the center of a mesh where all kinds of connectivity happens. Organizations will use their private networks as on-ramps to these campuses, and the campuses will be the foundation for software-defined networks.

CoreSite launched an initiative called Open Cloud Exchange to give organizations a choice of cloud service providers at the network, infrastructure, service management, and onboarding layers, focusing on high-performance hybrid and multi-clouds. As the carriers boost their core capacity from 10G to 100G, they will install their equipment in data center campuses first. Open Cloud Exchange facilitates direct connection to data centers from organizations’ Ethernet. Appleby advocated leveraging the performance and security of private clouds with the scalability of data center campuses to optimize total cost of ownership.

In choosing a set of providers, Appleby advocated that organizations consider capacity, connectivity, community, and customer experience. He said they should use a multi-tenant data center that can provide secure private networking as a way to enhance the enablement of hybrid clouds. You can find out more about implementing a successful hybrid cloud strategy in the RightScale Hybrid Cloud White Paper.

All organizations, by using the cloud, gain the advantages of no up-front capital expense and a relatively low-cost and self-service infrastructure that’s easy to scale up and down. Users also only pay for what they use, all of which lead to improved agility and time to market. These same benefits also apply to fault tolerance in a cloud infrastructure.

Many of AWS’ services, including S3 and Elastic Load Balancing (ELB), are inherently fault-tolerant, while others, such as Elastic Compute Cloud (EC2), Virtual Private Cloud (VPC), and Elastic Block Store (EBS), are fault tolerant to the extent that AWS customers choose to architect them. Customers can build in redundancy by geographic area, facility, deployment, resources, and more. Ward also noted that RightScale is especially valuable in managing those types of fault tolerant configurations.

Ward talked about a recovery time objective (RTO) – a time period in which service must be restored to meet business continuity planning objectives – and a recovery point objective (RPO) – an acceptable data loss as a result of a recovering from a disaster or catastrophic event. The two may be at odds, so the goal is to figure out the best RTO/RPO ratio, and in that decision, cost is a huge factor. Application owners must balance the cost and complexity of HA efforts against the risks they are willing to bear.

Best practices for HA that Ward suggested include avoiding single points of failure, using at least two availability zones, replicating data across AZs and backing up and replicating across regions for failover and disaster recovery, and setting up monitoring and alerts to automate problem resolution and failover operations. He advocated designing for failure: Use DNS to support multiple load balancers that send traffic to multiple app servers that use a replicated master/slave database setup that is backed up by S3 spread across two AZs.

One tool Ward highlighted was a new EC2 VPC feature. Elastic Network Interfaces (ENI) can have as many as 16 IP addresses and participate in multiple networks. ENIs let you move virtual NICs from one instance to another.

A multi-zone architecture designed for high availability

He also introduced a new tool called Storage Gateway that is designed to promote data availability. Storage Gateway runs on-premise connected to your application servers via iSCSI and replicates as much as 150TB of local data to S3. The data is stored as EBS backups, so you can easily restore them to another on-premise server, or you can create a new EC2 instance and get immediate access to the data in the cloud.

Cutline: AWS’ new Storage Gateway

Ward said to mitigate risks, organizations should assess each application and define its target RTO and RPO. Design for failure, starting with the application architecture. When you implement, factor in cost, complexity, and risk. Automating the processes is critical – and again, that’s a place where RightScale shines. You can use dynamic DNS for your database servers with a low time-to-live (TTL) to allow rapid changeover in the event of a failure in a database server and set up automatic connection of your app servers to your load balancers so that they require no manual intervention and no DNS modifications. You can automate promotion of a database slave to a master, but Ward recommends testing that automation vigorously.

In fact, Ward advocated vigorous testing of your entire cloud infrastructure. For instance, he said, you can have a “game day” when half of your staff does nasty things to try to break your testing instances and half work to fix them, while a small group of engineers takes notes on what each side has learned.

Once you have your automation set up and ready to use, make sure that the decision to use it is manual. Because every instance is different, someone needs to be responsible for determining whether your business situation demands deploying a particular disaster recovery plan.

Ward noted that RightScale’s MultiCloud ImagesTM (MCI) make it possible to launch instances across regions without modification. Each ServerTemplateTM contains a list of MCIs, and when you create a server, RightScale chooses the appropriate RightImageTM to launch. RightScale gives you nuanced configuration options for the individual parts of the servers that you deploy to aid in the automation process.

Bottom line: AWS provides powerful tools to promote high availability and fault tolerance, and RightScale delivers an advanced set of cloud management features that enable you to take better advantage of what AWS provides.

To do that, says Director of Engineering Chris Szymansky, “you want to iterate on your architecture, not perfect it.” The Resumator’s three-tier architecture includes front-facing load balancers backed by application servers that access a data tier at the back end. The company uses RightScale to manage production, staging, and development deployments, as well as deployments for individual regions. A deployment, in RightScale terms, is a cluster or group of servers that work together and share common input variables and cloud configurations. “The great thing about RightScale,” Szymansky says, “is that you can customize and tweak the setting for the instances as needed, and you don’t have to be super-technical to do it.”

The Resumator’s three-tier architecture

The Resumator uses benchmarking services to determine how its applications are performing, and when the load hits a defined trigger point, it scales its architecture as needed. “As we see traffic coming into our servers,” Szymansky says, “we can automatically scale the app tier up and down.”

During a talk at the RightScale Compute conference, Szymansky walked an audience through his team’s process for modifying and deploying software. They use Jira for trouble tickets and tag code using Git to associate it with a release. RightScale lets users save executable code in RightScripts™, so the engineers can use a RightScript to check out code, get it into the testing environment, and kick off a series of tests, for which they log the results. If all goes well, the RightScript can move the tagged release to deployment.

The engineers also use RightScripts to create custom dashboard graphs for the Varnish web cache tier, as well as to provide easy configuration management for hot-loading back-end servers for the web accelerator application. That makes it easy for them to add warm cache options for high availability for their caching servers.

Recently, the company ran into a bottleneck during document processing. It converts all resumes into PDF format, extracts the text from them to make it searchable, stores the data using S3, and displays the formatted resume to its customers. To do that, the engineers used a MySQL database and ran a cron job to send the resume to a third-party service to extract the text.

Unfortunately that architecture didn’t scale to handle the increased volume of resumes, so the engineering team replaced the cron job and MySQL with a simple queuing system implemented in Redis and managed with RightScale, which the engineers can spin up to feed requests from the application servers to the database tier of any of the company’s deployments literally at the click of a button.

At initial rollout, the new queuing system handled 30,000 jobs a day, and end-user and app server response times improved by 25 percent compared to the old approach. The engineers have since used the queue for other types of jobs on the back end, which allows them to handle the site’s traffic growth with essentially the same infrastructure.

Szymansky says The Resumator did similar work to optimize caching and Apache Solr, and will no doubt attack other pain points in the future: “It’s about always looking at what’s the next thing we need to address.”

The Resumator participates in the RightScale Customer Advisory Group (CAG), an invite-only group that acts as a sounding board for the new features and capabilities that we’re building, gets access to alpha and beta releases, and earns some RightScale swag — as modeled by the DevOps/SysOps team and CTO.

To see how The Resumator and hundreds of other SaaS vendors are benefiting by running their software applications in the cloud with RightScale, request a RightScale demo.

Anderson focused on two of the core components of Google Cloud Platform: Compute and Storage. The Compute component includes GCE, which is an IaaS platform, and App Engine, a platform for developing and hosting web applications. The Storage offering includes Cloud Storage and Cloud SQL.

GCE in particular is designed to run any application on Google’s infrastructure. It offers scalable processing and storage and fast networking. While it’s still officially in beta, Google itself uses GCE for dozens of projects internally. However, because it’s in beta, Google schedules maintenance windows of up to two weeks every 20 weeks, one zone at a time. When you use the recommended multi-zone architecture, RightScale makes it easy to migrate your servers between zones when necessary.

Everything in GCE is built atop the same JSON REST API. You can access the API from a command-line tool called gcutil, several GUIs (including ones from both Google and RightScale), and libraries for 10 different languages.

The virtual machines that GCE uses offer one, two, four, or eight CPUs, and three available memory sizes: standard (3.75GB), highcpu (0.9GB), and highmem (6.5GB). Unlike Google App Engine, the VMs are not locked down – customers have root access to their VMs. Internet connectivity uses Google’s fat pipes, with built-in firewalling. Every project (a project comprises VMs and their associated objects) gets its own private network with internal DNS naming so that you can use SSH to connect to named machines. After you have authenticated to Google once via SSH, you should never need to supply a password again to access a guest OS.

GCE offers three storage options. Persistent disk is triply replicated in the same zones that your virtual machines are in and remains in place even when the VMs themselves are not running. You can use local disk as scratch space. Finally, cloud storage is a blobstore (or object store, or key-value store) that you can share with the world. It can store any amount up to terabytes of data. In addition, since GCE has Internet connectivity, you can connect to any storage resources located anywhere.

GCE lets you create a persistent disk from a stored disk image, and you can add persistent disks to and remove them from a running VM. You can launch a VM from a persistent root disk. You can also take snapshots of existing persistent disks and restore them across zones and regions, which can work well with GCE’s ability to attach a single read-only disk to multiple VMs.

Each VM is isolated, from every other, and Anderson says isolation between workloads is key to GCE’s predictable performance. If you use scratch storage, your spindles are dedicated to your use alone. In addition, all data is encrypted at rest. Speaking of security, service accounts give you frictionless OAuth 2.0 access to authenticate from GCE VMs or App Engine apps to other Google APIs.

And speaking of predictable performance, Anderson says GCE lets you hot-add and hot-remove external IP addresses from running VMs and move them across zones, which can be helpful if a machine with a static IP address starts having problems.

After outlining all the features of Google Cloud Platform, Anderson offered a demo during which he started 200 VMs via the Quick Start UI, an App Engine app, in a minute and 37 seconds.

He also noted that when MapR broke the Terasort benchmark record last year, it did so by spinning up a thousand four-core GCE VMs, which it could do in a matter of minutes. By contrast, the old record-holder took months to build a dedicated cluster to run the benchmark.

Cloud Storage

Cloud Storage complements the Compute component of the Google Cloud Platform, and serves as the glue between all Google Cloud Services. Cloud Storage is an HTTP service that serves data directly over HTTP. It has strong read-after-write consistency – no waiting for the data to be replicated. It offers streaming uploads and resumable transfers of objects up to terabytes in size. It serves static data directly via HTTP. It supports two APIs – the same JSON and OAuth 2.0 API GCE uses, and a second that’s compatible with other cloud storage providers such as Eucalyptus and AWS S3 that use XML. Cloud Storage also lets you use signed URLs to delegate access to storage to non-authenticated users.

Behind the scenes, Google replicates Cloud Storage to data centers spanning multiple geographically diverse locations, and makes it accessible via Google’s worldwide network. All hardware is fault-tolerant, and the platform itself can scale up or down to meet varying needs.

Get a Fast Track to Google Compute Engine

GCE generated a lot of interest at RightScale Compute – Anderson’s session was standing room only. If you’re a RightScale customer, GCE is available to you today. If you’re not, find out about special introductory rates for new customers who sign up by September 30. Request more information about RightScale management for GCE.

On my way back from OpenStack Summit 2013 in Portland, where I spoke on Techniques for Managing your OpenStack Cloud, I had this exact experience. I knew it instantly — I was stranded. Of course, I’d missed flights in the past, I’d been delayed, you name it. But this time the flight I missed was the last one out for the night, with no other connecting flights to anywhere close to my destination.

My first reaction was “the infrastructure failed me.” I had done everything right, from booking my tickets to arriving on time and making it through security. Unfortunately that wasn’t enough, since forces beyond my control impeded my ability to travel successfully.

In reality, though, the infrastructure is fairly reliable, and the sorts of delays I encountered are not uncommon. For the most part, the travel infrastructure gets you where you’re going pretty close to your scheduled itinerary.

Using cloud resource pools is very much the same. Any given resource pool generally runs on commodity hardware, is generally available, and usually gets the job done with acceptable levels of performance. But sometimes something goes wrong and application performance degrades. Worse yet your application becomes unavailable!

Planning for Failure

I could have proactively planned around the failure of the travel infrastructure that day in a variety of ways, and they all have parallels for organizations that need to plan for their clouds’ availability. Each option had different costs and a different likelihood of success.

Cold Disaster Recovery

By far the least expensive option (and the one I ended up invoking) was to simply assume my itinerary would work out as planned. If something should happen, I could pay for a night in an airport hotel and get the next flight. I would only spend money if something went wrong, but I would get delayed by several hours.

This is like a cold DR (disaster recovery) plan for your cloud application. If you choose cold DR, you must have a plan in place to quickly launch your application on infrastructure that is not impacted by an outage. You incur no cost unless you have to invoke your DR strategy. But your recovery time objective (RTO) — the maximum time you want to allow between failure and renewed availability — is high, because it can take a significant amount of time to bring up your application infrastructure and switch over to it. You also potentially have a high recovery point objective (RPO) — that is, how much data, measured in time, you can afford to lose – in that you have to rely on copying data from your production infrastructure, or a backup from some time in the past.

Warm Disaster Recovery

If I were willing to accept a longer travel time in the case of my main itinerary failing, and I were willing to pay for a backup plan, I could have a standby ticket booked on a train or bus. This would still get me home, though more slowly, and since I’d already booked the ticket I would be able to make use of it the moment I discovered that my air travel wasn’t going to work out. It would still be inconvenient but I would get to where I was going pretty quickly and effectively.

In this case, the cloud application parallel is warm DR, where a replica database is kept running in a different resource pool, ready to take over should the primary resource pool have a problem. With warm DR RTO is still medium to high, since it still takes time to launch all of the other servers for your application, but your RPO is very low, or potentially zero.

Five Nines

Finally, I could have booked two completely different itineraries on two completely different airlines, through different airports. If my primary flight were delayed I could have instantly chosen to execute the alternate itinerary. Obviously this is the most complex and by far the most expensive option. I might consider using this option if money were no object and I needed to be home that night to have an anniversary dinner with my wife. I couldn’t be delayed, and missing it would be inexcusable. Any cost would be acceptable to ensure that I arrived on time.

In the context of your cloud application, this is like the “five nines” infrastructure, where all tiers of the application are running simultaneously in two or more locations with real-time replication between them. The cost can be extraordinary, but for certain workloads the cost of any downtime outweighs the operational cost.

Don’t Leave Your Apps Stranded

When I missed my flight I had to stay a night in an airport hotel and catch another flight early the next day. It was an inconvenience, but I survived. The lesson for me was to plan better for failure and give myself a bigger buffer of time for connections.

The lesson you should learn for your cloud application is that failure happens all the time. Have an availability strategy in place that matches with the demands of your application. Spend the money you need to meet the RTO and RPO goals that make sense for your application, and be honest with yourself about what sort of outages are acceptable.

Using cloud computing to its fullest potential requires a fundamentally different approach from what you might be used to. The good news is that RightScale can help you with the tools and expertise you need to be successful, and empower you to do things you would have never attempted in a traditional or virtualized model.

Take full advantage of the power of cloud computing, plan for failure, and don’t leave your apps stranded!

You can view the video of my OpenStack presentation above, and to learn more about how RightScale can help with your disaster recovery plan, request a demo.

Organizations are increasing cloud adoption at the same time DevOps is taking hold in many organizations. DevOps is a software development philosophy and practice that involves collaboration between operations teams and developers to increase agility and deliver applications to market more quickly. More than half (54 percent) of all respondents to our survey have adopted DevOps. The findings also reveal that higher levels of cloud maturity in an organization correlate with adoption of DevOps. In the figure below, we ranked organizations by their level of experience with cloud. Seventy-five percent of Cloud Focused organizations are leveraging DevOps, versus 41 percent of Cloud Watchers.

The obvious explanation for this connection is that both initiatives, cloud and DevOps, focus on enabling IT agility. By leveraging both together, organizations can multiply the impact and deliver products to market more quickly.

One key practice of DevOps is to test the requirements of production environments from the very early phases of application development. This practice requires that organizations quickly create environments for developers that mimic the target production setup. To meet this goal, more and more organizations are replacing traditional scripting with more flexible configuration management tools, such as Chef and Puppet, to set up and maintain production-like technology stacks for their developers.

The survey found that 33 percent of organizations are using Chef or Puppet. Among those adopting DevOps, the number is higher at 48 percent. The survey found several interesting factors that impact the relative adoption of Chef and Puppet. Chef is more popular than Puppet with SMBs — 23 to 15 percent adoption. But that difference is reversed in enterprises — Puppet leads 28 to 21 percent. Among developer respondents, Chef has the edge on Puppet 24 to 14 percent, but among operations respondents, Puppet leads 24 to 20 percent. It appears that both solutions are making inroads to adoption, but each appeals more strongly to slightly different types of organizations and users.

The Bottom Line

The RightScale State of the Cloud 2013 survey offers interesting insights for any organization considering or already implementing cloud computing. One of the most important takeaways is that more cloud adoption unlocks more cloud value. As cloud usage increases within an organization, organizations report more benefits and fewer challenges. Each organization’s journey to realize the full value of cloud will take many steps and will evolve over months and years, but cloud adoption will deliver more value at each step along the way. RightScale aims to be there to help customers unlock that value.

By the way, when we say industry professionals, we don’t just mean the technology industry. The survey respondents came from a variety of industries, with half coming from technology-focused companies and half came from a wide variety of other industries, including media, financial services, and education. Respondents were a mix of development staff as well as  IT and operations, with almost one in five respondents coming from the business side.
 

Last week we noted that one of the key findings of the report was that the cloud is a given for organizations of all sizes today. Three-quarters of organizations are adopting cloud, and are at various stages of maturity in their use of cloud. Segmenting respondents based on their cloud maturity reveals that as organizations adopt cloud more broadly, they realize increasingly more value.

As organizations progress in cloud maturity, the workloads they deploy in the cloud get increasingly broader. While development, test, and customer-facing web applications continue to be the top workloads deployed by companies across the maturity spectrum, other workloads are not far behind.  More than 50 percent of organizations that are Cloud Focused are also running internal web applications, batch processing, and mobile apps in the cloud.

Going hand in hand with the growth of the types of cloud workloads, we see that the benefits organizations report from cloud also increase with increasing cloud maturity. Organizations indicate that the top benefits they have already realized are faster access to infrastructure, greater scalability, and faster time to market for applications. These top three benefits are reported by more than 25 percent of Cloud Beginners, more than 50 percent of Cloud Explorers, and more than 80 percent of Cloud Focused organizations.

As organizations move toward more experience with the cloud, more than 50 percent report such benefits as business continuity and increased application availability, better application performance, expanded geographic reach, and increased IT staff efficiency. These findings show that cloud benefits are not only a future expectation, but also a reality today for many organizations.

In addition to an increase in reported benefits, the challenges of cloud show a sharp decrease with cloud maturity. Across the board, organizations with more experience in cloud report fewer challenges with security, governance, compliance, and integration.

As an example, while security is the most-cited challenge, the percentage of organizations that report that security is a significant challenge decreases from 38 percent of Cloud Beginners to 18 percent of Cloud Focused. In other words, the more you learn about how to work in the cloud, the more you understand how to address these issues and the less likely you are to see it as a significant challenge.

Cloud experience also pays off in handling inevitable outages associated with any data center – whether cloud or private. While news of cloud outages inevitably makes headlines, the reality is that in 2012 there were fewer publicly reported cloud outages than private data center outages. Not surprisingly, as organizations increase their usage of cloud and expand workloads, they are more likely to report being impacted by a cloud outage. However, organizations with more experience report that the impacts of those outages were of shorter duration, indicating that they have learned to architect for these situations and put failover and disaster processes in place to reduce their impact.

With increased benefits, fewer challenges, and fewer outages, increased cloud maturity clearly unlocks increasingly higher levels of value.

We have a few more points to talk about next time that will interest anyone who follows both DevOps and the cloud. To read the complete survey results, see the RightScale State of the Cloud Report 2013.

Friday began with a customer spotlight (watch the video) that featured three prominent RightScale customers. Joe Emison, CTO of BuildFax, began the session by talked about setting up a hybrid cloud environment and optimizing storage and networking while using both CloudStack and AWS. BuildFax uses five ephemeral virtual machines for processing incoming data sets, and kills them when each set is done. Its original cloud deployment was on AWS, but the bill was higher than the company could afford. BuildFax wanted the high availability and disaster recovery benefits of a hybrid cloud architecture, and wanted to use some commodity hardware it already had on hand. The company knew its hardware would fail from time to time, so it needed to be able to fail back to AWS as needed.

BuildFax implemented a hybrid cloud using AWS, CloudStack, and AWS Storage Gateway. Data gets stored in S3 and the company pulls EBS volumes off as needed, and RightScale ServerTemplates™ with Chef are used to manage it all. The company was able to cut its EC2 bill in half, and Emison thinks it can cut it more by running more variable loads in the private cloud. It has a better business continuity plan because it is not solely reliant on AWS US East, and if the company’s own office building burns down, it can be back up in 20 minutes. “AWS is essentially a warm backup that only costs us $200 a month.”

Key quote: “Multi-cloud is about people cost-savings as well, because you don’t need people at 4 a.m. to get your systems back up if you go down.”

Next, Roy Ellis, principal QA engineer at Progress Software, talked about automating deployments for the Progress Arcade SaaS platform using the RightScale API and tags. Progress created its own vending machine to “help our application partners to SaaS.” He said Progress has 2,000 customers, of which about 150 use cloud. The company maintains 250 accounts on RightScale that it uses for customers’ deployments. It uses RightScale Tags to filter owners of projects and create “doors.” Tags share IP addresses among deployments. They use RightScripts™ and customize them.

Key quote: “Shame on AWS for going down, but shame on you for not having a backup.”

Finally, Chris Henry, head of technology at Behance, an Adobe company, talked about how his company optimized its infrastructure by melding together physical hardware and cloud infrastructure. Behance is a portfolio site and social network for creative professionals. It gets more than 51 million page views per month, mostly from creative professionals uploading images. Yet only two people run its infrastructure, thanks to the company’s use of Rackspace as a hosting provider. Behance was the first RackConnect customer, and uses Rackspace public and private clouds with RackConnect to connect them, which yields very low latency conditions between the two. It has spun up HA servers for image hosting in a self-healing cluster that is always up. It uses MongoDB to run a Facebook-style activity feed – “you can scale it right out of the box and set up shards and write to them at the same time” – and found that as writes were happening performance was not degraded. RightScale helped Behance to iterate the ServerTemplates they use to power their site.

Key quote: “You have to engineer everything you write for failure.”

RightScale CEO Michael Crandell and RightScale CTO Thorsten von Eicken then took the microphone to preview some developments to expect from RightScale this coming year, including:

• Enhancement of the RightScale API
• New development around workflow automation
• Improving existing cost forecasting tools
• New services offerings: “we are very hands-on with customers who need onboarding and strategy consulting”
• Building out the multi-cloud landscape and giving customers more choice

Deployment Checkup: How to Regularly Tune Your Cloud Environment

In this session (watch the video), RightScale Senior Services Architect Brian Adler shared how RightScale helps customers perform deployment checks, and offered tips for people who want to do their own deployment checks to save money and improve performance. “‘If it ain’t broke, don’t fix it’ can be a bad decision,” he said.

Deployment checks should focus on ways to improve cost optimization, server utilization, high availability and disaster recovery (HA/DR), security, and best practices. To optimize costs, look for unused and unneeded resources. For instance, if you have EBS volumes you haven’t had attached in a long time, you probably don’t need them. Be realistic about how long you really need to hold onto EBS snapshots. Watch out for elastic IPs – you pay for inactive EIPs on AWS. Increase storage capacity only when you need it. Don’t over-buy or over-allocate, and use Recipe to allocate as you need it. Compress or eliminate cross-region and cross-cloud bandwidth.

You may find the greatest savings by tuning your server utilization, Adler said. Utilize Reserved Instances – PlanForCloud.com can help you figure this out. And choose the right size instance for the task at hand. Find the right fit for memory – you want to be running at 70 to 80 percent of memory consumed. Use monitoring and alerts to find small problems before they grow. Look for trends, not spikes, and look for under-utilization. Act conservatively and react early.

Also consider HA/DR. Is your provider set up to absorb regions dying? Avoid single points of failure, because if you have one, you aren’t HA. Spread the load by using multiple load balancers. Replicate data across availability zones, distribute servers in each tier across multiple AZs, and back up across regions and clouds for DR and failover. Set up monitoring and alerts ahead of time.

As for security, you should use security groups if they’re provided by your cloud. Make sure you know why ports are open in your firewall and who is using them.

On the topic of best practices, have things you need automated and ready to go, and when necessary trigger them manually. We don’t recommend image bundling, Adler says, unless – and this is rare – you need to do a manual install of software and boot time is unacceptable to respond to a dynamic event. Also:

• Use a ServerTemplate with a base RightImage™, and configure your server at boot time.
• Use EBS-backed images to speed boot times if you must, but remember you pay for storage for these each month.
• Use deployments as application containers.
• Set up naming conventions that make sense for your usage and stick with them.
• Commit your ServerTemplates – don’t use them from HEAD.
• Use CREDS for all sensitive inputs.
• Use auto-scaling in combination with right-sized instances for each task at hand.
• Automate all operations – allow no manual changes.

In closing, best practices promote operational efficiencies, and you should design in HA/DR from the start.

Understanding Virtual Networking in the Cloud

Josep Blanquer, RightScale’s chief architect, began this session by saying, “Networking is messy, even in the cloud.” Different cloud providers pick different designs based on what they think you want to manage, and use different naming conventions and API semantics between clouds. Cloud software can be so heavily customized during installation that even for the same cloud you can have different implementations across zones without knowing it.

So, instead of grooming an army of experts on cloud networking, let others do that for you: “Maintain control without having to be bogged down with non-business details.” Blanquer then talked about differences in how AWS, Google Compute Engine, and CloudStack handle networking, which you can best see by watching the video.

RightScale helps you manage cloud networking by abstracting network resources such as:

• Instances
• Subnets
• IP address bindings
• Security groups
• Network ACLs
• Routing tables

From a RightScale perspective a cloud has multiple networks. A network defines an isolation perimeter and has a CIDR block, and subnets further segment networks into CIDR subblocks. Networks contain security groups, routing tables, and network ACLs, but “notice a conspicuous absence of IP addresses”; we use IP address bindings, which are a combination of instance + IP address + port, and enable multi-cloud traffic through abstraction.

Using RightScale you can see the entire network through a single pane of glass. Coming soon we will be creating synthetic resources to fully abstract the networking process so you don’t have to think “security groups” or “firewall” or whatever – you will be able to specify all server configuration in a consistent way.

Delivering SaaS Using IaaS

Senior Product Manager Shivan Bindal presented an overview of the RightScale feature set and described its functionality at a high level (watch the video).

Our customers vary in experience and cloud maturity, he said, so we help them adopt cloud in a way that makes sense for them. User permissioning and accounts enables organizations to have organized environments. Many customers use development sandboxes and staging and production environments.

Eating our own dog food helps: Every employee at RightScale can log in to RightScale and access the cloud to do the development work we need them to do in order to ship product. Developers have access to test accounts where they can create deployments and servers as needed. QA has control of staging accounts where they do rolling code updates from developers and run automated regression and manual functional tests. Operations staff have access to a separate environment with production accounts that run RightScale on RightScale.

But what about when you have a customer who wants to take a legacy environment and launch it in the cloud? That’s the time for “SaaS-ification” – instantiating deployments with single-tenant application stacks per customer. Not economical? Cost efficiency is irrelevant if you price your app appropriately, but such a process requires ingenuity for operational management, taking into consideration the vast number of potential customers and potential application stack upgrades.

Of course complexity exists in cloud – but where do you want it to exist? It should be in your app, not in the management of it. Don’t push it up into the stack.

Once you get up and running in production, then you can optimize production deployments. One RightScale customer chose a unique way to do this. It used AWS DirectConnect to have low latency between an AWS public cloud and a private cloud data center that was geographically close to an AWS region, and it had the same app running in two separate cloud environments.

Bindal introduced RightScale customer Chris Szymansky, director of engineering at The Resumator, who recommended organizations moving to the cloud “iterate on your architecture, don’t perfect it.” He also suggested:

• For disaster recovery, have a passive region ready to go and replicate to it as needed.
• Set triggers for scaling.
• Know when to shed old technology.
• On that note, use MySQL when you need it, but also use tools such as Redis and Solr when it makes more sense.

PHP, Mobile, and RightScale: The Right Way to Do Mobile

Kent Mitchell, senior director of product management at Zend Technologies, led a session on PHP and mobile. He said that PHP runs 40 percent of the cloud, that 72 percent of PHP developers using cloud based services and APIs, and that 66 percent of PHP developers expect to work on mobile apps in 2013.

PHP excels at interfacing with other systems, and mobile apps need an agile approach
since they are updated all the time. You need a system to allow you to do this, and that is where cloud and RightScale come in.

Mitchell demoed Zend’s suite of mobile solutions, as you can see on the video. Zend uses the Apache Cordova PhoneGap emulator for mobile development. Zend Studio builds in the ability to deploy right to RightScale, and single billing through RightScale is available for true utility-based consumption – all of the tools necessary to build a mobile app and deploy it on a scaleable platform.

Operations Playbook: Monitoring and Automation

Our Chris Deutsch and Raphael Simon bragged a little about our RightScale Operations staff – 7 people managing more than 700 cloud servers across 5 continents. One factor that helps them do their job is that RightScale runs on RightScale!

A demo, which you can see in the video, shows how we do all monitoring using collectd, for which we’ve written custom plugins, including ones to get information from Cassandra databases. How do we get these custom plugins into our deployment? By using a RightScript to attach the plugin. Pro tip: Have a boot script that auto-tags your instances. It makes automation much easier.

RightScale makes heavy use of automation APIs to deploy upgrades and manage servers, among many other things. We created a tool called Chimp – a Ruby gem for running commands on servers managed by the RightScale platform – and we’ve released it as open source software. We use Chimp to do rolling upgrades of application servers, since they can’t all go down together. Chimp takes options for controlling concurrency so that we can upgrade in waves of a set number, and it has a “dry run” mode that does everything in sequence except actually run the script.

HA and Fault Tolerance: AWS + RightScale

Amazon Web Services Solutions Architect Miles Ward talked about architecting in high availability and fault tolerance using AWS and RightScale. He noted that cloud can fail from faults in facilities, hardware, networking, code, and people, and defined fault tolerance as the ability of a system to continue operating properly, though perhaps at a degraded level.

Ward said fault-tolerance is not binary – there are degrees of risk mitigation. By using the cloud, you have the advantage of no up-front capital expense, relatively low cost, and a self-service infrastructure that’s easy to scale up and down, all of which lead to improved agility and time to market.

Many of AWS’ services are fault-tolerant – you can see them enumerated if you watch the video.

Ward talked about a recovery time objective (RTO) – a time period in which service must be restored to meet business continuity planning objectives – and a recovery point objective (RPO) – an acceptable data loss as a result of a recovering from a disaster or catastrophic event. The goal is to figure out the best RTO/RPO ratio, and in that decision, cost is a huge factor.

Application owners are ultimately responsible for availability and recoverability. They must balance the cost and complexity of HA efforts against the risks they are willing to bear.

Best practices for HA that Ward suggested include avoiding single points of failure, using two availability zones, replicating data across AZs and backing up and replicating across regions for failover and disaster recovery, and setting up monitoring and alerts for problem resolution and failover operations. He advocated designing for failure: Use DNS to support multiple load balancers that send traffic to multiple app servers that use a replicated master/slave database setup that is backed up by S3 spread across two AZs. Use Elastic Network Interfaces (ENI) in a Virtual Private Cloud (VPC). Consider distributed NoSQL databases with the same distribution considerations described above.

To mitigate risks, assess each application and define RTO and RPO. Design for failure, starting with the application architecture. When you implement, consider best practices and factor in cost, complexity, and risk. Document your processes and automation (operations). Test frequently.

Performance: Key Elements to Consider in the Cloud

Craig Irwin is vice president for Channel and Alliances at Apica, a company that has been a RightScale partner for the last two years. He talked about how to proactively identify bottlenecks, improve performance, and optimize the cloud environment (watch the video). Part of improving performance is preparing for the unexpected and knowing how to respond, because when things go wrong, a snowball effect makes more things go wrong.

Irwin offered a number of tips:

• Have “minimalistic start and landing pages,” because small is fast.
• Make extensive use of front-end cache systems. He suggests the open source Varnish caching application.
• Implement a scaling and queuing system. Redirect excess traffic using load balancers. And for those users who wind up waiting anyway, create informative “waiting” pages.
• Test your solution for peak loads before launch.

Just what should you test?

• Is the site stable?
• When does it crash?
• Can my application scale?

To test your capacity against load, create a test environment, and use it. Then load and check your test findings. Identify the back-end calls – you’re liable to find that database calls don’t kill your application, but lack of caching does. Check the delivery of static content too.

Have performance and uptime targets. Establish a baseline and a response time average, but don’t optimize the average, work with the exceptions. Remove the 10 worst transactions every month.

Outage-Proof Your Applications

This session was jointly led by RightScale’s Brian Adler and Sanket Naik, vice president of cloud operations at Coupa, which provides a suite of cloud-based financial applications. Naik said that Superstorm Sandy helped drive Coupa’s plans for HA/DR. Because it needed “zero data loss,” Coupa went with a warm DR 99.99 percent uptime plan, which translates to no more than 4.23 minutes down each month.

Some of the material in this session covered the same ground as that of the HA and Fault Tolerance session outlined earlier. I’m going to forgo repeating that information and suggest you watch the video.

When it comes to disaster recovery, make sure you know who will do what to get yourself back up and running. Don’t have people thinking “someone else” is doing a necessary task. Develop expertise in-house or get outside help.

There are several levels of disaster recovery, each with increasing costs. Multi-region cold DR, the cheapest, is not recommended for organizations that require rapid recovery. Warm DR is the generally recommended solution because it combines minimal costs with fairly rapid recovery, but because it employs the public Internet, security and latency may be considerations. Hot DR is warm DR with all the backup servers kept running. As you might imagine, this comes at a high cost, but it allows for rapid recovery. The highest tier is multi-cloud HA, a live/live scenario in which traffic goes in all directions at a massive cost. If you can afford this, we’d like to talk to you about sponsoring RightScale Compute 2014.

HIPAA in the Public Cloud: The Rules Have Been Set

“HIPAA compliance in public cloud is achievable – don’t let anyone tell you otherwise,” said RightScale’s Phil Cox in this session. However, you must pay attention to privacy, security, and breach notification.

For security, you need to maintain reasonable and appropriate administrative, technical, and physical safeguards on electronic protected health information (ePHI). You should therefore perform a risk analysis and implement governance practices, defined staff roles, access management, training and awareness, and a program review.

Cox explained the Omnibus Rule change and discussed what qualifies a company as a business associate vs. a conduit (watch the video). Business associates are also subject to the Omnibus Rule. “This is the kicker,” Cox said. “A service like Dropbox that stores persistent data becomes a business associate in the eyes of Health and Human Services, so they are required to be HIPAA-compliant even if they never intend to view that sensitive information or only do so on a random or infrequent basis.”

Business associates need to sign a Business Associate Agreement (BAA). Not all public cloud providers will:

• Azure will
• Datapipe may on a case-by-case basis
• AWS has made no public statement
• Google Compute Engine, Rackspace, and SoftLayer currently will not

And RightScale? Cox said, “I believe in the security of RightScale enough that I personally would sign a BAA” if it were a customer requirement.

DevOps Stories: Getting to Agile

Uri Budnik, RightScale’s cloud evangelist, and Arindam Mukherjee, senior manager of DevOps at Blackhawk Network, a provider of prepaid and financial payments products, led this session on using DevOps and agile development coupled with the cloud’s ability to provide infrastructure (watch the video).

Mukherjee said Blackhawk employs 700 people of whom 300 are engineers and 40 are IT people. What do his developers – and all developers – want, he asked? The freedom to work anywhere with the tools they choose. Therefore, the first step to set up DevOps is to create a self-service portal for developers. By using RightScale ServerTemplates, Blackhawk has taken the process of deploying environments from two months down to 20 minutes. The company practices continuous integration – check in code, kick off a build, and the build script will fire up servers if they are not up. That kicks off a smoke test, then creates a deployment and builds a deployed app to that environment. They run unit tests then shut down the deployment.

Of course with that kind of freedom to create environments you now have to track costs and plan ahead. PlanForCloud.com can help with that.

For DevOps, how you bring the organization together is critical. At Blackhawk, the IT people joined the dev team’s scrum. Lessons learned:

• Take ownership of applications.
• Embed ops people into the development process.
• Enable developers to self-provision environments.
• The DevOps philosophy and RightScale ServerTemplates can simplify application lifecycle management.
• Create a dashboard for production operation tasks.
• Surface cost information to people who manage budgets.
• Think about how to architect for the cloud, where adding more infrastructure is no longer a bottleneck.

CloudFlow Deployment Orchestration: Automate All the Things

RightScale’s Ryan Geyer and Ryan O’Leary took the wraps off of RightScale CloudFlow Deployment Orchestration, a brand-new hosted, highly available service with built-in concurrency, conditionality, and error handling, currently in private beta. You’re going to want to watch the video for this session.

The Ryans gave a demo in which, with a single action, CloudFlow moved a whole live deployment from one cloud to another without disruption to services. Normally that process takes many steps that must be followed carefully and manually. With CloudFlow it’s all automated, and it works.

CloudFlow uses a new language called RCL that lets developers run any blocks concurrently. It offers simple methods to wait for or interact with other tasks. It builds in error-handling. And RCL integrates with other systems – you can make native API calls or callbacks to your systems.

Marketing at Scale: Delivering Marketing Campaigns in Record Time

RightScale Vice President of Marketing Kim Weins began her presentation by citing Gartner’s prediction that CMO spending will pass CIO spending on technology within five years. Because marketing departments need to roll out mobile apps, websites and other initiatives quickly to hit campaign launch dates, they need the ability to move on a  dime. In a sense, marketing is like a rogue IT department – with its large budgets, it will hire someone to build what it needs.

Because marketing departments want technology that’s scalable, fast to market, and cost effective, the cloud and RightScale are a natural fit for their use. With the cloud and RightScale, you get instant provisioning – push-button access to “cloud in a click” – and developers are able to self-provision. You can auto-scale both up and down – for instance, you can set minimum and maximum of numbers of servers and pre-provision ahead of known usage spikes. You can design just the environment you need, determine how it scales, and predict your costs over time.

RightScale is the technology behind successful digital campaigns from well-known brands, and Weins presented details of hugely scalable marketing campaigns by Lady Gaga and Mars (the candy maker, not John Carter’s vacation spot), as well as ongoing projects at Mattel, InterContinental Hotels, and Sony Music, which you can see in the video.

RightScale can be particularly helpful on the services side. We have white-glove campaign launch services – ask us (well, pay us) and we’ll do it all for you, your marketing team, or your agency. We’ll set up a dev/test/production environment for you and support you for a defined period leading up to and through your campaign.

And More!

As was the case yesterday, I don’t have recaps of every session, but you can watch the videos for Using the Cloud for Mobile, Social, and Games, Connecting the Clouds, IT-as-a-Service: Back to the Future,  and Uncovering New Opportunities with the HP Public Cloud.

Friday at 3:30, RightScale Compute 2013 wrapped up, and our customers, partners, and staff headed home. If you attended the event, we’d like to know what you thought of it – what could we do better next year? And if you couldn’t make it, tell us in the blog comments section here how you liked our coverage of the conference via the blog and by video.

ServerTemplate Best Practices

RightScale Senior Director of Engineering Tim Miller and Senior Software Engineer Cary Penniman shared some best practices for building RightScale ServerTemplates™ (watch the video), starting with using an efficient developer workflow. Go from a local box straight to an instance and bypass source control by using RightScale for development purposes with the “download_once” tag. This lets you, for instance, troubleshoot a stranded server and fix a Chef cookbook dynamically. Minimize your relaunching as much as possible – make sure every script runs by hand on your servers.

Another good practice: Don’t run servers on HEAD, the editable version of a RightScale asset. Use a committed revision instead to ensure your server will launch consistently. RightScale takes a snapshot of the repository every day in our back end, and you can freeze repositories by date to make sure that your servers launch with the assets you want. Nothing changes, so the server will boot consistently and reliably.

A couple of other pointers:

• Commit, freeze, and minimize external dependencies.
• Minimize changes – use cloning.

PCI: Building Compliant Apps in the Cloud

Phil Cox, director of security and compliance for RightScale, talked about building PCI-compliant applications in the cloud (watch the video). “PCI compliance in the cloud IS achievable,” he said. However, “There are a lot of charlatans out there. Be wise with your spending.”

Cox said most providers and all cloud-based operating systems can be PCI-compliant. The same cannot be said for all applications. He also noted that “if you don’t have the right qualified security assessor (QSA) you are screwed.

“Hardening your system is not an ancient Chinese secret,” Cox said. “There are well-documented steps. And a nice aspect of cloud is that since automation is part of the cloud’s DNA, automation of design change reviews can be built in.” Among his advice:

• Do not store the Primary Account Number if you do not need it.
• In fact do not store anything you don’t need.
• Restrict access and users — that’s really no different than what you’d do in a hosted environment.
• “Logging and tracking will bite you — basically no one is doing this right. There is a lack of transparency into some the devices you don’t have access to, such as hypervisor logs. We use RightScale to configure systems to send app logs to a central log server. You have to configure the system to create and send a log, because otherwise it won’t be there when you need it. Then you have to look at the log, because if you don’t look at the log, then it does you no good.”
• There’s no replacement for human testing for compliance.
• Have an incident response plan and make sure it works.

Mastering Puppet Configuration Management in the Cloud

RightScale Product Manager Ryan O’Leary led a session on Mastering Puppet Configuration Management in the Cloud (watch the video). O’Leary said that if you have your Puppet servers handle configuration management for you, you don’t need to use RightScale for configuration management, but you can use RightScale inputs to configure your Puppet environment. Alternatively, all you have to do is add a single script to our Base ServerTemplate to “Puppetize” your instance, and RightScale’s reporting and cost planning can be a huge help in enabling chargeback within your organization.

Looking ahead, expect officially supported ServerTemplates from RightScale Engineering in the near future. You’ll be able to store external facts about servers using tags. And we’ll have a Puppet Master Connector for deeper integration for Puppet environment configuration.

Key Design Considerations for Private and Hybrid Clouds

RightScale Product Manager Utpal Thakrar talked about Design Considerations for Private and Hybrid Clouds (watch the video). He started by noting that virtualization is not cloud computing, though it enables cloud computing. From that base, “always build with the end in mind. Always keep the application in mind,” he said.

A hybrid cloud is one that spans more than one private or public cloud. When would you need a hybrid cloud? One common case is when an application outgrows a private cloud. Many companies also want to “cloudburst,” or add public cloud resources when the demand on a private cloud gets too great. Another possible reason for turning to a hybrid cloud is to satisfy regulatory or compliance issues for parts of the application. Most organizations find they use multiple clouds in different parts of the same organization for different applications, with each app in one cloud.

One typical user case is to put a high-availability production environment in one cloud, and keep a disaster recovery environment in a second cloud. We call this a “warm disaster recovery” scenario. HA/DR can be very expensive.

For a healthy hybrid cloud, you need to eliminate single points of failure as best you can. Every architecture has them – for instance, in OpenStack deployments, you have OpenStack API services, MySQL, and RabbitMQ – but all can be made more fault-tolerant.

Build in agility, Thakrar said. Separate the management layer from infrastructure. “Keep the keys to the car outside the car.”

Three Stages of Cloud Adoption

Forrester analyst James Staten led a session on cloud adoption. He related the story of one cloud customer whose average spend was $500 a month. One month the bill shot up to $50,000. That kind of scenario will prompt changes in public cloud consumption. On the other hand, “you will pay more if you avoid ‘pay-per-use’ in cloud.” There will be no rebate, and you have to guess about what you will spend and maybe have to roll over your expenses to following year.

“Scaling down is the key to unlocking cloud economics in your favor,” he said. For example, “big executables equal big expense.” Break apps up into smaller pieces, he advised, so you can scale components more effectively – and not have to scale everything. Then keep scaling up until you get the scary bill, at which time you’ll get to scale down. After that point cloud becomes a profit center.

The model-view-controller (MVC) architecture doesn’t work in the cloud, Staten said. Instead, use a pipes and filters model the take advantage of an agile architecture that allows changes in applications with components that scale out for cloud economics. Evernote, he said, does this well, as does Instagram; LinkedIn learned the hard way.

Staten said time, componentization, service choice (meaning not provider, but cloud services), caching, and code optimization are the tools of cloud economics. Traditional apps struggle on clouds because they are architected with the assumption of stable, reliable hardware, sole ownership of resources, uninterrupted network access, and other static interrelationships. By contrast, cloud is a commodity, with shared resources and networking and no performance guarantees. Cloud can run anywhere, and services are shared with other elements.

To profit from cloud, align your use of cloud to your business needs. How will your cloud service generate revenue? What does the transaction flow cost? Analyze your performance profile. Can you improve your scalability model or action timing? And bake the lessons you learn into your developing cloud architecture.

Windows Azure Automation and Dev/Test for the Enterprise

RightScale’s Patrick McClory and Microsoft’s Mark Brown talked about using Windows Azure automation and RightScale to enhance agile IT (watch the video). If you’re going to automate things, they said, you need visibility into what you have and what is running, so you can drive efficiencies.

Windows Azure just went into general availability for IaaS on April 6. On the compute side, it can handle virtual machines running multiple server options including Windows Server 2008 and 2012 and three flavors of Linux. It also runs additional workloads, including SQL Server and BizTalk. On the networking side, it handles software-defined networking, and you can combine it with Direct Connect to make it look as if cloud resources are running inside your firewalls.

The presenters demoed the Azure dashboard, using it to launch a virtual machine from VM Depot, Microsoft’s online catalog of more than 200 prebuilt images. Users can take any VM created with VMware, run it through a converter, and move it to Microsoft’s Virtual Hard Disk (VHD) format. VMs can be triply replicated to three data centers.

While Microsoft has taken a static VM approach, McClory pointed out that you can use RightScale ServerTemplatesTM with Windows Azure. We have IaaS, SQL Server, and Active Directory ServerTemplatesTM, among others. The RightScale Dashboard adds another layer of security and offers OAuth authentication.

McClory then demonstrated the use of RightScale with Windows Azure. He showed that for development and testing, you can create an entire deployment, then push one button to clone it and get whole new dev/test environment with standard configurations. You can also build a promotion strategy to cover the whole software development lifecycle, from dev to test to staging to production.

With RightScale and Azure you can push the whole dev/test process into the hands of developers.

Building RightScale’s Globally Distributed Datastore

In this session (watch the video), Josep Blanquer, our chief architect, shared three factors that determine when we use MySQL and when we use Cassandra in our internal architecture:

• When we need transactionality, we take advantage of MySQL’s strong ACID properties.
• When we need availability, we use Cassandra’s distributed, masterless, highly replicated architecture.
• When queryability is the key factor, we use MySQL for its flexibility at adding indexes and changing data models.

We consider our architecture from two different views: What the users see vs. what the clouds see, and what is global vs. what is account-specific.

For data that is close to users and global we use MySQL, which handles smaller amounts of transactional data. To manage availability we use a custom read-only replication scheme.

Some data is close to users and account-specific (sharded). We use MySQL for our Dashboard functions, but for tags and other systems we use Cassandra for its simpler key-value access, greater scalability, and high write availability. For our data archive, which has a low read rate, we use S3, which is globally accessible. With this architecture, we can guarantee that what is put in a particular shard stays there; moving shards is an intentional and manual process.

For data that is close to instances and account-specific, we use a combination of MySQL, Cassandra, and flat files. We keep our services colocated with our resources. “We don’t need instances in every single cloud,” Blanquer said, “but geographically close is the key.”

Next-Generation Cloud Computing with Google

Google’s Evan Anderson told attendees about Google’s cloud platform. He noted that strong isolation of virtual machines was a value proposition for Google Compute Engine (GCE). Google’s frictionless OAuth 2.0 authentication with service accounts is still in beta, but customers are actively using it. Anderson also talked about some upcoming new features, but he went too fast for us to write them down, so watch the video!

Next he moved into a demo, launching 200 instances, with the first one up and running in 27 seconds, and all of them operational in just over a minute and a half. That led into information about the performance records Google has broken, with a slide that referenced a GigaOM article that talked about how fast GCE is compared to AWS. Before he finished, Anderson noted that managing multi-region deployments, which Google believes is a key to scaling, is an area where RightScale shines.

How to Build Your Own IT Vending Machine

RightScale Cloud Solutions Engineer Ryan Geyer talked about how to build a self-service interface on top of RightScale (watch the video). Doing so relies on the simple and powerful RightScale API, which comes with good documentation. We use API 1.5 internally to enable our ops team to perform rolling upgrades on our app servers. They can select all servers by app tag, then for each server they get new code, wait for the code to download to complete, and restart the server.

Geyer ran a live demo in which he created and deleted a deployment using our public Ruby library (right_api_client), which handles authentication and has simple access to mediatype actions and references, running in the interactive Ruby shell (IRB). The demo ran on AWS EC2, and included an admin interface to enable authorized users and terminate and clean up environments that shouldn’t be running. In the demo Geyer introduced some alpha software that may ultimately get open sourced, in the form of a graphical interface to create a deployment Visio-style. He also debuted an in-progress open sourced PHP API 1.5 client.

Integrating RightScale, Windows, and .NET for Fun and Profit

Koupon Media, in the persons of Patrick Moore and Gordon Bailey, showed attendees how to use .NET with RightScale (watch the video). They demonstrated how they use 2012 Team Foundation Server (TFS) for version control. All the resources to replicate the demo are located on the RightScale Support page on MSDeploy.

To get to this point, Koupon Media first found itself with a platform that took too long and was too expensive to scale. “We had a success disaster, and we had to re-engineer the airplane while we were flying.” That led to Koupon embracing the cloud, mobility, and social in order to do more with less. Today their operations are easier, more efficient, and faster, they said.

They also had some kind words for RightScale: “Working with Professional Services was like having an extra set of engineers on staff enforcing best practices. We were not just another face in the crowd. They helped us [use] what we need, not what we thought we needed.”

The happy ending? “I promised our CEO a three-month ROI. It looks like we will get it in six weeks.”

The Data Center as the On-Ramp to Cloud Enablement

RightScale is a key tool in the collision of the data center and the cloud, said Jarrett Appleby, COO of CoreSite, a company that builds and manages data centers across the U.S. (watch the video).

Appleby said data centers are at the center of everything. They facilitate the creation of 2.2 terabytes of data every day. IP traffic is constantly growing, and expected to triple by 2018. Sooner than that, by 2016, Appleby expects three to five data center workloads to be running in cloud. Thus the WAN has to be at the center of your data center, and software-defined networks will drive it.

In choosing a data center, network performance matters. You need to be able to offer sub-millisecond workloads. Systems integrators can be your best friends in helping you get the resources you need.

And More!

I don’t have writeups on them, but you can watch video of the sessions for The Business Case for Cloud Management, Unlock Your Cloud, Chef Configuration Management with RightScale, Managing Your Cloud Spend with PlanForCloud, and Tips for a Successful Cloud Proof-of-Concept.

Panel Discussion: The Future of Applications in the Cloud

After the midday sessions (and a refreshment break) we closed the day with two panel discussions. Forrester’s James Staten, acting as moderator, started things off by asking, “What kind of workloads are you bringing to cloud that you are struggling with, or maybe you think you can’t even use cloud?” Panelists included Steven Martin, general manager for Windows Azure; Brian Goldfarb, head of Cloud Platform Marketing at Google; Roger Levy, vice president and general manager at HP; and Duke Skarda, CTO of SoftLayer.

Levy answered by citing HP customer DreamWorks, which generates an incredible volume of data in rendering. ”We provide an object store in the cloud for them so that they get best possible economic outcome.”

Skarda noted that synchronizing data across public clouds is very inefficient. “We are always working on improving that,” he said. Goldfarb noted that Google laid its own trans-Atlantic cables to make sure data transfer is instantaneous.

Interoperability is another issue affecting the future of application in the cloud. “From Google’s perspective,” Goldfarb said, “we want to be part of a multi-cloud environment, whether that’s private plus Google or private plus HP Cloud, for example.” HP’s Levy expressed similar sentiments. ”Cloud is not about homogenizing apps. It’s about optimizing workloads.”

Skarda said, “At SoftLayer, we talk customers through leveraging the right resource for the right problem. We don’t go with multi-cloud to just have multi-cloud — what problem are you trying to solve? The key is to architect your system: Think through what you want to do and which tools are best.”

Staten then asked the panelists whether pricing per unit will keep dropping. Microsoft’s Martin said, “We feel great about returning value to customers as prices continue to drop. The market determines value and we’re here to play in it.” Staten followed up by asking how cloud providers can stay profitable. “We will take variability out in other places,” Martin said. “We will do what we do best: high volume, low cost. This is not a side business for Microsoft. We are committed to cloud.”

Skarda said SoftLayer views pricing as a performance and value issue. “Looking at other ways to scale your apps is important, and we will continue to improve our data center performance.”

An audience member asked about the transparency of specs of the underlying hardware in providers’ clouds. Martin said, “There will a race among public cloud providers to get the newest chips and get them into data centers for customers. The industry has not been transparent enough to say what is running under the covers.”

Levy said, “Speeding new chip innovation into public cloud is dear to my heart as someone who works for the world’s number one hardware provider. We will be able to get the best chipset via our relationship with Intel.” To which someone in the audience commented, “I don’t care what the chipset is. I want to know how many seconds the server request takes.”

Goldfarb said, “Google will take care of all those details on your behalf. The secret sauce is how do I combine infrastructure and PaaS — or not — to get what I need.”

Martin said he speaks to two types of customers. One is concerned with such things as clock speed, while the other is “trying to build something radically different with good value and good throughput. The latter is the way of the future.”

Staten began winding up the discussion by asking what is the future of applications in the cloud, and what should the audience plan and architect for? Skarda said, “Know what you are trying to do and find a solution to meet that need. All applications are different; the answer is always ‘it depends.’”

Martin agreed: “Do you want an evolution or a revolution? Do you want to build apps in a brand new way? We can help you, but someone’s ox will get gored and there will be blood on the ground. Be intentional about your goal — do you want to save money or build something totally new?”

Panel Discussion: The Future of IT Organizations in the Cloud

Joining Staten for the final discussion of the day were panelists Jarrett Appleby, COO of CoreSite; Peder Ulander, vice president of product marketing for cloud platform at Citrix; and Scott Sanchez, director of private cloud strategy at Rackspace.

Ulander recalled that back in the early days of public cloud, enterprises had two reactions. Some realized they wanted to bring the cloud model in-house to empower developers. At other shops, IT wanted to open up a virtual layer to power business advances but maintain control over the physical layer. Cloud, Ulander said, removes remedial functions and gives IT the opportunity to be more strategic. IT’s new job is service broker, delivering services with the appropriate risk and cost profile.

Sanchez sympathized with shops struggling with the new realities: “It can feel awkward for the dev and ops teams to move to cloud.”

Appleby noted that moving to full production in the cloud reflects a company’s risk level, “but we want to empower those who are ready.”

“Don’t you think IT expects things to be handed to them?” Staten asked.

“IT execs are putting their careers on the line to move to cloud,” Sanchez said. “We try to give them a portfolio of options. We feel we are uniquely positioned to help people make that journey from managed hosting to full cloud deployment.”

That raised a question with an audience member: “Is private cloud going mainstream or is it a temporary bridging technology?”

Sanchez said that the demand for private cloud is long term and hinges on reducing the complexity of managing it, explaining, “as long as an enterprise feels like it is only using one cloud, private cloud is here to stay.”

Going back to his earlier statement, Ulander said IT’s role is to become a service broker to run cloud, and it doesn’t matter where that cloud is as long as your users are successful in their daily life.

And there you have it — day one of RightScale Compute 2013. We hope that attendees got as much out of the first day as we did, and we’re looking forward to a second day just as full of information and communication.

• Cloud Watchers are organizations that are developing cloud strategies and plans but have not yet deployed applications into the cloud. Cloud Watchers want to evaluate available cloud options, and determine which applications to implement in the cloud.
• Cloud Beginners are new to cloud computing and are working on proof-of-concepts or initial cloud projects. These organizations want to gain experience with cloud in order to determine future projects.
• Cloud Explorers have multiple projects or applications already deployed in the cloud. They are focused on improving and expanding their use of cloud resources.
• Cloud Focused organizations are heavily using cloud infrastructure. They are looking to optimize cloud operations as well as cloud costs.

The survey includes organizations across all the stages of cloud maturity.

Cloud Is a Given

One of the primary findings of the survey is that cloud computing is no longer on the bleeding edge of technology adoption. Three-quarters of our respondents say that they are adopting cloud. The rate of adoption is slightly higher in enterprises than it is among small and midsize organizations (SMB) – 77 percent vs. 73 percent.

But although enterprises are moving into the cloud, they are moving more slowly through the maturity levels. Thirty-two percent are just at the experimentation stage, and only 17 percent report heavy use. The proportions are reversed for SMBs: 19 percent are just experimenting, while 41 percent report heavy use.

Clearly enterprises have moved beyond the question of whether cloud is appropriate for their organizations, and are progressing down the path to cloud adoption. The slower pace of adoption is in line with the typical behavior of large organizations, which are dealing with added organizational scale and complexity and thus tend to take longer to fully consume new technologies.

The Future of the Enterprise Is Multi-Cloud

While the use of cloud is a given, organizations often have different strategies for adopting cloud that incorporate varying combinations of public, private, and hybrid cloud infrastructure. Organizations have multiple choices when it comes to cloud architecture, and multiple cloud vendors ready to provide services.

Public clouds are services available to all organizations, providing elastic and scalable resources that organizations pay for according to the level of resources they use. By contrast, a private cloud’s resources are available for only one organization. Private clouds may be created and managed in-house or be hosted at a service provider’s location. Finally, hybrid clouds combine both types of implementations, taking advantage of the unique strengths of each model but requiring a greater level of management.

Among public cloud providers, Amazon Web Services (AWS) was first to market, but today the competitive marketplace includes Rackspace, Google Compute Engine (GCE), Windows Azure, and a host of other players. Organizations that want private clouds can deploy technologies like OpenStack, CloudStack, or Eucalyptus internally in their own data centers or leverage hosted private clouds from a variety of service providers.

The survey shows that hybrid and multi-cloud implementations are today’s strategy of choice for the enterprise. Seventy-seven percent of respondents have a multi-cloud strategy, and 47 percent are planning for hybrid clouds. In addition, 15 percent of enterprises expect to use multiple public clouds and a similar number are planning for multiple private clouds.

Our survey revealed several other interesting trends related to enterprise cloud adoption, cloud competition, and the DevOps movement. I’ll cover those in more detail in upcoming blog posts. To read the complete survey results, see the RightScale State of the Cloud Report 2013.

RightScale uses a mix of relational databases — notably MySQL — and NoSQL technology, in particular Cassandra.

Our data taxonomy involves several systems with different data semantics. They include global objects — such as users, account plans, and settings — as well as a number of different items that are private to each account:

• Dashboard objects, such as deployments, audit information, and alert specifications
• Cloud polling data, which includes cloud resource states and cloud credentials
• Routing data, such as the location of instance and core agents and an agent action registry
• Monitoring and syslog data

In practice, when it comes to using the data, we need to pay attention to the scope of any given data – whether it is shared among accounts or used by only a single account – and its placement, by which I mean who uses the data. Global and dashboard objects are used by the Dashboard and API — they are “close” to users. Cloud polling data, routing data, and monitoring and syslog data are used by instances and resources — they are “close” to the cloud. Those two concepts, scope and placement, make up two axes against which we can graph our database systems.

In my session I’ll share details on how these two axes influence how RightScale geographically deploys its systems, as well as how they dictate the technologies that we use (MySQL, Cassandra, S3, and others) for each specific task based on the availability, replication, and geographical proximity constraints of each of the tasks. For example, we will show how we leverage MySQL for its ACID semantics and “queryability,” Cassandra for its strength in availability and scalability, and S3 for its archival and large volume capabilities. I’ll also talk about our disaster recovery strategy and show how it reacts when facing complete region outages.

Register for RightScale Compute 2013 and plan to attend my session on April 25. I look forward to seeing you there.

I’ll cover:

• Architecting a custom MSBuild script for flexibility and ease of use
• Utilizing Windows Azure services to store and manage your build packages
• Implementing RightScale processes and assets to deploy, configure, and manage your dev and testing environment

Now let’s dig into the nuts and bolts of how your DevOps team can improve your dev/test workflow – from build script architectures to deployment automation using Windows Azure and RightScale.

The Reference App

To show how the process can work, I chose as a reference project the Mileage Stats application that Microsoft’s Patterns and Practices group put out under the Project Silk initiative. The group did a great job of building a visually appealing web app that has some cool HTML5 in it and uses SQL Server’s LocalDB engine to host the data. For a demonstration of web technologies it’s a good choice, but I actually want to dig into integrating SQL Server deployments with the demo app, so I modified the project to use SQL Server by building out a new class library and modifying the Unity configuration to point to it. I also uploaded two database backups to GitHub (SQL 2008r2 and SQL 2012).

MSBuild Process and Architectures

Frameworks like MSBuild are the key to getting DevOps right in the Microsoft ecosystem. MSBuild is completely entrenched in the software world and is easily extendable. For me, it has become the go-to scripting framework for managing deployments and configuration changes.

If you’re a Visual Studio developer, you already use MSBuild, even if you’re not aware of it. Visual Studio project files are actually (you guessed it!) MSBuild project files, and are consumed by the MSBuild engine to compile your application every time you press F5 or Ctrl-Shift-B when you’re in Visual Studio.

When putting your custom MSBuild scripts together, it can be tough to figure out how much flexibility to put into the framework you’re architecting, so I thought I’d share my template and thought process on building it out.

To start, I wrapped my XML docs in a standard class library project so that I can version them and eventually build a publish process out of it, but for now, it’s just the container I’m using. You can get the code from GitHub. I have a main Build.xml file that includes a number of other files along the way: an environment-specific file, a project-specific file, and a base set of custom targets that may consume custom tasks.

You need an environment file because developers all set up their machines differently, such as where SQL Server is installed, for instance, or specific repository root paths, or the possible use of a secondary partition to store data. Also, some critical paths in the process of building this application  – most notably the location where we’re going to publish the package – may need to be accounted for on an environment-by-environment basis.  While you can push the name of the environment file into the MSBuild process via the command line, it’s much easier to set defaults and use the $(ComputerName) variable to pull in the environment file automatically. With this technique, you only need to create the file in the right place, and if you’re on a domain network, you’re guaranteed to have a unique name! Check out how it works: if a value is found for $(EnvFile) among the command-line parameters, MSBuild imports that file; otherwise, if a corresponding environment file exists for the computer, it imports that one:

With this setup, the process of configuring an environment is the same for your local machine as it is for your build box. That gives you a ton of flexibility as to how you set things up on your machine depending on what else you need to have set up to do the rest of your day job.

Next, the build process pulls in all of the solution-specific artifacts, such as what to build and other solution-level defaults. In the Mileage Stats application, check out the Properties.xml file and note that I’m setting up a number of properties for the build process itself, such as paths for tasks and the solution root path, as well as compiler-level hints for code analysis and build configuration and architecture. Next, I’m creating the collection of project and solution files that I’ll actually build; for this application I’m just building the overall .sln file:

Finally, I have the rest of the targets and process behind what MSBuild is actually going to do. At this point I’m just packaging up the web application using the Web Deploy package target and doing some file manipulation to zip up the entire contents of the package using DNZip from the MSBuild Extension Pack.

At the end of the process I have a fully compiled MSDeploy package that I can use to move the web app out in the wild. I’ve incorporated RightScale and Windows Azure into TFS, and rather than building the solution file directly, I’m calling my custom build process and this package target in addition to my normal build/compile/test process.

Taking It to the Cloud

With that part of the process completed, we’ve actually got the majority of the heavy lifting out of the way.  In order to deploy our assets in the cloud, we’re going to utilize Windows Azure Storage to house our build packages. This way we can modify some inputs on a RightScale ServerTemplate^TM (more on that in a bit) and get the system fired up “automagically.”

On the tail end of the package process in MSBuild, we’re going to add a custom task to take the final file and upload it to a specific container in a Windows Azure Storage account. This process is simple and is just a matter of consuming the Windows Azure Storage API within a custom MSBuild Task:

It’s that simple (from a task perspective), and calling it from MSBuild is just as easy:

With all of this integrated, there’s nothing cooler than seeing it work without errors:

Deploying Automatically via RightScale

Once we have our compiled (and hopefully unit-tested) application deployment package sitting in the cloud, the next step is where all the magic happens. Using an all-in-one ServerTemplate^TM in RightScale that contains SQL Server and IIS, we’re going to spin up an instance for testing.

From the build script, we can run two potential tasks to finalize the process:

UpdateCITestServer, which updates a running server (using RefreshApplication) with the latest version of code, and LaunchDevTestServer, which terminates a server (using TerminateWithWait) if it’s currently running, then relaunches it (using LaunchRSServer) with the newly built code package.

The three custom build tasks I’m using to leverage RightScale’s API are pretty simple, too, when implemented with a .NET wrapper for the RightScale’s API 1.5:

You can find this ServerTemplate^TM in our MultiCloud Marketplace. It is essentially the Database Manager for SQL Server ServerTemplate^TM with modifications to support this test environment deployment process. After the SQL instance is up, the RightScale cloud management platform automatically runs PowerShell scripts to add database users and configure IIS for the application. It:

• Installs IIS via the Add-WindowsFeature cmdlet and registers .NET 4.0/4.5 with IIS
• Using the Web Platform Installer 4.5, installs MVC3 and .NET 4.5 (if it’s not already installed)
• Installs Web Deploy 3.0
• Downloads, unpackages, and imports the Web Deploy Package into IIS

We’re calling the launch action on the server from MSBuild, so we have a lot of control over the inputs and setup on the server via RightScale:

• We set the Web Deploy package name at launch time so we can launch the package we just built.
• We can also set variables and modify the configuration of the Web Deploy package – for instance modifying connection strings via inputs on the ServerTemplate^TM that populate the ParameterSet.xml file.
• Along with that, we can tightly control creating accounts to make sure that the web.config and the SQL Server accounts are synced for connection strings.

End-to-end, I can rapidly deploy an instance for testing from within my build workflow. In 20 to 30 minutes, I have an instance that’s deployed and ready for testing in the cloud initiated from a build process from my development environment with just a few easy clicks.

Behind the scenes, the RightScale ServerTemplate^TM that I’m using also has been set up to conform to my specific security and policy standards. In an upcoming post I’ll show how the ServerTemplate^TM can even be domain-joined to pull down group policy rules so that not only am I able to test on a clean machine, but that I can also test on one that’s representative of the proper environment and security context.

A Final Word

Admittedly, this is a lot to take in, even if it is an “easy” example of an all-in-one test server.  But scaling out to an environment that includes multiple tiers (load balancers, SQL Servers, and IIS Servers) for testing and eventually production is really just a matter of mechanics rather than an exercise in building new components. Given the flexibility of the demo assets, with a little modification you could be standing up full stacks right from your development environment!

For more information on RightScale and Windows Azure, register for our upcoming joint webinar on May 21.

Selecting an application for your proof-of-concept is a key first step. You should choose a real application, but not the hardest one on your to-do list. Keeping in mind a few of the many benefits of cloud computing — speed to deploy, high scalability, and the ability to support variable loads — pick an application that will enable your organization to respond more quickly to business needs and opportunities. Good candidates are those projects that give more control to your internal business users or developers or that automate routine work for your operations team, such as web applications, social and collaborative apps, big data analysis or processing, or development and testing solutions. And be sure to choose a project for which you can show demonstrable results within a few months.

Once you have an application in mind, you need to decide where to put it. Should you deploy on a public or private cloud? Private clouds are a good choice for applications that require high flexibility and performance and that demand a level of security or compliance. They’re also a good fit for organizations that work under a capital expenditure procurement model. The advantage of public clouds is a higher level of automation than you can attain with private clouds. As for which cloud technology to use, consider one built on a standard like OpenStack or CloudStack. Numerous cloud vendors’ offerings are built on top of these open source platforms.

Along the way, you’ll find yourself navigating many technical hurdles. In my session, I’ll talk about how to architect applications, manage data, and ensure security in cloud environments. I’ll cover testing for both performance and security, and discuss integrating cloud applications with existing IT service management processes.

As you near your project’s release date, you’ll want to measure the success of your cloud proof-of-concept. If you’ve picked the right project, you should see improvements in uptime and agility and lower costs than you could achieve via traditional data center development. Even if these improvements are slight, bear in mind that the point is as much to learn about how to implement cloud applications as it is to roll out one particular application. The lessons you learn from your proof-of-concept development will pay off in every future cloud development project.

I look forward to seeing you in San Francisco at my session on Tips for a Successful Cloud-Proof-of-Concept. If you haven’t already, check out the conference agenda and register for RightScale Compute.

For a successful foundation for PCI compliance, plan to protect all cardholder data (CHD) housed in the IaaS provider. You should architect your application in three tiers: load balancer, application server, and database server. And make sure that you keep your dev and test environments separate, outside of the cardholder data environment (CDE) and with no CHD, so that you can focus your compliance efforts solely on the production systems.

For PCI compliance, you need to have proof for what you assert. When it comes to partners, you will need to have cloud service providers (CSP) that are on the Approved Service Providers list for one of the major card brands or that have done a Level 2 assessment and can show you an attestation of compliance. The former is preferred, and the latter may suffice, depending on your situation, but the CSP should sign a contract that states that it must protect CHD in accordance with PCI DSS. You have to do your due diligence on both approved and compliant providers.

The other key aspect of PCI compliance is making sure you manage the system components correctly. The industry knows how to manage traditional environments, but the nuances of public IaaS clouds can make mistakes more egregious. The functionality that RightScale gives you in terms of management and governance of system components is invaluable, but you can also leverage other management options (other vendors, do-it-yourself, or a combination) to promote your PCI compliance efforts.

PCI compliance in a public IaaS cloud is a touchy subject, but it need not be. Register for RightScale Compute and join me in San Francisco on April 25, and I’ll try to answer your concerns. If I don’t cover your specific questions during the session, I’ll be happy to speak with you afterward.

As a special incentive for blog readers, I’m offering a 25% discount for the first 10 people who sign up for RightScale Compute using the discount code COMPUTE_PCI_25.

Last year I began working as a feature developer for OpenStack, the open source cloud computing project founded by Rackspace and NASA. In my work I develop and test new features of OpenStack on different versions of OpenStack itself, and using different operating systems. As a developer, your work environment should be as close as possible to the environment in which your code will be deployed so that you can to get to know the code, improve it, implement new features, and check how things behave. However, after nearly three months, I found myself juggling an incredible mess of various clouds implemented in different ways across multiple operating systems. I realized that I was spending too much time managing the environment and not enough time working on my code.

I went looking for tools to organize my deployments and improve my productivity, and came across RightScale, a comprehensive cloud management solution designed to monitor and manage cloud deployments. Since RightScale supports OpenStack, I decided to see how it could fit my needs. I learned that RightScale not only supports OpenStack but also recommends the Rackspace Private Cloud reference architecture for OpenStack.

To test integration with RightScale, I used a single-node OpenStack Folsom implementation running on Fedora 18 on a standard server with an AMD Athlon X2 2.7GHz CPU with 4GB of DDR2 RAM. You could get better performance with high-end servers, but for testing and development purposes this hardware is more than enough and the integration process is the same.

I had no trouble following Fedora’s Getting started with OpenStack on Fedora 18 setup guide and using the available packages in Fedora repositories. The hardest part? My ISP doesn’t provide static IP addresses, so I had to get a dynamic DNS service to make my server visible from the outside.

Adding a Private Cloud to RightScale

It’s easy to add a cloud to RightScale, as long as you have an administrator account and credentials on hand. I signed up for a free trial, then followed the detailed directions in Register an OpenStack Cloud with RightScale.

Click Clouds > Add Cloud in the main menu displays a list of all the available clouds.

Since you will be the manager, click Administered Clouds and register a new private cloud with the Register Cloud button. You must enter your administrator credentials – the username and password you use for your OpenStack cloud – the tenant ID, the name of the region where your server is, and the cloud controller address. You can retrieve this information from OpenStack’s Keystone client, or by going to the RightScale dashboard in the upper-right corner under Settings > OpenStack API and downloading the admin’s RC file.

You should see a notification on the RightScale dashboard informing you that the connection was established with your private cloud and, after viewing a brief Getting Started Guide that appears in the dashboard, you can start using RightScale to manage your OpenStack cloud.

Integrating RightScale and OpenStack

I was excited to find that RightScale lets you do almost everything you can do from the OpenStack Dashboard, including launching instances and establishing SSH tunnels with them, creating volumes and security groups, uploading images, and deploying networks. RightScale has great support for every OpenStack service.

Having all my deployments in a single place allows me to show them to my colleagues, and allows them to review my work. I can also learn from other people’s deployments and share resources with new developers getting involved with the stack.

A beginner like me – with little experience developing cloud features – cannot yet take full advantage of all the flexibility that RightScale offers for managing applications across multiple public, private, and hybrid clouds. However, the ease with which you can access the service and the multitude of tasks it lets you perform make RightScale beneficial even for those who use only some of its features.

Deploying OpenStack is not difficult, and integrating it with RightScale is even easier. If you want to give OpenStack and RightScale a try, sign up for a free trial.

Victoria Martínez de la Cruz is a computer science student and interns for OpenStack as a participant in the GNOME OPW program. She is a FOSS enthusiast and tech lover and is always willing to learn about new technologies.

It’s time to change that! At RightScale Compute 2013 I’m leading a three-hour workshop on cloud cost budgeting. My goal is for you to walk away with information and tools you can use right away to better understand and plan for your cloud costs.

As a special incentive for blog readers, I’m offering a 25% discount for the first 10 people to sign up for the Cloud Cost Budgeting Workshop using the discount code COMPUTE_CloudCost_25.

Here’s what I’ll cover:

1. Understand the CFO Perspective

Why should you care about what your CFO thinks of the cloud? If you want your cloud strategy to be successful, you need to work successfully with all levels of your organization. Your CFO has veto power, so I’ll focus on how you can understand and align with the CFO perspective by using the RightScale CFO as a case study.

2. The Big Shift

You need to shift to a new mindset when you start thinking about the cloud. You have to consider private vs. public cloud costs, TCO, and capital vs. operating expenses. Even if you’re on top of all these factors, the complexity of public cloud prices is daunting. We currently maintain more than 12,000 price points in our PlanForCloud free cloud cost simulation engine. That is a crazy amount of information to be able to digest and use to accurately budget for your cloud project. I’ll demonstrate how you can budget for your specific cloud projects.

3. Investigation and Planning

Every project runs through cloud adoption lifecycle phases. I will cover each of these phases, introducing the challenges that you can expect to face and provide the tools to help you meet these challenges. The investigation and planning phase is an especially important one because it can set you off on the right (or wrong) foot.

4. Deploying and Monitoring

With cost in mind, I will cover the points you should look at when deploying your application to the cloud. There are a number of things that you need to keep in mind to be able to control your cloud costs at this stage. Once you have deployed your application, you will want to monitor your costs and make sure things are running according to plan. I’ll walk you through the tools that can help you with this.

5. Optimization

Once you have settled into your comfy new home in the cloud, the optimization work begins. I will cover the two main optimization techniques:

• Resource optimization involves using your cloud resources to make sure there is no waste, and automating the steps. I’ll cover top tips for saving money on the cloud.
• Cost optimization includes looking at purchase options, such as reserved instances, six-month plans, daily deals, and spot instances. I will walk through the business decisions you’ll need to make to optimize your costs.

6. Advanced Next Steps

I’ll talk about chargeback, cost allocation, cloud provider price changes, and new features for serving your use cases better.

I want this workshop to be a two-way conversation, so please come with questions relating to your specific scenarios and use cases.

As a special incentive for blog readers, I’m offering a 25% discount for the first 10 people to sign up for the Cloud Cost Budgeting Workshop using the discount code COMPUTE_CloudCost_25.

I hope to see you there!

When you explore any of the new UIs, you’ll notice a number of improvements. Much of the tabular functionality that previously required server requests is now handled on the client side, smoothing the entire UI experience. Some of the highlights:

• We now do filtering and column sorting on the client side, and it happens instantly.
• We’ve unified bulk and single actions in one menu.
• Tables can now hold a large number of entries, reducing or eliminating the need for pagination.
• Large tables no longer wrap or require horizontal scrolling. Overflow ends with an ellipsis, and mousing over it shows the entire contents in a tooltip.
• Multi-select options for entries like security groups now use a widget based on Chosen, which allows both mouse and keyboard-driven entry.
• We support in-place, client-side editing for ELB info, health checks, and listeners.
• We provide an HTML5 multiple-file uploader for S3.
• A fixed right sidebar displays additional file characteristics when users select a file in the S3 browser.

Updated S3 UI with our new HTML5 uploader

A New Framework

Many of these features take advantage of key components of our new UI framework. Like many companies that provide web-based services, RightScale uses JQuery, which opens up a large number of exciting JavaScript libraries. Our core UI library is built on Bootstrap, a common UI framework that we use for a variety of components, such as modal dialogs, popovers, and tooltips. We have also modified and deployed Datatables, a framework that gives us fast and flexible tables that can manipulate large amounts of data. These JQuery libraries, along with several smaller libraries, give us a base that we continue to adapt in our new UIs.

Perhaps the most exciting component of our new UI framework is Backbone.js, a library for building single-page apps that allows us to move much of the logic that was previously server-side into client-side JavaScript. This means that users can manipulate data using JavaScript without having to wait for a server to respond. For example, in the ELB browser, users can add a new listener on the client side, and the back end will sync the changes without forcing the users to view a loading screen. Backbone also allows users to move through a variety of “pages” seamlessly, without having to endure the page load times common to traditional websites.

These libraries provide the foundation for our UI framework, but we have done considerable additional work to create a cohesive collection of libraries that we can use to quickly and easily create future UIs. In particular, cloud services from one provider will be able to share UI functionality with comparable services on other clouds from another when the two are similar — Rackspace Cloud Files and AWS S3, for instance. This framework has already increased the speed of application development; during a recent internal development challenge, a small team of our developers was able to create a new internal monitoring page in a matter of hours.

Our new framework also separates logical areas of the dashboard into separate, individual web applications that can communicate with one another and share resources. As a result, we can quickly incorporate feedback, address bugs, and iterate on features in one application with less risk of causing problems in another. As an example, today we are rolling out a series of bug fixes to our ELB application, many of which were reported by our customers. Though this fix falls outside our usual release timeline, the isolated nature of our ELB application allows us more flexibility in our updates.

Wanted: Your Feedback

We’re building new RightScale features using this UI framework, and we’ll update our existing UIs over time to take advantage of it. We would love to hear which improvements you would like to see in the RightScale dashboard. You can share your feedback with us in several ways:

• Use the Feedback button that appears in the upper right of the new UIs; it sends your feedback directly to the product and user experience (UX) teams so that we can quickly act on it.
• Comment in our Feedback Forum, whose content our product team regularly monitors and uses to plan development sprints.
• Participate in a usability study. The UX team conducts periodic usability tests of new features; if you are interested in spending 30 to 45 minutes in return for a gift card and a chance to influence the future of the RightScale cloud management platform, you can sign up here.
• Join us at the RightScale Compute conference, where you can talk with members of the RightScale UX team in person.

When you work for a cloud management provider, you see the word cloud a lot. And you know how, when you see a word over and over again, it kind of loses its meaning? Yeah, that happens for us, too, and sadly there are no good synonyms that we can use to vary things a little. Store your data in the smog? Set up a public nebula? Launch a new haze? No, no, and no.

To offer an antidote to the all-cloud-all-the-time fatigue, a developer whose GitHub handle is panicsteve wrote cloud-to-butt, a Chrome extension that replaces every instance of “the cloud” in a browser window with “my butt.” Building on that fundamental base, developer DaveRandom created similar extensions for Firefox and Opera.

If humor that would amuse a second-grader is not your taste, you can opt to recode the JavaScript open source extensions so that instead of “my butt,” your browser will replace “the cloud” with anything from “a Tardis” to ” bacon” to “Sesame Street.” We tried replacing “cloud” with “bacon” on an article from InfoWorld, with amusing results:

Try it yourself. Better yet, surprise your boss by installing the extension in his or her browser, replacing “cloud” with “client/server.” And then let us know how that goes. (Use a #RightScaleAF hashtag if you tweet it.)

When it comes to cloud management, RightScale takes a rear seat to no one, but its obvious that Steve and Dave worked their tails off on these extensions. We just hope their well of creativity hasn’t bottomed out yet, and their best coding isn’t behind them.