Our partner New Relic has always strived to make the lives of its customers easier with its SaaS-based APM tool. Now it’s made a good thing even better with the release of the New Relic Platform – a seamless new way to monitor the performance of any technology through the intuitive and easy-to-use New Relic interface.

With the New Relic Platform, you’ll be able to get in-depth, real time insight into the performance of each component of your application stack – from cloud services, to the database, caching, networking, queuing and more. And best of all? You’ll be able to do it from a single pane of glass to monitor all of the metrics you care about.

One of the New Relic Platform plugins launching today is created specifically for Rackspace users. With the Rackspace Load Balancers plugin, you can now monitor your load balancers within the New Relic interface. You can use the information it provides to monitor incoming and outgoing traffic separated by SSL and non-SSL, set alert thresholds and keep an eye on the performance of your load balancers. Click here to start using the plugin today and keep an eye out for more Rackspace plugins that are currently under development.

By the way, if you don’t already have a New Relic account, we’ve partnered with New Relic so all Rackspace customers get a free Standard account for life, through our Cloud Tools Marketplace. I’ll post again once the next plugin is available.

1. Is your provider here for the long haul? Read up on the provider’s history and successful track record as an email provider. Check out the provider’s customers, leadership team and investors, and look at what the media has to say about its reputation.
2. Are the provider’s archiving solutions easy to manage? Ask a potential provider to walk you through its policies, capabilities and procedures; pay particular attention to the vendor’s testing procedures for its archiving and backup systems.
3. Does the provider use state-of-the-art malware and spam protection? Clarify how anti-virus and anti-spam work to avoid a security catastrophe. Grab a demo account to test-drive it for yourself.
4. How responsive is the provider’s customer service? Look for a provider that guarantees response times, has a documented escalation policy and offers around the clock support.
5. What does the provider really tell you in its SLA? Know how the provider defines terms like “uptime” and “unplanned outage;” how the provider communicates with customers regarding outages; and how the provider compensates customers for outages.

To help you compare the email providers that make your short list, Step Seven gives you a customizable comparison sheet. Use it as a place to record the data gathered about providers to simplify the comparison process.

For the entire list of questions to ask an email provider and the provider comparison sheet, read or download the Business Email 101 Guide and check out Steps Six and Seven. Catch up on the previous chapter overviews here: Intro, Step One, Step Two, Step Three, and Steps Four & Five.

For our customers who might have a database server or an application that needs a very high performance with random reads and writes, we offer a Solid State Drive (SSD) that can help you achieve that level of performance. Before, with our competitors, you would have to buy several Standard volumes and RAID them together to improve the performance. Now, with our new SSD offering in Cloud Block Storage, you only have to purchase one drive to gain that performance.

And in true Rackspace style, you pay only for the amount of block storage that you provision. What’s better is that Cloud Block Storage is based on OpenStack, the open and scalable cloud operating system that we founded. This means that we won’t lock your data into one proprietary platform.

Your users count on your application to perform consistently, and you can count on Cloud Block Storage to deliver the performance that your app needs. Check out this webinar to hear J.R. Arredondo explain the different storage options and how they can help boost your business’ performance.

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. 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.

Below, we’ve compared our Rackspace email offerings in each category to give you an idea of the differences:

Hosted webmail is often confused with consumer-level free email services like Gmail or Yahoo. However, a business-grade hosted webmail system, like Rackspace Email, delivers business-focused features, such as an @yourbusiness domain and an SLA backed by financial compensation.

Businesses often turn to hosted Exchange to support mobility for power users, for deeper Outlook integration or to support other Microsoft apps like SharePoint or Active Directory. With the cost to stand up Exchange on-premise tipping $40,000, consuming Exchange as a fully-hosted product offers a lower barrier to entry and simplified ongoing management with security patches and upgrades handled by your email provider.

Businesses in highly regulated industries like health care and finance may be subject to security or compliance regulations that mandate messages be stored and transmitted on single-tenant hardware. These businesses can still reap the benefits of off-site Exchange server management with dedicated Exchange. Though dedicated Exchange servers live off-premise, IT staff is still responsible for management of SSL, spam and virus protection and storage.

Rackspace also offers customers an additional choice – Exchange Hybrid. In a typical business, users have different needs. For example, the CEO may need synced email, calendar and contacts across mobile devices, while the receptionist just needs to send an occasional message. Instead of buying webmail and stifling use for the CEO, or giving the receptionist unnecessary mobile capabilities, Exchange Hybrid allows a business to mix Exchange and Rackspace Email mailboxes on the same domain. This allows the CEO to get the necessary Exchange features without wasting money on a feature set the receptionist doesn’t need.

Get a deeper explanation of your business email shopping choices in the Business Email 101 Guide Step 4. Catch up on the previous chapter overviews here: Intro, Step One, Step Two and Step Three.

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.

These steps will take you from a fresh server instance to a fully functional Drupal application using some of the latest technologies and services used in the cloud.

No cloud account? No problem.

A cloud account is not required. A local virtual machine, a remote virtual machine or even a dedicated physical server can be used. This tutorial focuses more on development, deployment and automation paradigms; however, DBaaS and other cloud-related services work well and are easy to setup.

If you want to walk through this tutorial in the cloud, feel free to sign up for the Rackspace Cloud. But don’t forget: if you are using a cloud account it is important to remember that it costs money. While you only pay for what you use, please remember that simply leaving a VM running will incur costs. Once you are done with this tutorial, please delete your Cloud Servers and/or Cloud Databases.

We will use these tools in this tutorial:

• Linux (Ubuntu)
• Apache HTTP Server
• MySQL (Rackspace Cloud Databases)
• PHP
• Drupal
• Varnish Cache

Prerequisites

To get started, you need a fresh cloud server instance (or other server) running Ubuntu, with root or sudo access. You will also need a fresh database, with the host and user credentials handy to complete the Drupal install. That’s it! Now that you have these items, let’s begin.

Steps

1. Update your package manager

apt-get update

Updating your package manager ensures you have access to the latest software packages.

2. Install Puppet

apt-get install puppet

Puppet is available via the common repos. Installation is easy and we will add our own drupalstack puppet module to set everything up.

3. Install git

apt-get install git-core

We will need git to clone this repo and obtain the base Drupal application code and drupalstack Puppet module.

4. Clone this repo

git clone https://github.com/bighappyface/drupal-cloud-tutorial.git

Now that we have the code we can configure this server to run our Drupal application.

5. Copy our drupalstack module to the Puppet modules folder

cp -r drupal-cloud-tutorial/drupalstack /etc/puppet/modules/drupalstack

All Puppet modules from the Puppet Forge will be installed here as well.

6. Install Apache and configure

puppet apply -e "include drupalstack::apache"

View the Puppet class source

This class follows a standard pattern in Puppet: Package/File/Service.

Viewing the code in the manifest we see that it will install the apache2 package, copy over our drupal.conf file into the default Apache site, start the apache2 service and enable mod_rewrite.

7. Install PHP

puppet apply -e "include drupalstack::php"

View the Puppet class source

This class is very simple: install PHP and the necessary extensions for Drupal. Also, it installs libapache2-mod-php5 to ensure Apache and PHP work together.

8. Install and centralize Drupal core

puppet apply -e "include drupalstack::drupalcore"

View the Puppet class source

This class installs Drupal Core in a central location, /opt/Drupal, and creates a symlink titled current to point to the desired version. This is the beginning of a common practice of using a single Drupal install in a multi-site environment without storing Drupal Core in version control along with your application.

Also, this technique provides a simple method of upgrading/downgrading Drupal Core without modifying or deploying your application code.

To change Drupal Core, simply update the “$drupal_version” variable to the desired version and run the class.

9. Configure our Drupal requirements

puppet apply -e "include drupalstack::drupalapp"

View the Puppet class source

This class provides the most common final steps of setting up a new Drupal site. First, it copies our application code from within our drupalstack class into the path specified by the Apache vhost. Next, it copies the default.settings.php file into the appropriate settings.php file and sets the permissions necessary for the Drupal installation process to update the settings. Finally, it creates our files directory used for storing site media and sets permissions necessary to ensure we can write to it from within our Drupal application.

Lessons Learned

Again, a few special techniques and paradigms are used in this tutorial related to development, deployment and automation.

Development
Our Drupal application code is decoupled from a full copy of Drupal core. The benefits of this approach include:

1. Application-specific code under version control
2. Small file size
3. Easy upgrade of Drupal core via symlink update

Deployment
Our Drupal application is wrapped within a Puppet module that defines the full application stack necessary to run our whole application. The benefits of this approach include:

1. Application-specific stack configuration and essentials
2. Fire-and-forget design to deploy servers and application in isolation
3. Configuration under version control to adapt deployment process with application overtime

Automation
Our Puppet module provides a convenient and reliable method for maintaining our application configurations and dependencies. The benefits of this approach include:

1. Application-specific package, service and file inventory and documentation
2. Configuration under version control to adapt dependencies with application overtime
3. Limitless expansion and enhancement options for logging, monitoring and caching.

The options and possibilities facilitated with this technique are endless. This example is but a brief glimpse into the power behind these techniques, especially automation.

To drive the point home, here is a bonus!

Bonus

Drupal in the cloud runs great with a dedicated application server and (hopefully) separate database or DBaaS instance; however, with a single server instance running a single application, some resources must be available to make our application really fly!

Enter Varnish cache, an HTTP accelerator. We can install it on our server using a Drupal-specific configuration and store the raw HTTP output of our application in memory, along with all resources.

To get it going, apply the Puppet class as shown below:

puppet apply -e "include drupalstack::varnish"

Now that Varnish is installed and running we can access it via port 6081 on our server. After navigating a page or two all of the resources will be cached. You can confirm caching by inspecting the HTTP response headers of any resource and a special header titled “V-Cache” will contain either HIT or MISS (HIT coming from the cache server, MISS coming via passthrough of the cache server to Apache).

The HTML of each page is not configured to be cached due to the Drupal configuration and modules included in our repository. Configuring Drupal for Varnish is a bit beyond the scope of this example but that is all that is left and your application will be ready to fly full speed.

Next Steps

The steps above show each phase of configuring a server and deploying our application. If you are curious about next steps or how things could be improved, here are a few questions to help expand our application:

• After reviewing the Puppet manifests, can you think of a class that could combine these steps into a single step?
• With tools like Vagrant, could we tie our Puppet module into a provisioning service to automate spawning instances and applying our module?
• For deployment, could offerings such as Cloud Backup, Cloud Load Balancers, and Cloud Monitoring be integrated to improve your application’s stability, scalability and reliability?

The answer to these questions is yes and you have used some of the tools and technologies to build amazing and performant applications in the cloud. The paths forward are many and the next step is to follow them and learn.

Don’t Forget!

As mentioned above, if you used a cloud account for this tutorial don’t leave the servers or databases running unless you wish to pay for them. Even if they are not being used, they will incur a cost.

• Auditing your current email system for usage
• Polling users for pet peeves around the current email system
• Reviewing regulations governing email in your industry

As you complete these steps, the Business Email 101 Guide offers several tips to help you along the way. For example:

Talk to the right stakeholders. A desk-based service representative may have a completely different idea of what their email system should look like than a salesperson in the field. As such, it’s important to take a sampling of feedback from different departments and levels in the organization. Use techniques like Survey Monkey, small focus group meetings, or setup an inbox to gather feedback and suggestions on the new system. Parse all of this feedback into a set of the top repeated needs.

Gather and analyze system data: This phase helps you create a baseline for “checklist features” of the next system. Reviewing system logs, outage reports and other performance data from your current email system can reveal technology gaps that a new system needs to address. Use indicators like the amount of storage users consume, types of devices users access messages from and the average attachment size to guide your feature set requirements. Compare this data with your user polling to further refine what the new system must include.

Security compliance: Obvious measures like spam and virus filters can protect you from malicious code, but are you protected against less obvious threats like the inability to produce messages in a legal proceeding because your emails haven’t been properly archived? Once stakeholder and technology needs have been parsed, the next step is to compare your list with security and compliance needs. For example, mobile email in a highly regulated industry, though a top request from users, may prove too risky or costly to justify. Other requirements around data retention, disaster recovery and privacy should be weighed as well. For example, the free consumer-level email currently in use may be great for the budget, but introduce privacy holes and weak SLAs that make it too risky to use.

For the full list of considerations when developing requirements, read or download the Business Email 101 Guide and turn to Step Three. Catch up on the previous chapter overviews here: Intro, Step One and Step Two.

How much time and effort have you put into your WordPress website? What would it cost you to replace it all from the beginning? How many hackers are knocking on your website’s doors and windows right now to see what gives way?

Setting up a backup solution should be the first thing you do after installing WordPress. As the author of UpdraftPlus – the highest-rated backup plugin the wordpress.org, and one of only two automated backup plugins to have scored eight points at rankwp.com – I’m really pleased to see Rackspace Cloud Files as a fully supported cloud backup option.

While developing for Cloud Files, I appreciated its easy-to-use web interface. I had no problems with it “under the hood” either. UpdraftPlus Backup/Restore supports backups into Cloud Files fully:

• It supports all setups that WordPress supports (including Windows servers and PHP 5.2,  which is still used by 62 percent  of WordPress sites, but is not supported by many backup plugins; see http://wordpress.org/about/stats/).
• It supports all sizes of website. No matter how big the created backup zip archives are, it can upload them into Cloud Files in chunks, and resume from wherever it left off – automatically, without you needing to watch it.
• It’s not just a backup plugin – UpdraftPlus also includes easy downloading of your backups, and easy restoring from the WordPress dashboard.
• Comprehensive help and commercial support is available; see http://updraftplus.com.

It also offers all of the standard features you’d look for in a backup plugin, including:

• Easy setup without jargon – just a single page with a few simple options: When do you want your backups to run, and where do you want to send them to?
• Automatic scheduling – choose to run your backups multiple times a day, once a day, weekly, fortnightly or monthly. Choose how many backups to keep historically (i.e. automatic deletion of unwanted backups).
• Email notifications – receive a message when your backup completes.

UpdraftPlus Backup/Restore is tried-and-tested; it has an estimated 20,000 active users, according to rankwp.com. And, best of all, it’s free. For more advanced users, a premium version with professional support and more features is also available.

Setup on Cloud Files is very easy, you just need to copy-and-paste the “API key” from your Cloud Files console into the settings, choose the name of a container and you’re done. Press the “test” button, and it’ll confirm that everything is well.

To get started, use the usual WordPress plugin installer from your dashboard; or for a full guide with screenshots, go to http://updraftplus.com/download/. Don’t put it off, because the hackers won’t.