Sean Lynch is a Product Manager at Google for App Engine. He’s also Canadian, but works in Mountain View. In January he’ll be in Montreal attending a Google Hackathon at RPM, hosted by Year One Labs. The official event page is here: http://www.yearonelabs.com/google-hackathon/. The Google Hackathon will be a 1-day event (January 22nd) for developers to come in and work on Google App Engine. With Sean’s attendance and assistance and Google’s support, it should be a fantastic event.
We reached out to Sean to ask him about his thoughts on App Engine, cloud computing, Platform as a Service (PaaS) and more. A quick thank you to Alistair Croll for facilitating the interview.
NextMontreal: In a couple of sentences, can you explain what App Engine is?
Sean: App Engine is a service that Google provides which allows developers to build web applications using a set of APIs and run those applications on Google’s infrastructure. The service and APIs provided by App Engine are built on top of the same highly distributed components that power services such as Gmail and Google Search. This means that while developing App Engine applications are simple thanks to the simple APIs, the application is immediately scalable because that highly-distributed infrastructure is baked right into your application.
NextMontreal: Why did Google launch a cloud computing platform?
Sean: Google recognized very early on that making the web better would benefit everyone so we have a long history of products and technologies created to that end. Google has also made a significant investment in the knowledge, technology, and infrastructure to run massive scalable applications that people depend on every day. The App Engine team recognized that by exposing this technology in a general way, we could harness it to enable rapid innovation on the web.
App Engine now serves as a fundamental component of Google’s cloud centric strategy. From Google Apps, to Android and Chrome, our focus on simplifying the entire life cycle of web application development has made App Engine a critical part of the success of many other Google efforts. As well, the rapid adoption of cloud technology means that App Engine and our other developer products such as Google Storage for Developers are particularly well suited as a significant growth opportunity for Google.
NextMontreal: How is Platform as a Service (PaaS), like App Engine, different from the more virtual-machine-centric cloud computing models that we see at places like Amazon, Rackspace, and Gogrid?
Sean: The primary difference is in the unit of deployment. With infrastructure services, the fundamental unit of deployment is a machine image. Even though they’re virtual, machines still require you to deal with the same cognitive overhead of many of the issues of traditional rack and server solutions: operating systems, memory allocation, library versions, load balancing, etc.
With PaaS solutions, the fundamental unit of deployment is the application itself. You don’t have to worry about the versions of the code, how they talk, or how many instances you’ll need. Removing the overhead allows developers using PaaS to focus on the functionality that differentiates their applications instead of keeping the lights on.
NextMontreal: Will enterprises adopt App Engine, or is it mainly a place to build startups?
Sean: App Engine’s core values are simple: development, management, and scalability. This message has certainly resonated strongly with start-ups as many of our early adopters and early success stories fall into this category.
While enterprises are never thought to be bleeding edge in the way start-ups are, we’ve certainly seen a lot of interest in App Engine from this space. It turns out that the same focus on development, management, and scaling matters to enterprises as well, though with one twist. Intuitively, everyone building web applications today likes the idea of easier development and administration, but enterprises don’t have to worry about going from zero to a million users over night, so why would scaling matter? The beauty of App Engine is that it transparently scales applications both up and down. That means the enterprise quarterly reporting app can cost next to nothing for 2.5 months every quarter, but can easily scale up to handle the load of every user in the company on the Friday night before a critical deadline. That’s a compelling story for CIOs.
NextMontreal: Many cloud providers “wrap” their cloud in services — from image manipulation, to customer records, to storage, to email. How important is the ecosystem that surrounds a cloud platform?
Sean: In some ways, the ecosystem determines which cloud service you are most likely to use. For example, if your application needs to modify your company’s Salesforce data, force.com is the obvious choice.
In the case of more standardized infrastructure such as storage, email, and communication APIs such as XMPP, these tend to be available or build-able on most cloud services. The decision then becomes one of priorities. You can choose to implement and maintain all the components of your application on your own, but choosing the right cloud service can make all the difference by letting you concentrate on the unique features of your app rather than spending time re-implementing the wheel.
NextMontreal: What’s the biggest change to the way developers need to think when they move to an on-demand, utility computing model?
Sean: I was on a panel with Jeff Hoffman from enStratus earlier this year and I believe he said it best, when he stated, “developers need to embrace the ephemeral.” In the traditional rack and server model, you have a named machine that you can go over, reboot, and pull the guts out of if you need to. The physicality of the machine is comforting but it’s also a constraint. Letting go of the box is liberating. Resources can come and go as you need them, you can experiment with new technology and services, and you can throw the experiment away with no commitment guilt if that’s the smartest decision.
Ephemeral resources also require a change in development process in that you can’t assume that any given server or endpoint is going to be around at any given time. Your application needs to build in some defensiveness, retrying when things fail or communicating with redundant backups. The reason that Queue systems like App Engine’s Task Queues and Amazon’s Simple Queuing Service are so useful in cloud development models is that they remove much of this complexity.
NextMontreal: How is cloud computing changing the playing field for new entrants into an industry?
Sean: Cloud computing simply takes the investment in computing resources out of the equation for new companies. Talking with start-ups today, this is no longer in the future, it’s the defacto standard. I can count on one hand the number of companies I’ve talked to in the last year that have their own machines, and most of those also evaluated cloud computing options before choosing to run their own.
The big issues for start-ups now are getting the people to build the product and getting the adoption from the market to make the product successful. When new entrants go after funding, they’re doing so for these two reasons, rarely ever is a company constrained because they can’t get the infrastructure to power it.
NextMontreal: Do you foresee a time when cloud platforms are the norm, and having to deal with individual machines — real or virtual — is the exception?
Sean: I see a time when using a cloud platform in combination with individual machines is the norm. This reality is not far off. The pattern is already used today with some App Engine developers and I see it with developers building on other platform services as well. The reason developers gravitate towards this pattern is that PaaS provides 80% of what they need for their application right out of the box. But as they build out their application, they find a task or use case that needs to be customized for their application or is sufficiently complex that they fall back to a machine-based service because its familiar. This pattern then gives developers the best of both worlds today: the scalability and simplicity of PaaS solutions while still being able to draw on open source projects and skills sets that revolve around a machine, virtual or otherwise.
In terms of abstractions, platforms are the logical end for cloud computing, doing away with the concept of a machine that is largely an illusion today anyway. I do foresee a future when platforms will be the norm for application development, but in order to replace the machine, the platform will need to provide an abstraction that is sufficiently complete so that it allows developers and the open source community to build reusable infrastructure on the platform the same way they do with machines and operating systems today. Developers are blessed with incredibly powerful projects such as MongoDB, Hadoop, and Node.js that take advantage of this common abstraction. When you or I can build or download and run these sorts of tools on any platform, we’ll have no more use for the machine.
