We tracked down some of the biggest brains at Google and posed them some tough questions about how their projects will evolve and change to accommodate the ever-shifting tides of development. In the first part of this two part series Linux User & Developer gets up close and personal with Fred Sauer, developer advocate, Google App Engine…
How is the collaboration between VMware and Google going?
I think it’s going really well. We have our initial release out the door. The teams are working closely together on co-ordinating the work. I work with App Engine and GWT, and it’s exciting to see the integrations come together. The leverage Java gives us… I think back five to ten years ago about what my Java development experience was like and I am so much happier now.
What about App Engine makes developing and deploying Java so much easier?
There’s a few factors. One of them is the principle we started with. We want to adhere to open standards wherever we can, whenever it makes sense. With App Engine and Python, there weren’t as many relevant standards, so we used Django, and we did the best that the environment allowed.
When we started working on App Engine for Java, we had a lot of standards we could take advantage of. There’s a long running history of building Java applications in the cloud, so we leveraged the skill sets of Java developers. In May we announced App Engine for business, and we started communicating the fact that we’re there for enterprise developers. In the enterprise space, Java is by far one of the most popular languages. Every person I know who does development in the enterprise writes code in Java.
Is Java in trouble now that Oracle is in control of the language?
It’s difficult for me to predict the future of the language. As a developer and as builders of development tools and platforms we’re very practical, and today Java provides enormous leverage and benefits. It’s simply the best tool we have today given the strengths that exist.
If developers today did not already know a language, and we could come up with the perfect language, we would come up with, perhaps, a very different set of languages and tools. But that is not a realistic constraint. Developers know Java and Python. With tools like Eclipse, developers know that there is an ecosystem around that. When you take all the great things about Java, like static typing, that provides tremendous leverage in the tooling side to prevent bugs to catch bugs. Java is a wonderful environment, because of the tooling.
Java right now is the right answer. As long as it is the right answer, we will continue to build tools for it. When the practical world changes around us, whatever the flavour of the decade becomes, that’s where we will be working. At Google, we care about the end-user. That’s embedded in our mission statement with GWT, where we’re trying to build no-compromise applications. The user comes first, but the developer is always second.
The App Engine deployment model is very different from other cloud models. Why is that?
It is a very different model. It was a very conscious choice on our part to make it that model. We looked at how external developers deploy, and it’s much too difficult to deploy applications to the cloud. When you look across many different projects and you look at creating a database server, configuring log files, having rolling restarts and pushing out binary code, these are all things most projects could do with the same kind of code and instructions. But these pieces get reinvented with every project.
What’s valuable for developers is building the application logic. With App Engine, we had a very clear goal of making it extremely easy to deploy applications. We asked ‘what’s the absolute minimum a developer should have to do to get an application up and running?’ If you go to an App Engine administration console, what you won’t find is probably more interesting than what you do find. You won’t find any knobs or dials for the number of servers you want to run. The more data you put into App Engine, the more distributed that data becomes. The more requests that come in, the more servers we have running. When those requests die off, we re-provision those servers for other users.
It’s a one-button deployment. Our plug-in uploads the code. If you come back six months later, your application is still serving. If on some Tuesday morning you get very popular, we’ll simply spin up more servers. We think that’s the way it should work.