Clustrix just exhibited at two good shows: Structure and Velocity. I spent my time at Structure. One of the highlights of the show for Clustrix was the The Future of SQL In the Cloud panel that Paul was on. There was some good discussion about SQL vs. NoSQL and different products available for scaling your database. The title is a bit of a misnomer, however. Database challenges are orthogonal to the cloud. The database is a critical challenge no matter how the application is deployed.
But this isn’t what surprised me the most at Structure. That came in the How Does a Company Scale in Real Time? panel. This panel had representatives from PayPal, Engine Yard, Yahoo!, Facebook, and Zynga. These panelists are all responsible for ensuring their products continue to function smoothly. These companies are all recognizable and successful. I was really hoping to hear some good insight into operating large scale web properties and perhaps some good advice for new web startups. I think the money question came at around 16:30 in the video. Jonathan asks the panelists to rewind the clock and say what they would do differently and to give advice to startups for what they should focus on to avoid application bottlenecks. There was a lot of advice offered. There was talk of establishing a single-signon infrastructure. There was emphasis on avoiding SQL entirely, saying it is far and away the biggest scalability problem in web architectures today. There was a suggestion you should invest up front in separating out your architecture. You should think hard about the abstraction layers in key parts of your system and get the infrastructure right first. Another talks about getting the right instrumentation and metrics in your application. You should put in the right levels of abstraction, and the right levels of caching. You need to force yourself to run your application on two servers. Think about sharding and replicating at the beginning and force your scaling challenges to come up in advance before you have to scale.
None of this advice resonated with me. Startups have enough challenges finding the right business model and securing the initial set of customers. Why would you spend your very limited money, and more importantly, time on infrastructure and architecture of the back-end before you’ve proved your business? Matthew Mengerink, VP of Customer Quality, Engineering Services, and Site Operations at PayPal finally stepped in and made some sense. He says he would do nothing different. To him, a startup working on architecture is a waste of a dollar. He advises spending your time and money on making the business model work. Thank you, Matthew!
This discussion reminded me of a post titled Start In the Middle I read a while ago. In there, it offers a bit of advice that should be obvious that is so often not: solve the interesting bit of the problem first. Prove there’s value in the core idea, and then flesh out the infrastructure around it. Do what makes your business unique first and put the majority of time into that. Delay building the rest of the surrounding architecture until its really needed or when possible, just buy those bits. The rest of that BS is not what your customers see and not what makes you money.
So what’s my advice? Make the code and architecture as simple as you possibly can but no simpler. Don’t abstract too early and don’t make premature optimizations. Rewriting code and adding abstractions later is not a sign of coding failure, rather it’s a sign the product is successful. Choose the data model that fits your problem. That is frequently SQL. Full transactional and relational SQL is exceptionally expressive and it fits many problems so well. Why wouldn’t you use it? Don’t re-invent things that are not part of your core business. When the product becomes successful and the load starts to ramp, collect hard data to find the bottlenecks and fix them when they become a problem. When your data shows that your database is that bottleneck, perhaps Clustrix can help.
2 Comments
Great points Aaron. I’m right there with you about being disheartened at the NoSQL movement. It seems like the retaliation is really about weak and unscalable implementations or behemoth vendors rather than about the fundamental properties of SQL. Like getting pissed off about your car breaking down and declaring war on four-wheeled vehicles.
It is interesting, though, that most of the great properties of the relational model, like transactionality, expressive support for aggregates, single point of query, and consistency are undermined as soon as you have to split your data across separate monolithic databases. I can easily imagine that for a lot of those panelists, by the time they’d started with a MySQL database and then dealt with all the headaches accompanying trying to provide for all those great relational properties after leaving the single-instance nest, they’d feel some ill-will toward the fundamental relational properties that they presumably see as impractical in web-scale applications.
If you were to enumerate the properties (virtues or flaws) of an RDBMS, like natural language, ACID properties, aggregates, efficient, consistent query, single point of query, built-in replication etc. et. al., can you tell us where you think that traditional RDBMSs failed these panelists, and how Clustrix approaches things differently? Were there any SQL products that could have made the experience less painful? Do you think that there was a better experience available to them using some existing technology?
You also mention “SQL” a lot in your posts. Am I to take it that you’re referring to all relational databases? Or just ones that use SQL the language?
Aaron,
While a lot of startups do follow your thinking on coding the core idea/next minimum piece of functionality, and then rewrite frequently as needed, one could equally stress the need for not forgetting core software engineering practices of documentation, diagnostics, and the need for a long term architectural roadmap.
Indeed, the more small companies that work out the long term product risk, engineering cost, and complexity of scaling out a reliable online service, the more your solution will make sense.
I think you are one of the few startups out there building complex core technology, and wish you all the best. I for one will be checking out your Careers page for server developers in first quarter 2011!