KML_FLASHEMBED_PROCESS_SCRIPT_CALLS

Archive for the ‘GoGrid’ Category

 

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.

Infographic: 2014 – The Year of Open Source?

Tuesday, April 8th, 2014 by

If you’re a software developer, you’ve probably already used open-source code in some of your projects. Until recently, however, people who aren’t software developers probably thought “open source” referred to a new type of bottled water. But all that’s beginning to change. Now you can find open-source versions of everything from Shakespeare to geospatial tools. In fact, the first laptop built almost entirely on open source hardware just hit the market. In the article announcing the new device, Wired noted that, “Open source hardware is beginning to find its own place in the world, not only among hobbyists but inside big companies such as Facebook.”

GoGrid_OpenSource200_blog

Why now?

Open source technology has moved from experiment to mainstream partly because the concept itself has matured. Companies that used to zealously guard their proprietary software or hardware may now be building some or all of it on open-source code and even giving back to the relevant communities. Plus repositories like GitHub, Bitbucket, and SourceForge make access to open-source code easy.

In its annual “Future of Open Source Survey,” North Bridge Venture Partners summarized 3 reasons support for open source is broadening:

1. Quality: Thanks to strong community support, the quality of open-source offerings has improved dramatically. They now compete with proprietary or commercial equivalents on features–and can usually be deployed more quickly. Goodbye vendor “lock-in.”

(more…) «Infographic: 2014 – The Year of Open Source?»

Deploying Cassandra with the Push of a Button on GoGrid

Thursday, April 3rd, 2014 by

Let’s say you’ve already done your due diligence and decided you want to run a NoSQL database. The only problem is that you’ve now got to figure out how to deploy the cluster in an environment that lets you scale within a single data center and also across multiple data centers. To save money, this is when many people trial Cassandra on cheap hardware with limited RAM across clusters that are simply inadequate for the job.

That’s a mistake, but luckily, there’s a better way. At GoGrid, we’ve made it possible to deploy a production-ready 5-node Cassandra cluster on robust, high-performance machines with the click of a button. Check out the specs of the orchestrated deployment we’re providing using our 1-Button Deploy™ technology:

  • SSD nodes: 16 GB RAM, 16 cores, and 640 GB storage per node
  • 10-Gbps redundant, high-performance network
  • 40-Gbps private network connectivity to additional Block Storage volumes (as needed)

image

Once you’ve deployed the first cluster, you can add more nodes as you need them via simple point-and-click. Consider for a moment what you can do with this technology: You can run a user/session store for your application, run a distributed priority job queue, use it to manage sensor data, or any number of other things with just a few clicks of the mouse. And you can do it all in 3 easy steps:

Step 1: 1-Button Deploy™

(more…) «Deploying Cassandra with the Push of a Button on GoGrid»