Brad Abrams on Google, Spring Tools Integration

Recorded at:

1. Brad, can you tell us a little bit about the integration between Google’s suite and Spring’s suite?

We’re very excited about the alignment. We announced only just few months ago with Google I/O that Spring and Google were going to work together on this. We’re working on App Engine as a kind of cloud hosted environment and we just announced also at I/O Google App Engine for Business where we’re doing work with App Engine to make sure it’s great for business applications. In the process of that we looked around at how people are building modern business applications today. It turns out a lot of our customers said that they are using Spring and Spring is definitely a large and growing community.

When we talked with the Spring community and leaders in the Spring community we found a lot of synergy between the world view that I think Google has and what Spring has around openness, simplicity, portability. Those are all very important for both of us, so there is a lot of synergy there. We began to pursue it some more and we did work to make sure that Spring applications run really great on App Engine today. We did work to make sure that Spring Roo, which is a very high productivity tool for building Spring applications, can now emit GWT front ends.

GWT is a Google Web Toolkit and it allows developers to write in Java, very familiar Java syntax that many Spring developers are very familiar with. So they can write in Java and then it compiles to JavaScript, so it runs as Ajax applications and that extends the reach for Spring developers, so you can now write modern Ajax applications. If you are a Spring developer, you are now an Ajax developer and you can just add that to your resume with this work. That was the next piece.

Then, the last piece is we did some work with our Speed Tracer which is our plug-in for Google Chrome. Google is somewhat obsessed with performance of our applications, third party applications and so we wanted to really know where every microsecond is going in the application. We didn’t want any black boxes whatsoever. Speed Tracer completely instruments any application running in Chrome, every millisecond what’s happening. We are very happy to see that Spring Insight does the exact same thing for the server side of the application.

We just thought it was a match made in heaven, so we integrated the two pieces and now you can actually see every millisecond in one view, a timeline view of where time is spent in your application. So that’s a really powerful tool for developers. Sure, these things work very nicely together, you can use STS [SpringSource Tool Suite], which is where I think a lot of Spring developers go and live in, very productive. You can use STS and you can build GWT frontends so there are rich Ajax frontends as well as there is a button now where you can deploy those applications to App Engine and that works today so that’s definitely very useful to Spring developers, I think.

2. What were some of the challenges involved in getting the Google App Engine container to work well the Spring container?

We run App Engine applications in a sandbox on the server and the reason we do that is because we have this infinite scale idea that you don’t have to request a number of machines or a number of cores. That’s too low level for a lot of developers to think about. How do you ask them? - "How many cores will I need? - I don’t know." With App Engine we automatically scale the application up. Based on demand we transparently under the covers go and spin up new instances for you and it can go all the way from literally no request to a Google style infrastructure. There are close to a billion page views going on on App Engine, so there is a lot of scalability there.

But, in order to accomplish that, we needed to run these applications in a sandbox. While the vast majority of Java APIs are available, not all of them are there. One of the things we did as we brought Spring up on App Engine and made sure that was a very smooth experience, is just ensuring that every API common for Spring developers to use is available on what we call the "White List" for App Engine, meaning that it will work there. To our pleasant surprise, just about all of them were there, so it actually didn’t turn out to be a lot of work to get Spring up and running on that.

3. One of the things which has been restricted on Google App Engine is access to files since there is no local disk to speak of. How is that handled with respect to Spring APIs which access files and with Google itself?

We have within App Engine several mechanisms to store data and so there is a BLOB-based storage system there that a lot of developers find a very productive way and more interesting, a very scalable way to go store data. But we know that BLOB storage alone isn’t enough for many enterprise applications and that a structured data view is very interesting. One of the things that we announced a few months ago is Google SQL. We are actually demoing for the Google SQL publicly for the first time at this conference in sessions tomorrow.

We’re very excited about that because it gives what I consider the standard in enterprise applications, a kind of SQL-based view of data, we bring that to the cloud and to Google high availability, high scale systems. What we’ve literally done is taken the MySQL code base and we have ripped off the backend store and used Google’s high availability store on the back Big Table. So it’s kind of a very interesting engineering problem to go make sure all that works and transactions work correctly and what not. But we’re ready to demo it and it will ship in the near future, sometime next year.

We already have several trusted testers, several people experimenting with it and building applications on it. We think it will really complement the suite. Now you have App Engine for business, you have Spring for building your logic, GWT for the backend and now you have a place to store your data with Google SQL.

4. Can you describe the integration between Spring Roo and GWT in more detail?

What we did with Spring Roo is Roo does a great job of getting you started by generating a large part of the scaffolding of your application so you can focus on the business logic. What we did is plug-in to Spring Roo, so not only is the backend generated, the server side, but also a rich Ajax client in GWT is generated as well. So we thought that was a really nice synergy and it turns out to work very well. As we were doing it we were looking at what had to be generated and it really made us think hard about GWT in terms of the high level application patterns that are there up until our current release which is GWT 2.1 that we’re announcing here.

There has been a lot of different add-ons to GWT to add these kinds of concepts and what we realized is with this integration we need to bake in a pattern into the framework itself, in order to have the same level of productivity on the server and the client and give something for Roo to target. So we’re very happy to have formalized what we think is a very common practice, best practices for building Ajax applications with GWT. We have an Activities and Places API which is essentially an MVP [Model-View-Presenter] pattern that plugs very nicely in with Spring as well as history management support.

Once we did that, handling the back button in Ajax applications is very cumbersome because really you don’t want to go back to the last application you visited. What you want to do is go back to the previous logical state in this application. While that has always been possible with GWT, it hasn’t been baked into the framework and now we have baked it in there. The last piece, the kind of Spring and Roo inspired thing that we did, is really look at our data widgets and make sure that they deal with millions and millions of data records.

We do a windowed view of data, so you only bring down the data that you need to display and we do UI recycling so we don’t recreate all the UI elements. We just repopulate them with data. Those kinds of things make GWT and Spring a great environment for building business applications.

5. Can you describe the MVP pattern more detailed? I’m not familiar with that.

The MVP pattern is a model view presenter and, like a lot of the patterns, the idea is to separate the business logic of your UI away from the UI itself. There are a lot of reasons to do that. One of the primary ones is testability, because you want to be able to write unit tests for your business logic without doing UI automation, because that’s very cumbersome and hard to get right, so, by separating it out, you get that.

The other big benefit of it I think is that it provides some structure to your application and that helps you maintain the application and get new developers on the application. It’s more obvious where a piece of code should go or how things are wired up. You don’t have business logic scattered throughout the UI. It’s sort of centralized in a given place.

6. GWT will translate Java into JavaScript 4 for running as a web application. Most developers that I’ve worked with tend to be wary of that kind of translation from one language to another. How does GWT address some of these concerns?

It’s very understandable. One of the things that we think a lot about with GWT is we wanted to make it a very high performance environment. So we think of GWT as a compiler that compiles Java down to JavaScript. Rather than thinking about it as a language translation we think about JavaScript as simply a target environment, much like you have the Java C compiler that compiles Java code to bytecode, we compile down to JavaScript. If you look at the JavaScript in the optimized retail mode, it looks essentially like bytecode.

We do all the standard compiler tricks, dead code elimination, we remove code that is only applicable to IE, if you hit it with Chrome, then that IE code doesn’t download and vice versa. We do things like spriting; so if your application uses a lot of small images, we can package it together in a single image and bring those down and that saves network bandwidth. There are a lot of those aspects of it. We have definitely seen developers that have been skeptical of how really can you do as tight JavaScript code as I could go and hand write, and we found that many of those developers have become convinced that the compiler does it better and more consistently than many developers’ hand writing.

Many Google properties use GWT, for example AdWords, which is the app that advertisers use to buy ads on Google’s ad network, uses it and it’s a massive application. It’s very feature rich and the developers on the team as well as customers have been very happy with the experience that they’ve gotten out of using GWT for that.

7. I’ve heard JavaScript described as the runtime for the web elsewhere, as well. How does JavaScript allow you to tackle some of the issues which are inherent in trying to target the very wide variety of browsers on a variety of screen sizes that are connected to the internet going from cell phones up to desktop computers?

Definitely we see JavaScript as the runtime for the web. I think it’s a good analogy and there are a couple of different classes of developers that it’s useful to go think about. I think for the vast majority of enterprise developers who are skilled in Java and know how to do that, using a tool like GWT to compile down to JavaScript is a fantastic solution and it’s absolutely what you should go do. There are other developers that grow up writing web apps and they know JavaScript inside and out and for them I think there is benefit in the Java to JavaScript translation but then they have to go learn Java, they have to do the mental mapping there.

I think JavaScript is in the web, is in an interesting place, it is both a high level language in and of itself that people will continue to write applications as well as wiring components together. I don’t think that’s going to go away. I think that’s a valid legitimate use. But I think we will see, where there are more complex applications, some compiler will be employed to do things - the dead code elimination or as you mentioned the reality of the web today is you have to target a lot of devices and a lot of browsers. You want to do that and you have a relatively speaking narrow bandwidth to those devices. So you don’t want to send out a bunch of code that you’re not going to use.

Using some sort of compilation tool like GWT helps you send down only the code that you need to send down for targeting each one of those devices.

8. You also mentioned Speed Tracer’s integration with Spring Insight. Can you tell us a little more about that?

Yes, I’m very excited about that. Speed Tracer lets you see where every millisecond of the application is spent. And Spring Insight lets you see where every millisecond is within the server side of the app. Using STS you have all these tools bundled in the same development experience, so that STS is the one-stop shop for doing this kind of profile analysis across client and server, deploying to App Engine, using GWT to build the client of your application. So it’s really a great place to go get started to build out these applications.

9. These three integrations - the Spring Insight/Speed Tracer, the Spring Roo/GWT, and the Spring container/Google App Engine container seem to indicate a fairly large scale partnership between Google and SpringSource. Can you describe a little bit more about the ideas behind that and describe a little more about what it means for developers?

We felt we have a lot of synergy with the Spring community. We looked at extending App Engine out to building enterprise and building business applications. We looked at what people are doing building business applications today and Spring pops to the top very quickly as a large and growing community for that. From that point of view, it was sort of a no-brainer to go and do work together. As we started to talk we realized we had even more synergies - the notion of openness and cloud portability was very important to both of us, so you can write applications that run on your own hardware and in your own office and then to be able to move those seamlessly to the cloud when it’s time to go do that.

We certainly think App Engine is a fantastic place to go run those, so that’s a really great alignment. For developers, it’s so easy to go get started, because the answer is go get the latest version of STS. And from that you can go and build out Spring applications, Spring Roo applications back with GWT and then you can start, for free, testing those on App Engine, you just go and deploy those to App Engine. My advice to people is even if today you are not ready to move to the cloud, maybe do a little testing on App Engine to make sure that there are no architectural issues with moving it to App Engine eventually.

Then, when you are ready, if the scale of the application gets to a certain place or you want to do some server consolidation in your data center, then you know it’s very seamless to go move that to App Engine when it’s time.

10. Can any Java application be ported to Google App Engine or are there certain things that you have to do in advance and what are some of the differences between running my Java app on the box under desk or running the Java app on a server in the data center and running it on Google App Engine?

We certainly think App Engine is good for a very wide variety of applications. As we talked about, there is a sandbox that App Engine apps run in and that’s to allow this elastic scale where you can seamlessly run them across any number of devices. We have found that it usually takes some tweaks to the applications to be able to get them to work. There are some best practices for building high scalable applications that can do that very nicely. I think the biggest area is data access and how you store and retrieve data and there are some best practices too. Writes to the data store take a lot longer than reads when you run into the cloud.

And thinking about doing things like marking things for delete and then deleting them in a worker thread rather than deleting them right away is an example of a best practice thing. That works fine, works better for your on-premise, for your own server when you host it yourself. But then it works really fantastic once you put that up in the cloud. There are a handful of tweaks going out on that, we have several White Papers out that help you figure the details of that out.

11. How does Google App Engine compare to other Cloud offerings?

With Google App Engine we focused on a fairly high level of abstraction. If you’re familiar with all the terms, we think of Google App Engine as a platform-as-a-service, so you don’t think about VMs or cores or "How many machines do I need at any given time?" With App Engine you build your application and you get it running in your development experience, deploy it up to our cloud. Then we scale it literally from no request a second to millions of requests a second and you get a seamless experience with that.

I think it’s at a different level than other cloud vendors; it is a kind of a much lower level where you are effectively managing machines that you just don’t run in your data center. We think it’s a higher level of abstraction.

12. Google App Engine currently supports Python and Java as target languages. Are there plans to add other languages in the future?

Yes, that’s right. We support Python and Java and what’s great about supporting Java is what we really support is the Java VM there. Just about any of the languages that run on the Java VM, that admit bytecode, can run on App Engine as well. Pick almost any language you can think of and there has been a port to it to make sure it works on App Engine. We’re pretty happy with that set that we have right now, but we are open as new languages and new development paradigms come up we’ll obviously be looking at those for App Engine to make sure App Engine stays relevant.

13. Thank you very much.

Thank you.