Creating an interactive website used to be difficult and expensive. In the 1990s, if you wanted a website that was more than static text and graphics, you typically had buy and maintain your own servers. This was a huge pain. If a server broke, you’d be forced to drop everything and fix or replace it. You had to worry about backups, power supplies, and all manner of other tedious hardware details.
Around the turn of the century, companies began offering increasingly sophisticated managed hosting options. Rather than having to buy and maintain hardware yourself, you’d be given a standard-issue server. If it broke down, you could order another, identical, one to be put in its place. In 2006, Amazon unveiled EC2, which provides virtual servers. You might be sharing a physical server with others, but from your point of view it looks like a dedicated server.
This was an improvement, but there were still significant downsides. While the hardware was no longer your problem, setting up the software on a web server still involves a number of tedious steps that have little to do with the functionality of your website. And while the ability to instantly order additional servers to deal with sudden increases in traffic was valuable, building websites that “scaled” well was still a serious technical challenge. If you did it wrong, one program or server could still become become a bottleneck and bring the whole site grinding to a halt.
To deal with these problems, companies began offering “platform as a service” products. Google App Engine, introduced in 2008, is a popular example. Google App Engine handles all the low-level details of installing web servers, databases, and the like. Developers get to focus on writing the code that makes their specific website work. And Google App Engine automatically allocates more servers to your website as it gets more traffic, freeing you from having to manually order more servers to deal with demand spikes.
This was another big improvement. But even the “platform as a service” model leaves a lot to be desired, especially for interactive web applications. Getting interactive applications (like, say, Google Docs) to work well is difficult, especially when multiple users are accessing the same data. If you do it “by hand,” you have to deal with subtle differences among browsers, network congestion, dropped connections, and so forth. And while the “platform as a service” makes it easier to avoid scaling problems, it’s not completely foolproof; if you don’t design the application carefully, you might still get a fail whale on launch day.
Firebase (formerly Envolve), came up with a clever solution: free the programmer from worrying about the server at all! As co-founder James Tamplin puts it, Firebase is like Dropbox for your app’s data. Firebase maintains a data structure that’s shared among all the clients. When clients want to communicate with each other, they simply change their local copy of the data structure, and Firebase automatically ensures that the change propagates to other clients.
Once again, this greatly simplifies web programming. Since there’s no application code on the server, scaling is entirely Firebase’s problem. And because Firebase handles synchronization, programmers don’t need to worry about subtle differences between browsers, or tricky cases like when a user suddenly loses her network connection. As a result, programmers can create sophisticated applications like this multi-player asteroids clone in a matter of hours.
This isn’t a blog about programming, so I’ll spare you the gory technical details, though they’re pretty cool and you can read all about them here. But I wanted to briefly comment on the broader economic consequences of this kind of innovation. Each new model I’ve described “abstracts away” tedious details that the previous model had forced programmers to deal with explicitly. In each case, that meant that developers could forget about a whole class of problems—first hardware administration, then software administration, then the whole server—that were now handled by the service provider.
This, in turn, has been essential to Silicon Valley’s startup ethos because it radically increases programmers’ productivity. Today, a couple of 23-year-old entrepreneurs with a a few thousand dollars in the bank can reach “ramen profitability” in the course of a summer. That wouldn’t be possible without increasingly sophisticated technology platforms, that handles a larger and larger share of the tedious details of running a website. If Firebase takes off—and its launch yesterday generated a lot of interest—it promises to further enhance the productivity of thousands of web programmers. The result will be even smaller teams building even more sophisticated websites.