The following press release came out today about GoGrid’s parent company, ServePath, and discusses how Gartner has included ServePath as a “Cool Vendor” for development done under the GoGrid brand as related to Cloud Computing.

ServePath Named “Cool Vendor” by Leading Analyst Firm

Vendors selected for the “Cool Vendor report” are innovative, impactful and intriguing

San Francisco, CA April 27, 2009 — ServePath, LLC has been included in the list of “Cool Vendors” in the April 2009 “Cool Vendors in Cloud Computing Systems and Application Infrastructure, 2009” report by Gartner, Inc.

The “Cool Vendor” report by Gartner, Inc. showcases key findings and recommendations to consider when evaluating Cloud server infrastructure services and companies. As defined by Gartner, Cloud services are divided into two general categories: infrastructure and applications. ServePath’s Cloud Computing division, GoGrid, represents excellence within both cloud categories as is evidenced through the Gartner “Cool Vendor” selection of ServePath. The report is available on the Gartner website for a limited time.

“We believe the recognition we have received by Gartner’s selection of ServePath for the ‘Cool Vendor’ Report further affirms our pioneering position within the Cloud Computing Infrastructure marketplace,” said John Keagy, CEO and Co-Founder of GoGrid and parent company, ServePath. “As innovators in the hosting industry, we firmly believe that Cloud Computing with a GoGrid cloudcenter exemplifies Cloud technology at its finest.”

GoGrid is the only Cloud Infrastructure vendor that supports the automated instantiation of Windows Server 2003 and 2008, CentOS and Red Hat Enterprise Linux Cloud servers through a user friendly GUI or the GoGrid API. Customers can instantly deploy servers and quickly and easily create cloudcenters (datacenters-in-the-sky) using a variety of tools and features that are included in GoGrid, including free hardware-based F5 load balancing, Cloud servers, Cloud Storage, public and private networks and Cloud Connect, which enables Cloud infrastructures to be connected to dedicated or colocated backend environments via private, dedicated megabit connections.

Cloud Connect handles database servers, transcoding and statistical analysis environments on custom, managed hardware with the power and I/O to perform well. Entire cloudcenters on GoGrid are easily controlled and managed by an industry-recognized web interface or programmatically via a REST-like API.

GoGrid offers customers including startups, small/medium businesses, government and enterprises, the ability to provision, scale and manage complex and robust server networks and infrastructures quickly and easily in the Cloud.

About Gartner’s Cool Vendors Selection Process

Gartner’s listing does not constitute an exhaustive list of vendors in any given technology area, but rather is designed to highlight interesting, new and innovative vendors, products and services. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness of a particular purpose.

Gartner defines a cool vendor as a company that offers technologies or solutions that are: Innovative, enable users to do things they couldn’t do before; Impactful, have, or will have, business impact (not just technology for the sake of technology); Intriguing, have caught Gartner’s interest or curiosity in approximately the past six months.

The full release can be viewed here.

If you are a GoGrid customer, you recently received the April GoGrid newsletter that talks about one of the exciting new features coming from GoGrid, specifically “Personal Server Images” which we call “MyGSIs.”

Definitions

First, it probably would be helpful to understand some of the new & current terms we are using:

• Base GoGrid Server Image is a standard GoGrid server images (e.g., Windows or Linux) that is created by GoGrid and currently available within the GoGrid system for deploying servers
  
• Image Sandbox is a development environment where you can create a “MyGSI.” Server Images created within the Sandbox are unique in that they have a predefined RAM allocation and hard drive sizes and are only used temporarily to create a Server Image. Images created within the Sandbox contain any and all custom code or applications that you choose to put on them.
  
• MyGSIs are based on either a Base GoGrid Server Image or other MyGSIs but where you have the ability to personally configure, customize and save it to your liking from the Image Sandbox environment. They are used to spawn or instantiate new custom servers within GoGrid, with all your customizations, code and applications present.
  

Think of MyGSIs as originals that can be used to make copies, much the way you would have a Golden Master CD and you would make copies or clones based off of that Golden Master.

Usage

From a high level, creating a Sandbox Image can be done in 3 easy steps:

1. Add an Image Sandbox;
2. Install, Configure & Prepare (bundling scripts) your Image Sandbox for imaging;
3. Save your Server Image from your Image Sandbox to your personal Images repository on Cloud Storage.

With a bit more granularity, it is a way for you to build and save a custom and personal server image. MyGSIs are created like this:

1. Add an Image Sandbox (an Image Sandbox has a server “development environment” of 2 GB of RAM and 20 GB of storage);
2. Remotely log in to the Server you are creating within the Image Sandbox via SSH or RDC (just as you would with a normal Cloud Server on GoGrid) and upload your applications or code. Configure the server to your exact specifications and lastly run “bundling scripts” which we provide to prepare the Image Sandbox for imaging;
3. Save new, MyGSIs from your Image Sandbox to GoGrid Cloud Storage. Note: you can store unlimited server images in Cloud Storage;
4. Deploy new server instances using the saved MyGSI which are great for rapid horizontal scaling, changing RAM allocations, or re-imaging a server (see “High-level Use Cases” below)

The monthly price to store a MyGSI relates to the amount of data in the contained within that Image. For example, if your Image contains 5 GB of data (your code and Operating System), you pay roughly $0.45/month. We compress the Image before it goes to Cloud Storage, so your 5 GB Server Image becomes roughly 3 GB, saving you some money in the process. GoGrid Cloud Storage costs $0.15/GB and the first 10 GB are free.

A Personal Server Image can be deployed as a new Server Instance by simply selecting the appropriate image from your repository, configuring the amount of RAM and the IP address of the new server instance, naming it and deploying. It really is that simple.

However, there are some IMPORTANT changes to workflow that you should start considering now.

Current Workflow (Pre-MyGSIs)

Right now, with GoGrid, a common workflow might consist of the following:

1. Create Web/App Servers individually based on Base GoGrid Server Images
2. Create DB Servers individually based on Base Server GoGrid Images
3. Configure Web/App Servers individually
4. Configure DB Server individually
5. Create Load Balancer
6. Tie it all together via a private network

While this is very straight forward and easy to do currently on GoGrid, if you are deploying and configuring large infrastructures, this process can become a bit time consuming and increases the chance of mis-configuration or human errors. We understand this and thus MyGSIs were born.

Future Workflow (MyGSIs)

It is VERY IMPORTANT to review this new workflow model. Following it will save you time and money as well as reduce the possibility for error.

In the current workflow (pre-MyGSIs), you focus on creating an infrastructure “live”, that is to say, configuring servers real-time that will be used in production. It’s a one-to-one setup, one server at a time. Once MyGSIs are rolled out, you can prototype and develop your server configurations within a specialized environment and create “masters” of which copies are spawned to production. This is more of a one-to-many setup where one “Golden Image” or “Golden Master” can be used to deploy multiple copies, all based on the original. This allows for better and faster scalability and much easier management of your infrastructure.

The new workflow would consist of:

1. Create & Configure a Web/App within the Image Sandbox and save as a MyGSI
2. Create & Configure a DB within the Image Sandbox and save as a MyGSI
3. Deploy multiple instances of new GoGrid Web/App Servers based on the MyGSI
4. Deploy multiple instances of new GoGrid DB Servers based on the MyGSI
5. Create Load Balancer
6. Tie it all together via a private network

Note: once you save your MyGSI, your Image Sandbox is “destroyed” and the Image is copied to Cloud Storage as a server image.

While this is the same amount of steps, if you are creating a redundant & high availability environment (see “How to Set Up High Availability Web Applications in the Cloud using GoGrid“), you actually eliminate some steps because you only have to configure your servers (the MyGSIs) once and then deploy multiple server instances based on that MyGSI with a couple of clicks. In the pre-MyGSI workflow, you would need additional steps for each server you configure and deploy.

So, the important thing to consider as you plan for this exciting release is that you will start your workflow within the Image Sandbox and then move from there. Unfortunately, there will not be a way with this first release to turn actively deployed GoGrid servers into Personal Server Image.

High-level Use Cases

There are several use cases that come to mind that will be simplified with the MyGSI release. While I will not go into the details, here are a few that people should consider:

• True Horizontal Scaling
• Changing & Optimizing RAM Allocations
• Re-imaging Servers
• Disaster Recovery & Failover Environments

I will explore some of these use cases in subsequent posts.

Lastly, for those of you ready to try out GoGrid, I encourage you to set up a GoGrid account NOW. You will be able to familiarize yourself with its workings, test out the different images and templates currently available and then design your strategy for when MyGSIs roll out.

Be sure to check the GoGrid blog for updates on this release which is expected to roll out at the end of July. I hope you are as excited as I am about this upcoming feature release!

Web Applications like WordPress, Drupal, Joomla, SugarCRM and others are all the rage and have been for quite a while. The huge availability of Open Source applications, typically based on Linux, Apache, mySQL and PHP (LAMP stacks) that you can find in SourceForge or other repositories, makes the implementation of powerful web-based solutions a snap. Once you find the web application of your dreams, the next step is finding a hosting provider. There are many VPS (Virtual Private Server) hosting providers that offer shared hosting at pennies on the dollar. But with those VPS solutions, you are left with exactly that, a “shared” environment. So, if someone else on your shared server is running bad scripts or code that sucks up resources on your server, you are affected with little or no recourse to resolve other than to complain, moan or move to a different provider.

So, as you grow (or as your service deteriorates due to the resource-sucking of others on your shared box), you are left with a decision of what to do next. Many people choose the most obvious upgrade path of leasing a dedicated server (e.g., at ServePath, we offer dedicated, managed hosting) or colocating (where you bring your own hardware and a hosting provider like Coloserve leases space, power, cooling, security and bandwidth). But now, you have another option that truly fits the model of delivering scalable web hosting…put in in the Cloud, with GoGrid, for example.

Recently I helped map out the implementation of a secure, redundant, load-balanced web application in the Cloud using GoGrid.

Original Setup

A client originally set up the following implementation of a WordPress blog on GoGrid:

• One Web/Application Server
  • CentOS 32-bit
  • 2 GB RAM
  • LAMP stack
  • Web Application – WordPress 2.7
• One DB Server
  • CentOS 64-bit
  • 2 GB RAM
  • mySQL 5.0

There were some immediate concerns that we noticed after evaluating the original design:

• No ability to gracefully scale with traffic demands
• There was a Public IP connection to DB Server
• No “root” password set on DB Server
• No DB backups
• No Web Server redundancy

While this setup is not all that bad (at least in comparison to a VPS solution), it is not ideal. After we put our heads together, we came up with a much more elegant solution that uses many of the advantages of the Cloud, but also capitalizing on standard high-availability network infrastructures as available on GoGrid.

Optimized Setup

Ideally, when you set up a redundant, high-availability network, you want to eliminate various points of failure as well as optimize the infrastructure to handle demand yet be scalable as well. With traditional or Do-It-Yourself hosting, people frequently either over-buy or under-buy their infrastructure which either wastes times, money and/or resources or cripples you when you are successful and can’t keep up with demand. I recommend that you read Randy Bias’ Whitepaper called “Scaling Your Internet Business” for some scalability insight.

So, what we wanted to achieve with our re-design was something much more secure and reliable. What we came up with is not necessarily a de facto standard, but rather a recommendation and a “how-to-implement” guide. You can obviously do more (e.g., more servers) or take shortcuts. It’s really your call. Here is what we did as a “better” solution.

• Two Web/Application Servers
  • CentOS 64-bit
  • 1 GB RAM
  • LAMP Stack
  • Web Application – WordPress 2.7
• One DB Server
  • CentOS 64-bit
  • 2 GB RAM
  • mySQL 5.0
• GoGrid Cloud Storage
• F5 Load Balancing

That was the list of GoGrid infrastructure components we ended up using. But HOW and WHY we used these is the important thing to document here. Once again, a quick laundry list:

• Why Load-Balance? GoGrid offers free F5 Load Balancing. It is very important for a high-availability, redundant web application infrastructure to use a load balancer. It can, based on the configuration, equally spread traffic between all of your web-servers, as well as automatically fail over traffic to a different server should one go down, without downtime or interruption to service.
• Why use Cloud Storage?There are many reasons why to use Cloud Storage in this type of environment:
  • GoGrid provides 10 GB of free Cloud Storage which can be mounted by your Web, Application and/or DB servers. Free is always nice!
  • Cloud Storage has high-throughput via gigabit connections, redundancy from daily backups and is infinitely scalable. Cloud Storage was GREAT for our solution, because we configured the WordPress environment to actually look at a “symlink”((symbolic-link, like an alias or pointer to another file or directory or location)) on the Web Server that connects to the physical files residing on Cloud Storage.
  • Web Application Clustering – one of the biggest issues with running hosted PHP Web applications (for example), is that you have to keep the PHP files locally on a server. This makes setting up a “clustered” environment much more difficult as you need to update multiple files on multiple servers should you have to change or update code. While you could set up some sort of complex “rsync” session, this gets complicated and potentially confusing. By pointing all of the Web/App Servers to Cloud Storage, the source files (PHP files) are at a single point and much more easy to manage.
  • It can act as a repository for back-ups from DB servers and/or Web servers
• Why reduce the amount of RAM on the Web/App Servers? Most of the processing power is needed at the database level and not necessarily at the Web/Application level. So, by splitting the RAM out from one 2GB server into two servers with 1GB of RAM each, there is no direct cost impact, yet you gain redundancy. Also, since 10GB of data on Cloud Storage is free, you do not need to use the persistent storage available on the Web/App servers (note: more RAM = larger persistent file storage).
• Why multiple Servers? First, please see earlier point re: load balancer. GoGrid uses an algorithm to determine which node new Servers are instantiated, ensuring that servers are distributed over different nodes. If a GoGrid node encounters an issue and potentially rendering a server as inaccessible, the load balancer will automatically route traffic to other available servers on different nodes. Since new server instantiations are automatically created on different nodes, the built-in GoGrid redundancy enables high-availability.

So, HOW did we do it all? We have published a very detailed Wiki article titled “How to Set Up a Load Balanced and Redundant Web Application on GoGrid” which goes through the following items (note: the steps listed in the wiki article assume that you have fairly good familiarity with Linux and system administration therein):

• 1 Getting Started
  • 1.1 Overview
  • 1.2 Web/App Servers
  • 1.3 Database Servers
  • 1.4 Cloud Storage
  • 1.5 F5 Load Balancers
• 2 Configuring Your Servers
• 3 Configuring your Web Servers
• 4 Configuring Your Database Servers
  • 4.1 MySQL Master-Master Replication
    • 4.1.1 Configuring db01
    • 4.1.2 Configuring db02
    • 4.1.3 Verify the MySQL Replication Status
• 5 Setting Up Backups
  • 5.1 Configuring Backups on web01
  • 5.2 Configuring Backups on web02
  • 5.3 Configuring Backups on db01
  • 5.4 Configuring Backups on db02
• 6 Restoring from Backups
  • 6.1 Restoring Web Servers
  • 6.2 Restoring Database Servers
  • 6.3 Testing

There are obvious permutations that can be implemented on top of this design that we have outlined. You could add more Web/App Servers, connect via Cloud Connect to a dedicated or colocated environment, or change the backup timing and strategies, for example.

Also, with the design we wrote, there still remains one important single point-of-failure, that of the MySQL database. Within the next few weeks, we will be compiling a “How To” on setting up a MySQL Replication environment within GoGrid in a Master-Master configuration, using many of the same methodologies outlined within the GoGrid Wiki article. However, assuming that you have fairly strong knowledge of restoring MySQL databases from MySQL dump backups, you can quickly create a new MySQL server and restore data from a previous backup, should you happen across a server failure.

How are you using GoGrid for your Web Applications? Do you have a particular infrastructure implementation that you are proud of? I want to know!

GoGrid was an exhibitor at the 2009 Web 2.0 Expo in San Francisco last week. It’s a show devoted to Web 2.0 companies and technologies. We host many Web 2.0-ers on GoGrid, mainly because it’s an ideal environment to set up a dynamically scalable infrastructure, billed on a pay-as-you-go basis. Perfect for that boot-strapped company or business that are really watching their IT bottom line and don’t want huge capital expenditures hitting their already tight budgets.

Here are some photos taken by GoGrid’s Tim Wayne.

We hope to see you at our next event. Be sure to watch our GoGrid Events page for details.

Many GoGrid users may have noticed a new tab that has appeared within the GoGrid Web Interface. The new "Jobs" tab is a great new addition for those who want details on any action or activity that has taken place on an object (e.g., Server, Load Balancer, Cloud Storage) within their GoGrid account.

Think of this new section as your GoGrid log file. It keeps track of actions that you have made on objects in your account, broken down chronologically. In fact, since we have been keeping an internal log for some time, many of your older activities prior to the release of this feature will show up in your log. Also, if you use the GoGrid API, any requests made through the API show up in the Job section as well.

GoGrid actions that are currently tracked are:

• Add Server
• Delete Server
• Restart Server
• Add Load Balancer
• Delete Load Balancer
• Add Cloud Storage

All actions are also logged with the following information:

• Date & Time (UTC timestamp – a good time converter can be found here)
• Action Details
• Action Status
• User that requested the action

Job History List

The Job list contains all of the actions that have taken place on your GoGrid account. The icons represent both the Action and the Object and are followed by a brief name of the event. Date, action Status and User that requested the action follow that.

Job Details

The power is in the details. You can drill down each object action to see greater detail on what transpired. Shown below are: Create Server, Start Server, Create Load Balancer and Create Cloud Storage. You always have full insight into who requested the action and what state the object is in. Current states include:

• Created: The time and date the job request was made.
• Queued: The time and date the job was received.
• Processing: The time and date the job began processing.
• Succeeded:The time and date the job was completed.
• Fatal: The time and date the job became fatal (if applicable). This means the job failed and could not be executed to completion.
• Canceled: The time and date the job was canceled by the system (if applicable).
• Failed: The time and date the job failed (if applicable). This may occur multiple times as a job can fail and then be queued again before succeeding or becoming fatal.

Search Box

If you need to search for a particular object quickly, you can use the Search Box.

Advanced Searching

To quickly drill down to a specific action on a specific object, or to constrain your search by a date range, use the Advanced Search.

We would love to hear what you think about this feature. It’s a great way to keep track of you and other users in your account and what they have been doing with GoGrid. As always, we hope you like it!