Software Development's Macro-Trend Towards Micro-Services
Last week, we crammed 60 people into our offices at Sequoia to discuss a trend that most people have never heard of: microservices. Even those familiar with the term (usually developers) debate its significance, pointing out that the idea is not new (remember “service oriented architectures”?). But to us, it’s one of a handful of major trends re-shaping software development, on par with the public cloud or open source in its likely impact.
The idea behind microservices is that, rather than building large monolithic applications, development teams instead build apps as collections of loosely coupled services which operate autonomously. That’s harder than it sounds -- it requires a completely different approach to software development. Alex Roetter, who runs engineering at Twitter where he oversaw this transition, described it as like moving from a centrally planned economy to capitalism: in other words, it’s possible but difficult and messy, and if you get it wrong, the result is anarchy. He shared the set of rules that have worked for Twitter, as they broke up their single, unreliable application (known internally as the “Mono-Rail” because it was written in Ruby) into a collection of microservices.
As Martin Fowler pointed out, none of this is free: there’s a “micro services premium” that every team must pay from the additional complexity of building applications in this way. Moving to a microservices architecture not only creates new problems that did not previously exist, it also breaks things that worked before. Staying with Twitter as an example, it was a lot easier to test the Mono-Rail than the disparate set of services which succeeded it.
So why bother? Because, as Ben Golub from Docker explained, it can make development teams massively more productive: according to his numbers, with a microservices-based approach, teams can update apps 30 times more frequently and recover from failures 50% faster. New applications become easier to change (just add a new services and leverage everything that was built before), and existing apps become easier to maintain (re-write components without any risk to the whole). Essentially, by moving to microservices, you get better software more quickly, which becomes a competitive advantage. That was the case for Google and Amazon in the 2000s, as Bill Coughran and Tom Killalea helpfully explained. And it’s increasingly true today for some of the best new companies, such as Airbnb, Dropbox and Xoom, who also shared their experiences.
The attendees at yesterday's event were mainly from companies at different stages of deploying micro services, along with a handful of forward-thinking entrepreneurs. It's early days, and some areas are much more advanced than others. For example, monitoring microservices is a universal concern; in our breakout sessions, at least 3 companies had already built internal solutions and there was a detailed discussion of design tradeoffs. By contrast, few people are yet thinking about security, where the threat model remains unclear.
For those interested in learning more , Matt Miller, who's a thought-leader at Sequoia in this area, has shared key learnings from the sessions here. We have also published an updated version of our ecosystem chart (thanks to all for the great feedback), and -- for fun -- put together this graphic of tweets from the event.
