KML_FLASHEMBED_PROCESS_SCRIPT_CALLS

Archive for the ‘GoGrid’ Category

 

High RAM Cloud Servers for Distributed Caching

Tuesday, June 10th, 2014 by

GoGrid has just released High RAM Cloud Servers on our high-performance fabric. These servers are designed to provide a high amount of available RAM that is most commonly required for caching servers. Like our other recent product releases, these servers are all built on our redundant 10-Gbps public and private network.

High RAM Cloud Servers are available in the following configurations:

High RAM RAM Cores SSD Storage
X-Large 16 GB 4 40 GB
2X-Large 32 GB 8 40 GB
4X-Large 64 GB 16 40 GB
8X-Large 128 GB 28 40 GB
16X-Large 256 GB 40 40 GB

 

 

 

(more…) «High RAM Cloud Servers for Distributed Caching»

An “Expert Interview” with Kole Hicks, Sr. Director of Products at GoGrid

Thursday, May 8th, 2014 by

If you’re interested in learning the answers to many common Big Data implementation questions  Syncsort, a leading provider of Big Data integration solutions, recently posted an interesting blog with our very own Kole Hicks, Sr. Director of Products. In this interview, blogger Mark Underwood proposes several key questions to consider when beginning a Big Data project, starting with “What are the biggest obstacles?” and going all the way to “What are the in-house requirements for Big Data?”

Syncsort-blog

Check out the complete interview by clicking here.

And of course if you’re interested in a Big Data solutions integrator, the combination of Syncsort and GoGrid infrastructure might just be an ideal way to get you up and running with the push of a button!

You can learn more about Syncsort on its website.

FBI: Health Care Providers Need to Improve Security

Tuesday, May 6th, 2014 by

There’s no disputing that upon implementing cloud servers, physicians, nurses, and hospital administrators will be able to store and access patient information more easily than before. Although such an approach enables them to develop treatments for specific customers, IT professionals and government officials believe care facilities need to improve their security before progressing to the cloud.

Nurses and doctors accessing information.

Nurses and doctors accessing patient information.

A number of cloud solutions offer expanded data protection; however, the current state of many electronic health records systems is lackluster, at best. Data flowing between hospital PCs and mobile devices opens new avenues — creating an environment hackers could potentially exploit to steal sensitive personal health information.

An official security warning 
According to Reuters, the Federal Bureau of Investigation recently informed health care providers their cyber-security infrastructures were unsatisfactory compared to other industries. Although cyber criminals have been known to attack the retail and financial sectors, they could also use electronic records containing insurance and payment information to gain access to bank accounts, personal addresses, phone numbers, and other data.

Reuters obtained a private notice sent to hospital administrators criticizing their lax network defense programs. Issued earlier this month, the memo did not mention the Healthcare.gov breach, which has been criticized by professionals for numerous security flaws. It further implored recipients to contact the FBI in the event any breaches occurred.

The source stated that criminals typically favor health care information because it takes longer for victims to realize that any intelligence has been stolen. Although they often don’t leverage the information itself, hackers often sell such data on the black market. To deter infiltration attempts, some hospitals have invested in cloud infrastructure featuring applications that encrypt data as it flows through the networks.

(more…) «FBI: Health Care Providers Need to Improve Security»

HBase Made Simple

Wednesday, April 30th, 2014 by

GoGrid has just released its 1-Button Deploy™ of HBase, available to all customers in the US-West-1 data center. This technology makes it easy to deploy either a development or production HBase cluster on GoGrid’s high-performance infrastructure. GoGrid’s 1-Button Deploy™ technology combines the capabilities of one of the leading NoSQL databases with our expertise in building high-performance Cloud Servers.

HBase is a scalable, high-performance, open-source database. HBase is often called the Hadoop distributed database – it leverages the Hadoop framework but adds several capabilities such as real-time queries and the ability to organize data into a table-like structure. GoGrid’s 1-Button Deploy™ of HBase takes advantage of our SSD and Raw Disk Cloud Servers while making it easy to deploy a fully configured cluster. GoGrid deploys the latest Hortonworks’ distribution of HBase on Hadoop 2.0. If you’ve ever tried to deploy HBase or Hadoop yourself, you know it can be challenging. GoGrid’s 1-button Deploy™ does all the heavy lifting and applies all the recommended configurations to ensure a smooth path to deployment.

Why GoGrid Cloud Servers?

SSD Cloud Servers have several high-performance characteristics. They all come with attached SSD storage and large available RAM for the high I/O uses common to HBase. The Name Nodes benefit from the large RAM options available on SSD Cloud Servers and the Data Nodes use our Raw Disk Cloud Servers, which are configured as JBOD (Just a Bunch of Disks). This is the recommended disk configuration for Data Nodes, and GoGrid is one of the first providers to offer this configuration in a Cloud Server. Both SSD and Raw Disk Cloud Servers use a redundant 10-Gbps public and private network to ensure you have the maximum bandwidth to transfer your data. Plus, the cloud makes it easy to add more Data Nodes to your cluster as needed. You can use GoGrid’s 1-Button Deploy™ to provision either a 5-server development cluster or an 11-server production cluster with Firewall Service enabled.

Development Environments

The smallest recommended size for a development cluster is 5 servers. Although it’s possible to run HBase on a single server, you won’t be able to test failover or how data is replicated across nodes. You’ll most likely have a small database so you won’t need as much RAM, but will still benefit from SSD storage and a fast network. The Data Nodes use Raw Disk Cloud Servers and are configured with a replication factor of 3.

(more…) «HBase Made Simple»

When is “good enough” the right product decision?

Wednesday, April 23rd, 2014 by

“If you are not embarrassed by the first version of your product, you’ve launched too late.”
– Reid Hoffman, Founder, LinkedIn

Here’s the scenario: You started with a great idea, partnered with an excellent tech founder, and got $1M in funding so you could get the first release out the door. Part of your new-found funding went to hiring 3 Engineers. As the weeks of product development pass, you review the usability, demo it for prospects, and get feedback on how to make it better. The Engineers are working long hours to complete the first useful release for beta. When you review the usability with the Advisory Board or prospects, you get lots and lots of feedback about what works and what doesn’t, and you’re making changes—often daily.

One night you wake up and wonder, “Will we be tweaking this product forever? Will it ever get out the door so we can close some sales?” It’s time to have the conversation about what is “good enough” to ship. That means it’s time to revisit the original set of product requirements—the ones you and your team agreed needed to be implemented to ship the product. Go back to work with the team to completely scrub the bare minimum of what needs to be in the first version. Everyone will have opinions about what needs to be in the product when you ship. Justifications for including requirements may sound something like these:

“We won’t be able to reach one of our vertical market targets.”
“We’ll have a product that will only scale to 1M requests/timeframe and we need 10M.”
“Beta users hate the UI.”

During the scrub remember to ask, “What’s the cost of not implementing this functionality? Will we be able to add this functionality later without re-architecting the product?” Asking these questions lets you and the team make an informed business decision about minimal viable functionality. And at the end of your discussion, remember to reassure the team this sort of dialogue is healthy because it helps the company stay focused by prioritizing functionality into the releases on your road map—and ultimately drives your success.

A few years ago I had a great team that was working endless hours on a new workflow product. We started with requirements that were loosely defined and easily interpreted differently by each member of the team. Our usability expert seemed to re-interpret the same requirement each week, for example, but with the honest intent off making the product better. When it became clear we weren’t going to meet our functional complete date, I called the Engineers, PM, and QA together. As we scrubbed the requirements, we realized we were going to deliver 60% of what we originally thought was needed, but we still had very useful product. We finalized our definition by doing an in-scope/out-of-scope as a team for the rest of the company. And although it was a difficult conversation for the team to have, we delivered the first version—and got first mover advantage. So in the end, our 60%-ready first release actually turned out to be “good enough.”