KML_FLASHEMBED_PROCESS_SCRIPT_CALLS

Author Archive

 

Selecting a Provider and Infrastructure for Running an In-Memory Database

Tuesday, August 19th, 2014 by

The need for database speed is always a given. Recently, application response time has been shown to not only provide customers with a better experience, but also directly impact the bottom line. Think about companies running mobile advertising networks that are paid for delivering an advertising impression to users swiping away at their mobile phones to flip to the next screen. If the ad doesn’t load, well, that equals lost revenue. For these customers, response time is mission-critical. A common solution for applications that require fast response times is to run the database in memory, also known as an in-memory database (IMDB). You can easily do so in the cloud; however, selecting the appropriate infrastructure and even the appropriate provider can be tricky. Depending on the provider, for example, there may be hidden charges, less-than-ideal network topologies, and in many cases, a poor selection of virtual machines.

image.png

So how do you choose a reliable provider? And do you know what you’re looking for in terms of infrastructure? There are 3 key requirements that will help you get started:

1. Know your database memory requirements

2. Identify your cloud provider requirements

3. Understand your infrastructure requirements
(more…) «Selecting a Provider and Infrastructure for Running an In-Memory Database»

Architecting for High Availability in the Cloud

Tuesday, July 22nd, 2014 by

An introduction to multi-cloud distributed application architecture

In this blog, we’ll explore how to architect a highly available (HA) distributed application in the cloud. For those new to the concept of high availability, I’m referring to the availability of the application cluster as well as the ability to failover or scale as needed. The ability to failover or scale out horizontally to meet demand ensures the application is highly available. Examples of applications that benefit from HA architectures are databases applications, file-sharing networks, social applications, health monitoring applications, and eCommerce websites. So, where do you start? The easiest way to understand the concepts is simply to walk through the 3 steps of a web application setup in the cloud.

Step 1: Setting up a distributed, fault-tolerant web application architecture

In general, the application architecture can be pretty simple: perhaps just a load-balanced web front end running on multiple servers and maybe a NoSQL database like Cassandra. When you’re developing, you can get away with a single server, but once you move into production you’ll want to snapshot your web front end and spread the application across multiple servers. This approach lets you balance traffic and scale out the web front end as needed. In GoGrid, you can do this for free using our Dynamic Load Balancers. Point and click to provision the servers as needed, and then point the load balancer(s) to those servers. The process is simple, so setting up a load-balanced web front end should only take a few minutes. Any data captured or used by the servers will of course be stored in the Cassandra cluster, which is already designed to be HA.

image

Deploying the Cassandra cluster. In GoGrid, you can use our 1-Button Deploy™ technology to set up the Cassandra cluster in about 10 minutes. This will provision the cluster for your database. Cassandra is built to be HA so if one server fails, the load is distributed across the cluster and your application isn’t impacted. Below is a sample Cassandra cluster. A minimal deployment has 3 nodes to ensure HA and the cluster is connected via the private VLAN. It’s a good idea to firewall the database servers and eliminate connectivity to the public VLAN. With our production 1-Button Deploy™ solution, the cluster is configured to include a firewall on-demand (for free). In another blog post I’ll discuss how to secure the entire environment: setting up firewalls around your database and your web application as well as working with IDS and IPS monitoring tools and DDoS mitigation services. For the moment, however, your database and web application clusters would look something like this:

image

(more…) «Architecting for High Availability in the Cloud»

Comparing Cloud Infrastructure Options for Running NoSQL Workloads

Friday, April 11th, 2014 by

A walk through in-memory, general compute, and mass storage options for Cassandra, MongoDB, Riak, and HBase workloads

I recently had the pleasure of attending Cassandra Tech Day in San Jose, a developer-focused event where people were learning about various options for deploying Cassandra clusters. As it turns out, there was a lot of buzz surrounding the new in-memory option for Cassandra and the use cases for it. This interest got me thinking about how to map the options customers have for running Big Data across clouds.

For a specific workload, NoSQL customers may want to have the following:

1. Access to mass storage servers for files and objects (not to be confused with block storage). Instead, we’re talking on-demand access to terabytes of raw spinning disk volumes for running a large storage array (think storage hub for Hadoop/HBase, Cassandra, or MongoDB).

2. Access to High RAM options for running in-memory with the fastest possible response times—the same times you’d need when running the in-memory version of Cassandra or even running Riak or Redis in-memory.

3. Access to high-performance SSDs to run balanced workloads. Think about what happens after you run a batch operation. If you’re relating information back to a product schema, you may want to push that data into something like PostgrSQL, SQL, or even MySQL and have access to block storage.

4. Access to general-purpose instances for dev and test or for workloads that don’t have specific performance SLAs. This ability is particularly important when you’re trialing and evaluating a variety of applications. GoGrid’s customer’s, for example, leverage our 1-Button Deploy™ technology to quickly spin up dev clusters of common NoSQL solutions from MongoDB to Cassandra, Riak, and HBase.

(more…) «Comparing Cloud Infrastructure Options for Running NoSQL Workloads»

How to Deploy a Riak Cluster in 5 Minutes on GoGrid

Friday, January 31st, 2014 by

The first big challenge to overcome with any new NoSQL database deployment is figuring out how to deploy the cluster in an environment that lets you scale as needed within a single data center and even across multiple data centers. To save cash, many customers make the mistake of trialing the product on cheap hardware with limited RAM across clusters that are inadequate for the application.

We think there’s a better way to run your evaluation. At GoGrid, we’ve made it possible to deploy a 5-node Riak cluster on beefy, high-performance machines with the click of a button. Check out the specs we’re providing as an orchestrated deployment using our 1-Button Deploy™ technology:

  • 5 nodes
  • 16 GB RAM per node
  • 16 cores per node
  • 640 GB storage per node
  • 10-Gbps network
  • 40-Gbps private network connectivity to additional Block Storage volumes (as needed)

Once the first cluster is deployed, you can point-and-click to add more nodes as you need them. Geek out for a moment on what you can do with this technology: You can run a user/session store for your application, use it to target and serve advertising, perform MapReduce operations, or any number of other things with just a few clicks of the mouse. And you can do it all in 4 easy steps.

Step 1: Login to GoGrid

To get started, login to your GoGrid account at https://my.gogrid.com to access the management console. If you don’t yet have an account, go ahead and create one: visit www.gogrid.com and click the Get Started button in the upper right-hand corner of the screen.

Step 2: Add New Infrastructure

(more…) «How to Deploy a Riak Cluster in 5 Minutes on GoGrid»

Implementing Big Data in the Cloud: 3 Pitfalls that Could Cost You Your Job

Monday, November 25th, 2013 by

In IT departments around the globe, CTOs, CIOs, and CEOs are asking the same question: “How can we use Big Data technologies to improve our platform operations?” Your particular role could be responsible for solving for a wide variety of use cases ranging from real-time monitoring and alerting to platform operations analysis or behavioral targeting and marketing operations. The solutions for each of these use cases vary widely as well. But no matter which Big Data solution you choose, make sure you avoid the following 3 pitfalls.

Pitfall #1: Assuming a single solution fits all use cases

In a recent post, Liam Eagle of 451 Research looked at GoGrid’s Big Data product set, which is purpose-built for handling different types of workloads. He noted that variety is the key here. There isn’t a single one-size-fits-all solution for all your use cases. At GoGrid, for example, many of our Big Data customers are using 3 to 5 solutions, depending on their use case, and their platform infrastructure typically spans a mix of cloud and dedicated servers running on a single VLAN. So when you’re evaluating solutions, it makes sense to try out a few, run some tests, and ensure you have the right solution for your particular workload. It’s easy for an executive to tell you, “I want to use Hadoop,” but it’s your job that’s on the line if Hadoop doesn’t meet your specific needs.

image

As I’m sure you already know, Big Data isn’t just about Hadoop. For starters, let’s talk about NoSQL solutions. The following table lays out a few options and their associated use cases to help illustrate the point.

Solution Common Use Cases Pros and Cons
Cassandra (more…) «Implementing Big Data in the Cloud: 3 Pitfalls that Could Cost You Your Job»