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!

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.

Here’s a recap of some of the more poignant topics that we discussed in last week’s hangout:

• There are several ways that you can backup your web app. We have lots of tools at Rackspace to help you with this, including snapshots, images and Cloud Backup. You can also use GitHub so you don’t have to worry about whether your image snapshot is up to date with your code.

• While having backups is important, it is equally important to consider where those backups reside. Racker Drew Cox says that having backups in multiple locations is a sound strategy for protecting important information. Check out the video to hear Jeff Olsen, our customer and cloud fan, talk about how you can put your critical data in a “safety deposit” box.

• Rackspace customer Eddie had a very technical question about backing up an eventually consistent NoSQL cluster. Here are some general best practices for rolling backups.

• Our customer, Eddie, also needed to know how to get in touch with Rackspace support. Drew goes over some of the best ways that customers can get assistance.

That’s a wrap for this week’s Cloud Launch Team office hours. If you missed it, scroll down to watch a video of the hangout. And don’t forget that our next office hours will be Thursday at 1:00 p.m. CST. If you have a question about monitoring, or the cloud in general, we hope you’re able to join the conversation. See you then!

Check out the previous Cloud Launch Team office hours where RightScale joined the conversation on auto-scaling in the cloud.

• Vijay Tolani, Cloud Solutions Engineer at RightScale, give a presentation about auto-scaling in the cloud as well as how RightScale works. If you are interested in learning more, you can jump directly to the presentation in the Hangout by clicking here.

• I found Vijay’s notion of a “success disaster” to be particularly interesting. A “success disaster” is an event for your app or site that has traffic that exceeds your wildest dreams. However, your infrastructure is not able to handle it and the site goes down. One of the things that the Cloud Launch Team does for our customers is to encourage them to have a plan in place (often including a scaling solution such as RightScale) to help the configuration grow with traffic.

• One of the beautiful things about the cloud is the ability to be in multiple locales; RightScale works with customers to setup infrastructure across various environments with a global load balancer. This geographical redundancy is particularly helpful to set up a disaster recovery plan or even scaling up your configuration to handle the load.

• We also got to discuss the difference between scaling for a known high traffic event (think of a Super Bowl commercial) using a tool like RightScale instead of doing it by hand. Vijay pointed out that while many people think about scaling up in the cloud, they fail to consider the time and effort to scale down after the event is over. He notes that it is important to terminate servers right when the event is over to help save costs and advises us to think of the entire life cycle of scaling.

Have a question about the cloud? Be sure to catch me and other Cloud Launch Rackers in the next Google+ Hangout this Thursday from 1:00 p.m. to 2:00 p.m. CST!

Our “Office Hours Hangouts” are active, multi-directional conversations – everyone gets involved. One of the best moments so far was when one customer answered a question posed by another customer. I can always give a good “Rackspace approved” answer, but a real life, tried and tested solution actively employed by another customer can be a much better answer than any I could give.

I wanted to make sure that as many Rackspace Cloud consumers as possible have a chance to ask and answer questions. Our Rackspace Cloud Office Hours Hangouts are Thursdays from 1 p.m. to 2 p.m. CDT, starting May 2, 2013. Our first topic is building a scalable WordPress configuration in the cloud. Some future topics include:

• Cloud Files – cloud storage and CDN delivery
• Cloud Load Balancers – load balancing as a service
• Cloud Monitoring  - monitor both cloud and dedicated servers
• Cloud Database – high performance database on the cloud
• Cloud Block Storage – for dependable performance from your database

We hope to see a lot of new participants. Instructions on how to join our hangout are as follows:

1. Head over to the Rackspace G+ page and click “Follow”
2. Find the G+ Event Post for the next Cloud Office Hours and RSVP
3. Go to our G+ page a few minutes prior to the hangout time and wait for your invite
4. If you don’t RSVP, no worries, just find the Event Post for the current Cloud Office Hours and leave a comment saying you would like to join…then wait for the invite…in the meantime you can watch what is going on because it is going to be livestreamed.

Sign up early to have a better chance of joining the hangout.

Our Google+ page will have archived versions of all of our hangouts, so you can watch past hangouts or just see what else we are talking about.

Also, we’re always looking for suggestions for discussion topics. If you have a suggestion, feel free to comment here, or share the topic with us on Google Plus. Hope to see you all on a hangout soon.

When we started FLO Cycling, one of the last things we thought we would have to worry about was crashing web servers. As a new manufacturer of a product, we assumed there would be production delays, design modifications and marketing/sales struggles, but we never assumed we’d have to learn how to manage high end web servers.  Well… you live and you learn.

Our site traffic is pretty unique. On a day-to-day basis our web traffic is low, but on our sales days we get hammered for about 30 to 60 minutes! This massive spike in traffic caused our site to crash several times during our first three Pre-Orders. Being a new company it was acceptable the first time, but when we crashed again during Pre-Order 3 we were simply embarrassed and knew we needed to fix the problem. In the end Rackspace (our current and awesome hosting company) provided a solution that was, in short, perfect… more on Rackspace below.

At FLO Cycling, we’ve covered a lot of our start-up process through our blog and on our “About Us” page. This article discusses how we’ve overcome a major road block in our start up process. This really has nothing to do with cycling wheels but nonetheless we think it’s a cool story. Here is our web server evolution from Pre-Order 1 to present day.

Website Hosting Intro

For those who don’t know, a web host is a company that “hosts” your website. When you sign up for a hosting account, you place all of your website files on a server and those files are given an address (known as an IP Address). When a user types a url like www.flocycling.com into their browser, the user is sent to that IP address where they can view the website.

There are typically four types of hosting accounts that you can purchase:

1. Shared – With a shared account, you share a webserver with many other websites. All resources like RAM are shared between all of the sites. If more than one site is having a busy traffic day, the server can quickly become problematic. This option is very affordable – prices typically range from $4 per month  to $15 per month.
2. VPS – A VPS or Virtual Private Server is similar to a shared server where more than one website resides on the same server. The difference is resources are allocated to you and only you. You are given a guarantee of maybe 1GB of RAM instead of “getting what is left over on a shared server.” This option can be cost effective for sites that experience higher than normal traffic and want to manage there own server settings. Prices typically range from $30 per month to $100 per month.
3. Dedicated – With a dedicated server, you are the only website on a server and all of the resources of that server are yours. This is great for high traffic websites but it’s quite expensive, typically ranging from $150 per month to more than $500 per month with the more reputable solutions easily being $400 or more per month.
4. Cloud Servers – In a way cloud servers are like VPS servers but they are extremely flexible and have the ability to be modified on the fly. Rackspace is truly the master of cloud web hosting. With the click of a button you can convert a webserver’s RAM from 512MB to 30GB when you expect a jump in traffic. It also has a ton of features that give server administrators endless flexibility. The best thing is, you pay for what you use – you can pay as little as $17 per month and when your traffic is about to spike you pay pennies an hour for the increase in resources. Our full solution will be highlighted below.

The Evolution

Pre-Order 1 – Shared Server RAM Unknown (likely less than 1GB)
After several lengthy discussions with our first hosting provider (not Rackspace) we were assured we could take our anticipated traffic load. Well… they were wrong. There were thousands of requests sent to our shared server within seconds of our store opening and the site crashed immediately. After five minutes of shear panic, we got the site back up, but there were many problems. The site was horrendously slow, which caused dozens of people to hit refresh on our payment screen resulting in dozens of duplicate charges. Our database crashed, meaning customers’ details weren’t complete and confirmation emails were not sent out. It took about four days to dig ourselves out of that mess.

Pre-Order 2 – Dedicated Server with 4BG of RAM
We knew during our next sale that we wanted to be on a dedicated server, but as a new company $400 per month was simply something we couldn’t afford. We moved to a new hosting company that informed us it could easily move us from a shared hosting account to a dedicated server whenever we requested it. The best part was we only had to pay for the time we used. What they failed to tell us was the process of scaling up or down would cause our site to be down and could take up to a week in either direction. We didn’t crash during Pre-Order 2, but we couldn’t handle the downtime.

Pre-Order 3 – VPS with 2GB of RAM
We stayed with the same host that we used for Pre-Order 2. After several discussions with the systems administration team we were pretty much guaranteed we wouldn’t crash with a 2GB VPS. Yup… you guessed it… they were wrong. We crashed and we crashed badly. We were down for nearly an hour. We were embarrassed and needed a solution in a bad way.

The Solution – Rackspace with 128GB of RAM!
I contacted Rackspace after a friend recommended them. From the minute I placed my first call I knew we were in good hands. Rackspace has by far the best customer service I have seen in the business, and the flexibility of its solutions are endless. I’d like to say that they are not paying me to say this, I’m simply a very happy customer. After explaining our unique situation, Rackspace placed us in the Rackspace Startup Program and assigned a team to our project. The team taught us the ins and outs of the Rackspace system, and best practice solutions. After a month or so of tinkering (slow for me because I was learning), I finally had the system set up. Let’s take a look at it below.

Simple Server Architecture on the Left / FLO’s Robust Rackspace Server Architecture on the Right

The image above details two types of server architectures. The schematic on the left shows a very simplistic design. The website and database both reside on one server and when a user visits a url like flocycling.com, they go directly to that server. This system is what we crashed during both Pre-Order 1 and Pre-Order 3.

The system on the right is our much more robust Rackspace solution used during Pre-Order 4. This baby DIDN’T crash!  Here’s how it works:

A user visits flocycling.com and is first directed to a load balancer. The load balancer in our case was connected to four web servers that all contained a copy of the FLO Cycling website. The load balancer runs an algorithm that calculates which web server is the least busy and it sends the user to that web server. When the user requests a read or write to the database, the web server they are on connects to the database server. This system has several benefits, such as:

Redundancy – Running four identical web servers gives you redundancy. If one of your web servers becomes overloaded and crashes, the load balancer automatically removes that web server from its que and directs all traffic to the other three web servers.

Plenty of Resources – In the simplistic architecture design (shown in the above image) the web server and the database server both share the resources of one server. When you separate the web servers and database server, they have their own resources and are less likely to crash.

In total we had 128GB of RAM running for Pre-Order 4, which is 32 times larger than ever. Was it overkill? Yeah probably, but the site didn’t even flinch. Instead of our regular routine of crash, panic, upset our customers and begin disaster recovery mode, we sold our entire container of wheels in 12 minutes without a single website or server problem. The best part is that this massive system only cost an additional $5.28 for the hour of our Pre-Order. Yes, you heard that right, only $5.28. After the sale we clicked a few buttons and our site was back to a very affordable 1.5GB system. Rackspace provides the perfect solution for our unique needs.

I’d like to thank Rackspace for its support throughout this entire project and the ultimate success of Pre-Order 4! With our new website architecture we have one less thing to worry about!

CDN all the things

Compute is the most expensive part of the cloud – don’t waste those resources on the distribution of your content. The cloud has an entire infrastructure set up to not only ensure that your content is delivered speedily, but is also cached geographically for the next request. This outsources a sizable load on your server onto a cloud feature that is perfectly suited for this task.

Pro Tip: To prevent a total loss of connectivity, create a static landing page for your domain. If all else fails, your landing page will always be available.

If you’re in the cloud, use cloud architecture

More often than not, when we see a customer’s site fall down during a high traffic event, they’re hosting on a single server. Performance and stability on the cloud requires a distributed architecture to protect against any single point of failure and to leverage the infinite scalability that the cloud has to offer.

The easiest way to do this is to set up a Cloud Load Balancer in front of your configuration. Why? Because it will provide you a persistent IP for DNS, an extra layer of content caching, the ability to use custom error pages and, most importantly, the ability to be agile with your environment at a moment’s notice.

Don’t create a single point of failure, and don’t create several potential single points of failure all over your application. Instead, distribute your application into a tiered architecture.

Separate your web and database functions by creating multiple web nodes behind a load balancer, and separate nodes for your database(s). Every piece of your application should be redundant; as many pieces as possible should be on redundant, fault tolerant platform services, i.e. Cloud Load Balancers.

Pro Tip: If you think your traffic might be extra “spikey,” have some “hot spare” nodes already spun up and ready to be added to an existing load balanced cluster. Use a configuration manager like Chef or Puppet to assign the spares where needed.

Take a few minutes to set up monitoring

You can make all of the necessary changes to make your application strong and redundant, but if something does goes wrong, you need to know about it. Rackspace provides several different methods for monitoring your application – ping, port, HTTP Status, web page content and our third party partners also offer application level monitoring that can help you find problems before they take you down completely.

Pro Tip: Since most cloud-centric monitoring platforms, including our own, have hooks for an API, you can add in some code to your application to automatically respond to monitoring alerts with an appropriate reaction – i.e. spinning up a new web node when traffic spikes, and spinning it down as traffic subsides.

Create an emergency plan and conduct a “fire drill”

So what about when something unexpected happens? Your launch will go much more smoothly if you turn the unexpected into something expected. This means having a contingency plan in case your site becomes unavailable. Once you have your configuration set up, be sure to load test it. Find out what happens when you kill a server right as people are accessing your application, or how the site reacts when you add a server image. What if you perform a reboot?  Simulate high traffic events, make note of what happens and have the appropriate measures in place. Do you need to beef up your database? Or spin up additional web nodes? After you make those changes or additions, test it again! Also don’t forget to backup! You can never backup enough…go do it now, we are not kidding. Do it. Allow yourself ample time for this process so you’re as ready as possible for the big day.

Move your blog to Cloud Sites

Your application may be the bread and butter of your business. Keep your focus on your business by offloading the management of your blog to Cloud Sites. The Cloud Sites platform takes care of many of the single points of failure, but your blog may need to adjust to Cloud Sites. For example, serving dynamic MySQL / PHP every time will only beat on the shared Cloud Sites platform and limit your scalability, if not doom you. HTML is still the gold standard, and plug-ins like WordPress SuperCache will help you to stay afloat. Remember, CDN all the things!

Let us know about your High Traffic Event

You don’t have to do it on your own – we’re here to help. Call your hosting provider and let them know about your event. From our end, a launch beyond your wildest dreams looks a lot like a DDoS attack. If we know in advance, we can better respond. We can help you implement the suggestions mentioned and provide additional advice. Plus, we want to cheer you on! Call us today at 1-800-480-3163 to get started.

Allison Henslee and Jason Swindle from the Cloud Launch team contributed to this article.

Be sure to check out the Top 5 Reasons Startups Love The Open Cloud.