Within hours, three foundational aspects of my life were rocked to the core: The project I worked on, the company I worked for, and one of the two people directly responsible for my very existence (however, I did receive a decent tax refund, so the news that week wasn't all bad.)
Now that I'm solidly on the other side of an extraordinarily disruptive year, I can afford to reflect and offer some perspective.
The burning question is, of course, What became of Falcon? The short answer is that the project was shelved and the team disbanded. But let me offer a somewhat more considered answer to that question.
Falcon's very existence was predicated upon the fact that MySQL needed a transactional storage engine alternative to InnoDB. To give you a sense of the importance of the project and a sense of the urgency back then, on my first day on the job with MySQL, Marten Mikos sat down with the Falcon team and said, "If you deliver Falcon, I will take MySQL public." That's pretty motivating, and the Falcon team was, if anything, motivated.
Yet, two years later, the Oracle acquisition instantly rendered Falcon strategically unnecessary. Would there be a role for Falcon? It seemed doubtful, but no one in MySQL was certain, and if they were, they weren't talking.
In response to the Oracle announcement, and quite apart from the pithy "Whither MySQL?" post, I assembled an internal wiki page describing my vision of a post-acquisition Falcon. Entitled Falcon Reimagined: The Falcon Performance Engine, it suggested that by reducing the engine to its purest elements--highly concurrent transactions and in-memory speed--and by optimizing the engine for screaming fast Sun hardware, we could turn Falcon into a performance beast.
Of course, the vision depended upon the vision of our new owners, but I figured given that
1) Falcon would no longer be positioned as a competitor of InnoDB, and
2) Falcon has neither a legacy tail nor an installed base to contend with,
then we might have an opportunity to inhabit a new niche with the Falcon equivalent of a concept car. (I'll post Falcon Reimagined once I determine that it's within the corporate social media guidelines.)
Weeks prior to the Oracle announcement, Sun management challenged the Falcon team to finally stabilize the engine once and for all. We'd been chasing performance and memory targets for months, and although progress on those fronts was excellent, the bug trend was discouraging and the project seemed stalled. Management was restless, irritable and demanding changes.
Kevin, Ann and I scrambled to devise a detailed and realistic plan with which we would finally drive Falcon home, but by then it was too late: Sun announced the acquisition and the Falcon team began to dissipate. By the end of the summer, each member of the Falcon team had either been reassigned or had chosen to leave Sun altogether.
In mid-October, after being granted a three-week stay, Kevin, Ann and I wrapped up the last remaining issues and put Falcon to sleep.
And In The End...
I could write a book reflecting on Falcon and the experience of trying to deliver a high-visibility project in the face of constant deadline pressure. Who knows? Perhaps some day I will. For now, I'll keep it simple:
What we did wrong:
Chase InnoDB at the expense of stability. For example, our performance goals should have remained fixed until the engine was stable. Instead, we reprioritized performance whenever InnoDB improved theirs. Yes, extremely poor performance is a critical flaw, but 70% of InnoDB should've been good enough until GA.
What we did right:
Assemble a top-notch team. By the March '09 Falcon team meeting in Athens, the Falcon team was comprised of a solid mix of senior engineers with a variety of technical skills. We had really come together in terms of collaboration, enthusiasm and technical innovation. We returned from Athens recharged and ready to kick ass. In some respects, the Athens meeting was like our Abbey Road album--the best and the last.
Falcon was fun. Falcon was interesting. Falcon was intense. Falcon was also frustrating and, at times, Falcon was insane. But that's why we do this, isn't it?
What's next? For now, I am part of the MySQL Search Team, a self-directed, cross-team SIG within MySQL. Our mission:
- Improve the ease of implementing native or third-party fulltext search with MySQL.
- Improve the quality of fulltext search results.
- Improve the performance of fulltext search response.
Now that the acquisition dust has settled, the MySQL Search Team will continue to gain momentum, and I will use The Falcon Blog to reflect upon our progress.