Web Services & Cloud Computing
Commercialization
In operating our own Cloudvox and Clover businesses, Seven Scale encounters Web services/SaaS product marketing, highly-parallel data stores, API adoption, and cloud automation on a daily basis.
Moreover, with our own capital at risk as entrepreneurs and investors, we intimately understand that Rome wasn't built in a day: practicality rules, and these technologies exist to solve specific problems.
Let's sit down in front of a whiteboard or notepad -- meet us at Zoka Coffee, Top Pot, Zeitgeist or the like, or on the phone or Google Talk/Jabber. Start by saying hello or following @sevenscale.
Common Topics
Scalable Data Stores ("NoSQL") ››
Pricing, Signup Conversion, & Cost Optimization ››
Evolving Traditional Software to SaaS App ››
Scalable Data Stores ("NoSQL")
We've stored tens or hundreds of millions of documents/keys using many highly-parallel data stores. Our own needs led us to write Ruby bindings for the Tokyo Dystopia fulltext indexing system. These changes were open-sourced as part of the standard rufus-tokyo Tokyo Cabinet library.
Decision Factors
Choosing the right data store implementation starts with a concrete understanding of the problem. Often these facts will narrow down the practical choices to just a few. We work with you to consider:
Query requirements: ID, integer ranges, timestamps, user-specified/domain-specific, fulltext
Query and client parallelism: 2 intensive queries from 2 clients vs. 500,000 queries from 200 clients
Data set size: # of docs, number scanned to complete query, storage
Persistence: disk, memory, hybrid (and tolerance for data loss)
Inherent feature set suitability (such as Redis' LPUSH/SADD)
Read/write mix
Average document size: 100 bytes, 1 KB, or 1 MB
Sharding (and reducing # of documents scanned to complete a query)
Product, support, & docs maturity
Query burstiness (and need to run on elastic infrastructure)
Insertion & indexing delay
Client language bindings
Client-facing cachability, such as with Varnish or memcached
Technologies
RDBMS scaling: MySQL multi-master, caching, disk subsystems
Key/value & document stores: Tokyo Cabinet (mixi), CouchDB, Redis, MongoDB
Highly-parallel retrieval: sharding, Cassandra (Facebook), HDFS and/or HBase, Project Voldemort (LinkedIn)
Fulltext indexing: Lucene/Solr, Tokyo Cabinet (Dystopia), Sphinx
Cloud Migration
Migrating from a single datacenter or pre-launch environment to elastic "cloud" infrastructure often entails additional automation and planning, like:
What app components are best suited for slices, dedicated servers, or in-house facilities?
When should new capacity be added, and how?
Can a scale-up "mega server" buy time by deferring hard software problems?
What capacity spinup delay is permissible, and how can it get there?
Can background tasks run on existing capacity to save costs?
Pricing, Signup Conversion,
& Cost Optimization
A 5% or 10% increase in conversion (or decrease in customer price sensitivity) can be the difference between a lucrative service and a science project. Pricing is a tortured art, even more so for services priced by value created and market comparables rather than COGS. Experience helps here:
Does freemium really make sense? How much does that qualified lead cost?
Where are natural purchase or upgrade "inflection points" in the service?
What few variables actually make sense for A/B testing (and where is common sense good enough or data impractical to collect)?
Who isn't subscribing today, and why?
API Creation
Exposing an API means putting yourself in the eyes of a developer or integrator, not a user. Minimize surprises and back-load complexity. Seven Scale has solved problems like:
Data normalization: What data makes sense where?
App workflow: What Web/Ajax-centric workflows are not natural for API clients?
Plumbing: HTTP verbs, status codes, & serialization, non-HTTP protocols
Adoption: Multi-language docs & sample code
Operations: Where and how is payment, tracking, logging, and rate-limiting needed?
Evolving Traditional Software
to SaaS App
Converting an existing software product to a hosted monthly subscription service can serve a new market and grow your business. It's a different world, though: entirely-fixed costs of traditional software businesses are replaced with variable ones faced as the business grows, and multi-tenancy introduces customer segmentation and capacity planning problems. Seven Scale has faced down:
How can SaaS add to, rather than cannibalizing, existing product sales?
What single-customer operations may swamp a multi-tenant system?
Calculating & decreasing variable costs
Where can sharding happen?