Note: We often use the term “image” to represent the base images from which Cloud Servers are built, and the term “snapshot” to refer to a point in time image taken of a running Cloud Server. For all intents and purposes the two terms are interchangeable; however, because the feature is called Scheduled Images, this post, the online documentation and the Control Panel have standardized on the term “image” or “server image.”

Users of our first generation Cloud Servers have long had the ability to setup a fairly fine-grained schedule of daily, weekly and monthly rotating server images. When a point in the schedule is met, an image is taken of the server without causing downtime and stored in your account for recovery or rollback purposes later.

While this system offered a great deal of flexibility, it also introduced complexity, and put our users in a position of ensuring that they designed valid, non-overlapping, non-conflicting schedules all to perform what is ultimately a straightforward task.

When we designed Scheduled Images for next generation Cloud Servers, we started with simplicity in mind: require the fewest number of choices to ensure that more customers are able to setup Scheduled Images more easily, and thus have more protection in the event that they need to utilize an stored image.

So, instead of a traditional schedule that combines times and days, arbitrary retention periods and overlapping rules, we focused on the one configuration item that our users found most important, and that’s the only question you have to answer to get up and running:

“How many images do I want to keep of my server?”

Scheduled Images in next generation Cloud Servers relies on that one simple question. You provide the number of images you want to retain, and we will take one daily snapshot / image of your server and store that number. It as easy as that. If you specify seven images, then when the eighth image is taken, the oldest will automatically be removed from your account.

Besides highly simplified scheduling and retention, we’ve also improved the capabilities of our first generation Scheduled Images in a number of areas.

Perhaps of the biggest change is that there is no longer a size limit on your server when taking images. This means that you can now take an image of a 512MB Cloud Server, or a 30GB Cloud Server, whatever you need.

Now, physics being immutable (so far), of course the larger the server, the more data will be stored, and must be transported across our internal networks into your account. We’ve done a lot of optimization to try and ensure that no matter what size your server is, you’ll see a successful snapshot for as many days as you’ve chosen. However, there may be scenarios where a very large Cloud Server takes longer to image than expected, or other limiting factors. If this occurs, no image will be stored for the day, and you will not be charged. Cloud Servers will re-attempt the snapshot the next day, without requiring any user intervention.

We hope that you find the new Scheduled Images feature useful, and as always we’ve contributed our work back to the OpenStack project as a Nova extension. We’ll be working with you and our partners to continue to evolve Scheduled Images, and we absolutely welcome your feedback.

For more information, check out the Scheduled Images FAQ in the Rackspace Knowledge Center.

FLO Cycling makes affordable aerodynamic bicycle race wheels to be used by triathletes. They have been our customer since late last year when they came to Rackspace after their popular pre-orders became too popular for their previous hosting solution to handle.

In a recent pre-order, they sold out of their wheels in 12 minutes and wrote a blog post about how they survived the traffic. You can watch the full video from the Google+ Hangout we did with  FLO Cycling, or jump to one of the highlights below.

• Jon Thornham and Chris Thornham of  FLO Cycling talked about how the majority of their business is done through pre-orders. They talked about the importance of having a site up and available and described the different hosting platforms the company has used.

• The guys talked about how they knew that Rackspace was the right platform for them and how important it was to have a hosting provider and team to support their business. Jon went on to talk about the relief of not having to worry about hosting so they can focus on their business.

• Chris talked about their program called Bike for a Kid, in which  FLO Cycling uses a certain portion of sales to help purchase bikes for children who can’t afford them. Watch Chris talk about the program here and be sure to check out their website for more information about Bike for a Kid.

That’s the recap from last week’s Google+ Hangout featuring  FLO Cycling. Be sure to catch Drew and I this Thursday at 1:00 p.m. CST for our next Cloud Launch Office Hours, and you can find out more information by visiting the Rackspace Google+ page. We hope to see you there!

Keynotes

It’s quite apparent that Red Hat is taking a more assertive — and sometimes aggressive — stance against closed source, overpriced solutions that prevent consumers from getting things done. Red Hat President and CEO Jim Whitehurst had a slide that showed “Open or Die” with a live plant on the left and a dead one on the right (see the photo in the post just below this paragraph). You could hear the gasp in the audience from some of the less technical crowd. Red Hat is making a big push to deliver on OpenStack and to modernize their RHEL and RHEV platforms. Paul Cormier, Red Hat’s executive vice president and president, products and technologies, detailed some of the upcoming offerings and the overall strategy seems to be a double-down on virtualization via OpenStack and further enhancement of Enterprise Linux.

Of the vendor keynotes, the Intel keynote from Dirk Hohndel, Chief Linux and Open Source Technologist, was superb. He seemed a bit nervous at first and we were quickly losing interest but he brought us back in with some good anecdotes. Dirk went into detail about how a company with a ton of intellectual property could also embrace open source. Surprisingly, the speech really moved me and there were no slides involved; it was just Dirk talking.

You can watch the keynotes on Red Hat’s Summit site. If you only watch one of them, watch Dirk Hohndel’s talk (direct link to MP4).

Sessions

The most memorable was Red Hat Chief ARM Architect Jon Masters’ demonstration of the 64-bit ARM platform (AArch64). Although there was no bicycle or spandex involved this year (he apologized for the lack of both), it was amazing to see some firsts. It was the first time AArch64 has been demonstrated in public and the first time Gluster ran on 64-bit ARM. He had a 2U rackmount chassis and the fans were extremely loud. Jon commented that the chips are “rarer than gold” and that he wasn’t going to chance turning the fans off. The server performed quite well during the demonstration and certainly outperformed what I’d expect from an ARM system.

Dan Walsh, Red Hat Senior Principal Software Engineer, led two informative sessions that I enjoyed. The first was a session on Linux containers. LXC confused me quite a bit before the talk but Dan and the product manager went through how containers work step by step. They gave real world use cases and made comparisons to the more prevalent virtualization methods, like KVM. As you might expect, Dan sprinkled in some useful security tips to make containers safer to use.

Another of Dan’s talks was about how to use SELinux in a large enterprise. He started it off with a brief explanation of SELinux and made us all stand up and say the words on his first slide (“SELinux is a labeling system”). He offered some tips on how to manage SELinux on multiple machines with Puppet and Ansible. In addition, he showed how custom policies could be easily exported and then passed around as RPMs or within configuration management systems. We also saw how to send auditd logs to remote systems for aggregation and alerting. You can certainly manage SELinux on many machines simply by treating the policies and configuration just like you treat any other service’s configuration files.

Even after the Pub Crawl on Thursday night, the Friday morning presentation about systemd was packed with attendees. The presenters went through SysV’s shortcomings and what systemd can deliver. It will replace init in RHEL 7. Adding systemd reduces the complexity of managing services and allows you to automate many of the things that are annoying to do manually (like cgroups). Its default method of handling cgroups allows CPU share to be carved up per service rather than per process. That means that if httpd has 10 workers and MySQL is running two processes, each service will receive a 50 percent share of the total CPU (rather than httpd getting a lot extra since it has multiple processes).

The RHEL 7 talks were extremely informative and I was writing until my hand almost fell off. I probably missed a lot of the new features so it might be a good idea to wait for the slides to be published. If you’re eager to use RHEL 7 as a desktop, you’ll see GNOME’s classic mode on the desktop (and it looks great).

After-hours

As usual, the Red Hat Certified Professionals reception at McGreevy’s was a great networking opportunity. I met other Linux users from around the world and enjoyed some pretty decent beer and food. I stayed after the reception and received a detailed lesson about how hockey works. The Bruins pushed through three OTs but eventually lost.

The rain ruined Thursday night’s plans but the Red Hat marketing folks put together a great alternative in less than 24 hours. We ended up at Royale and were treated to a ton of food and drinks. Some musicians set up late in the evening and we were all wondering what type of music they’d play. It was a group called Alter Ego from Montreal and they really rocked the place. They’re famous for “60 costume changes in 90 minutes” and they took us through oldies, disco, and contemporary music. They hit every single music genre I could think of (except country) and everyone was amazed that they entertained us for 90 minutes without a single break. If you get the chance to see this group in person, don’t miss it.

Wrap-up

The Red Hat Summits continue to be a good opportunity to learn, network, and experiment. The ratio of attendees seems to be tilting more toward the non-technical side, and this is a problem that the organizers will definitely need to improve. There were several technical sessions packed wall to wall with plenty of non-technical people playing on their phones or checking email on their laptops. It’s a tough problem to fix and many conferences have the same issue.

Next year’s summit will be in San Francisco in April. I hope to see you there!

Earlier this month, Rackspace sponsored and participated in a National Day of Civic Hacking at St. Edwards University in Austin. National Day of Civic Hacking brings together citizens, developers and entrepreneurs who collaborate to create, build and invent new solutions and software using publicly-released data, code and technology to solve challenges relevant to neighborhoods, cities, states and the nation. The ultimate goal is to work together to have a positive impact on society.

A group of Cloud Launch Rackers including Alan Bush, Drew Cox and Jason Swindle participated in the event and acted as live technical support, sat in with each team, designed hosting infrastructure and demonstrated what Rackspace’s award-winning Fanatical Support is all about.

I worked with Racker Nels Nelson on a project to deliver text messages to citizens when the Austin City Council discusses a particular neighborhood. We completed a non-trivial, legitimate, working product in less than 48 hours. Another Racker, Jay Morgan, was instrumental in guiding the process and design of a project called Connect2Good, an organization that links nonprofits with companies that can help them meet their needs.

See what Alan Bush had to say about the hackathon in the video below.

Harry Max, Rackspace’s Vice President of Experience Design, also served as a panel expert and gave advice and perspective to each team as it presented its project. Harry’s expertise helped the nonprofits ensure that their technology would deliver a good experience to all who interacted with it.

But the story I’m most excited about is that our participation helped prop up a new startup called Keep Austin Fed. This organization picks up unused food from restaurants and feeds people in need. Before the hackathon, Keep Austin Fed used a paper-based system that make it difficult to coordinate with volunteers around the city. Racker Joseph Palumbo helped Keep Austin Fed with its Cloud Servers and enabled developers to create a system to coordinate food pickup with volunteers via text message.

Throughout the weekend, developers, designers, system administrators and nonprofits in Austin and across the country collaborated to create software that will have a powerful and positive impact on society. If you haven’t been to a National Day of Civic Hacking, I encourage you to catch the next one that comes around. I know I am excited to see how each of these projects grows and matures.

Here’s the first question: is performance different than load times? Many folks think of the two as the same thing, but they are actually different. Increasing resources to your Cloud Server will almost always raise your costs, but will not always improve load times. And load times are what most people consider to be performance.

But did you know that there is one way you can leverage the cloud to serve content quickly to your visitors without having to beef up the performance of your server? In the video below, I talk about not only how you can save on your hosting bill, but also how you can speed up your website load times. The best part is that it works for all hosting environments, whether you have an all cloud, all dedicated or hybrid cloud solution.

But don’t expect to get blasted with Rackspace marketing the entire day. In fact, you should expect the opposite. We’re a world leader in cloud computing and over the years we have seen thousands of cloud applications and infrastructure designs, and we have spoken with hundreds of engineering teams. What we have gained from that is a solid understanding of what building in the open cloud looks like; from single-server WordPress installs to complex adaptive applications that span clusters of cloud servers and everything in between.

Cloud Savvy & Unlocked

The idea of Unlocked grew out of an internal program we created called Cloud Savvy, which takes the lessons we’ve learned and applies design principles, cloud know-how and best practices to advance the level of cloud expertise inside our organization. The Cloud Savvy program arms us with in-depth cloud knowledge to better help our customers design their cloud applications the right way the first time. The feedback from the Cloud Savvy program has been off the charts – Rackers are more confident in their cloud IQs and our customers receive more Fanatical Support in the cloud than ever before.

As the Cloud Savvy content matured and we saw significant impact within our customers, we realized there was a new opportunity in front of us – a new avenue that allows us to extend our Fanatical Support. Fanatical Support doesn’t start once you become a customer; we want you to experience it from the start. From consultation to deployment to growing your business – it’s about being helpful and doing the right thing to get you on the right path to the cloud. It was an easy choice to share our knowledge and experience with the world, and we hope you’ll find value in the lessons we bring to you via our Unlocked roadshow.

Why Should You Attend Unlocked: The Hybrid Cloud

1. It’s free. As in free beer.
2. You’ve heard what cloud is and why cloud matters, now learn how to cloud.
3. Learn why hybrid cloud is the next cloud.
4. Come away with action items you can implement the next day.
5. Find the right fit for your application(s)

Agenda Snippets

1. Choosing the right datastore and polyglot persistence
2. The Five Pillars of Cloudiness
3. Why hybrid cloud is the next cloud
4. Everything is code

Unlocked’s first stop is Friday, June 14 in New York City at the SoHo House in Manhattan. Future Unlocked events are planned for London, Portland, San Francisco, New Orleans, Chicago and Hong Kong. Check out the Unlocked web site for specific dates and locations: unlocked.io/#RoadshowDates

These events are for developers, engineers and technical decision makers. They are small by design, and we want to encourage a collaborative environment and engaging discussion.

The Rackspace team is in New York City all week for Cloud Expo, so stop by the Rackspace booth to say hello and ask us any questions you may have about hybrid clouds. You can also play the Unlock the Cloud game for a chance to win some sweet prizes! If you don’t have a Cloud Expo pass yet and would like to attend, Rackspace has plenty of passes, so please reach out to us on Twitter or leave a comment!

For more information about Unlocked: The Hybrid Cloud, please check out the Unlocked webpage!

However, the approach that we took in this hangout was to look at the lifecycle of the project: how does monitoring affect planning, the build and maintenance of your solution? Here were some of the topics that came up, and as always you can watch the entire hangout below.

• Racker Drew Cox examined the importance of discussing what parts of your configuration need to be monitored to provide insight into key metrics for the health of your environment. This is important to do as you plan out your configuration to ensure that the critical pieces are being monitored before you get to the build stage.

• While you are planning, it is important to measure the right things. Find out the one metric that Racker Steve Katen said was the most underrated that you should consider monitoring.

• You shouldn’t simply deploy a monitoring plan and hope it works; you need to make sure that it is working according to plan. Drew discussed the importance of verifying the monitoring functionality by tripping the monitoring alerts on purpose.

• Finally, if you are monitoring memory and suddenly hit a wall, I offered some tips for how you can respond when hitting memory limits to help keep your server configuration online.

Remember that two very important things, monitoring and backups, are not set up by default for your configuration. This is because there are many different variables and preferences that customers have. However, it is extremely important to get these configured as you bring your system online. Rackspace is always here to help, and if you have questions about how to get them configured, be sure to give us a call when you are in the planning stage!

Don’t forget to check out this week’s Cloud Launch Team office hours over on the Rackspace Google+ Hangout at 1:00 p.m. CST where we will have our customer FLO Cycling stopping by to chat.

Curious what the Cloud Launch Team talked about in last week’s office hours? Check out a recap of their discussion on backing up your cloud configuration.

Staten has a strikingly basic definition of hybrid cloud – “a cloud service connected to anything.”

For Rackspace, our portfolio of services has become hybrid cloud, meaning that it is a seamless combination of dedicated bare metal servers, private cloud and/or public cloud, working together to deliver the best performance and cost, Engates explained.

“For our customers, the benefit is they don’t have to go all or nothing on a particular technology, “ Engates said. “They can move some pieces of their workload in the cloud, they can continue to have some pieces of their workload in a physically-dedicated environment for performance or security reasons and they can allow themselves to make that transition on a pace that makes sense for them.”

Many companies already may be using hybrid cloud without realizing it.

“You’re already hybrid and now it’s time to deal with it,” Staten said. “If your company has any SaaS application, that SaaS application is talking to something else” so you’re running a hybrid cloud and need to manage it now.

You can watch the entire webinar by clicking on the image below. Use the navigation on the right to jump to different parts, or watch all three parts.

Fanatical Support®

The relationship between customers and Rackers is at the very core of the Fanatical Support experience. By working together to build a resilient and scalable Open Cloud architecture from the beginning, we’re actively redefining how to best leverage cloud. Let’s collaborate from day one on a solution that makes the most sense for your applications instead of relying on last-minute heroics when your business can least afford it.

Getting started with the Rackspace Open Cloud™

This guide will familiarize you with everything you need to know as you start to use The Rackspace Open Cloud. The entry point is our Control Panel; please feel free to check out the Control Panel documentation or watch the demo video. If you prefer to use the RESTful API or language-specific SDKs to interface with the cloud directly, you can find more information at the developer portal.

If you are hungry for more please feel free to explore the guides for:

• Cloud Servers
• Load Balancers
• Block Storage
• Cloud Files

Availability zones

Since Rackspace guaranties that our data center network will be available 100% of the time in any given monthly billing period, excluding scheduled maintenance, you don’t need to use Availability Zones to maintain a high uptime.  We do, however, split our host servers into groups called cells. Each cell is on its own L2 network for both the public and ServiceNet networks. This separation helps prevent certain types of network interruptions from affecting all servers in a given data center.

We have multiple geographically separated regions in which you can build Cloud Servers. These include Dallas, Chicago, London, and soon Sydney. By mirroring your infrastructure between datacenters, you can achieve higher availability of your application. You can also store backups of your data to Cloud Files in a remote region to enable availability of your data as part of your disaster recovery plan.

Persistence

Our Cloud Server instances, provisioned on RAID10-backed hosts, have persistent storage which only goes away if the instance is deleted. Additionally we offer persistent Cloud Block Storage which is independent of the server instances and can be detached and reattached to a different server instance if needed. Public and ServiceNet IP addresses are yours for the life of the instance, however if you delete the instance an IP is assigned to, that IP is returned to the pool for other customers to use. Regardless of what storage methods you’re using, we recommend setting up backups and clustering your instances for greater redundancy and uptime.

Key pairs

SSH key pairs are not used by default, however you can inject files into your Cloud Server instance during the build process to distribute your keys, configuration files, or make any other small deviations from the image. This is useful if you’re spinning up servers programmatically and need to pass unique configuration parameters to each of them at build time. You can also simply add your key pair to a server and take an image of the server, then every new server built from that image will be easily accessible using your SSH key.

Security groups

Firewalling is done at the Cloud Server instance level by utilizing a software firewall such as iptables or Windows Firewall. We also offer hardware firewall options via our RackConnect® solution as well as third party security vendors like CloudPassage, Dome9, CloudSMS, and CloudFlare. As an additional layer of security, isolated networks can be created to allow for secure network communication among Rackspace Cloud instances.

Pricing and billing

Rackspace has a much simpler billing structure for our services. We do not bill you based on the number of IO operations you make or the number of API calls made. Cloud Files, for example, is simply billed based on your monthly storage usage and outbound bandwidth and has the unique benefit of tiered pricing. Cloud Load Balancers are billed based on the average number of concurrent users throughout the month. You’ll also want to be aware that our RedHat Linux distributions have an additional monthly fee for the licensing. We also sell additional IPv4 addresses for SSL usage.

Flavors

We have simple flavors that scale disk, memory, CPU, and network throughput together as the flavor size increases. Should you want to increase your disk size without increasing other resources, we would recommend attaching a Cloud Block Storage volume (either SATA or SSD) to your instance. Additionally, if your application has specific performance or security requirements that demand dedicated gear, we would suggest leveraging RackConnect. As a powerful hybrid solution, RackConnect allows you to blend your highly customizable bare metal configuration with Rackspace’s elastic cloud infrastructure.

Message queuing

Message queuing services are available from Rackspace solution partners, such as Iron.io and their IronMQ product. Porting is generally straightforward, and IronMQ offers performance and consistency at least equivalent to SQS. Iron.io offers SDKs for major languages, such as Ruby, Python, PHP, Java, Clojure, and Go. You may also opt to use your own message broker, such as RabbitMQ, which can run on your own Cloud Servers.

Autoscaling

Autoscaling, like disaster recovery, is not currently innate to the Cloud Servers product. To build an environment that scales resources up and down based on load, we recommend using a third party solution such as RightScale, Scalr, or ScaleXtreme available through our Rackspace Cloud Tools Marketplace. Alternatively, you can work with Cloud Monitoring, Service Registry, and Chef or Puppet to configure a similar self-aware environment that reacts to the demands of your application. Regardless of your scaling solution, it will be imperative that you’re architecting for horizontal growth.

Testing resources

It is very important to test all configurations before using them as a production environment. If you have a preferred method for testing, please use what you are comfortable with. If not, there are a number of great third-party tools available for you to use such as Blitz IO, LoadStorm, and Soasta.

Now you’re ready to get going on the Rackspace Open Cloud. As always, we’re here to help you if you need it. Happy migrating!

ANY USE OR CHANGES TO THIRD PARTY PRODUCTS AND/OR CONFIGURATIONS SHOULD BE MADE AT THE DISCRETION OF YOUR ADMINISTRATORS AND SUBJECT TO THE APPLICABLE TERMS AND CONDITIONS OF SUCH THIRD PARTY. EVEN THOUGH RACKSPACE PROVIDES THIS INFORMATION FOR HOW YOU MAY DEPLOY THIRD PARTY PRODUCTS OR SERVICES ON THE RACKSPACE CLOUD, RACKSPACE DOES NOT PROVIDE TECHNICAL SUPPORT FOR THIRD PARTY PRODUCTS, OTHER THAN SPECIFIED IN YOUR HOSTING SERVICES AGREEMENT YOU HAVE SIGNED WITH RACKSPACE AND RACKSPACE ACCEPTS NO RESPONSIBILITY FOR THIRD-PARTY PRODUCTS.

Third-party trademarks and trade names appearing on this page are the property of their respective owners. Such third-party trademarks have been printed in caps or initial caps and are used for referential purposes only. We do not intend our use or display of other companies’ tradenames, trademarks, or service marks to imply a relationship with, or endorsement or sponsorship of us by, these other companies.

To appreciate what has changed, it’s important to understand how cloud services are built. The vast majority of cloud services have two major components: 1) a “control plane” which is comprised of the API, provisioning system, database, etc; and 2) a “data plane” which is the actual resources that get provisioned via the control plane – in this case, cloud servers. (If you have a networking background, control and data planes may sound familiar.)

These components have different availability characteristics. It’s quite possible for the control plane to be down while the data plane is up (e.g. you can’t add servers because the API is down but your hosted web site is still up) as well as the data plane be down and the control plane up (e.g. the host running your web server crashes but you can create a replacement cloud server via the API).

Historically we have only guaranteed the Cloud Servers data plane and the new SLA adds control plane guarantee as well. This is meaningful for a couple of reasons:

1. Apps are increasingly integrating with infrastructure APIs to make dynamic adjustments and thus take on a large dependency on API availability. A control plane guarantee means you can rely on the Cloud Servers API to be there when you need it.
2. OpenStack has proven itself and we are ready to guarantee it.  Since its launch in the fall of 2012, Cloud Servers has handled approximately 650 million API requests with an overall uptime of 99.95%. At this time, we are guaranteeing a 99.9% control plane availability but have every intention of pushing it higher over time. Note also that we don’t cheat. We count all server side HTTP 5xx errors as unavailability, maintenance is not excluded, and we measure availability monthly.
3. Having both control and data plane guarantees means you can build apps the way you want. If you want to build a more traditional static app that doesn’t need to work around data plane failure, you can do that. The data plane guarantee is there. If you want to build an elastic app that integrates with the API to autoscale, you can do that as well. The control plane guarantee is there.  No forced complexity. The choice is yours.

While SLAs are important, they are more than legalese to us. They are promises we make to our customers. It’s part of how we deliver Fanatical Support. We hate downtime and we work hard every day to keep our promises and provide you with a powerful and reliable platform so you can do what you do great. Thanks for being a customer, and we hope the new SLA gives you even more confidence in Cloud Servers and OpenStack.