KML_FLASHEMBED_PROCESS_SCRIPT_CALLS

Archive for the ‘GoGrid’ Category

 

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

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»

Security Alert: OpenSSL Bug Needs Prompt Attention

Tuesday, April 8th, 2014 by

A major vulnerability with the OpenSSL libraries was announced this morning. According to PCWorld, “The flaw, nicknamed ‘Heartbleed’ is contained in several versions of OpenSSL, a cryptographic library that enables SSL (Secure Sockets Layer) or TLS (Transport Security Layer) encryption. Most websites use either SSL or TLS, which is indicated in browsers with a padlock symbol. The flaw, which was introduced in December 2011, has been fixed in OpenSSL 1.0.1g, which was released on Monday [April 7].”

Heartbleed

We want to ensure all our customers are aware of this vulnerability so those impacted can take appropriate measures. The following description of Heartbleed is from http://heartbleed.com:

“The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”

GoGrid has already performed an extensive audit of our environment and has determined that none of our customer-supporting sites—including our management console, wiki, and secure signup—is exposed to this vulnerability.

If you are permitting SSL/TLS traffic to your servers, however, a firewall won’t block against this attack. This is a serious vulnerability with the ability to significantly expose your environment. GoGrid recommends you review the National Vulnerability Database CVE-2014-0160 as soon as possible to determine if the OpenSSL vulnerability applies to your organization and then take corrective action based on your specific security policies, if necessary.