Too much travel makes your brain into pudding. It’s like being hung over, except you didn’t have that nice experience of being drunk. As I work towards a more serious write-up of SpringOne, here are some quick notes a la Voltaire.
Earlier this week, I was at VMWare’s SpringOne conference, covering announcements and new work from their SpringSource division. They launched an integrating cloud-based software development suite of tools, several technology partnerships with Google, and started to outline new integration needs from the social, mobile, and database world.
(For an excellent, detailed summary, see Darryl Taft’s write-up of day one and then day two.)
Code2Cloud
The release of Code2Cloud is the most interesting announcement. Working with TaskTop – mostly TaskTop it seems – VMWare (or “SpringSource,” as I’ll call them) has put together a good looking approach to doing cloud-based ALM. They of course want to move away from the idea of “ALM” (good council, and one of those Three Letter o’ Death that our own James Governor has told people in the past to avoid) but you’ll pardon me using a known quantity as a crutch to talk about “all that stuff other than the IDE and complier that you use to get software out the door and manage the project.”
Since leaving the programming world, I’ve been envious of teams who could use hosted services like Rally and VersionOne, along with the host of other, well, hosted tools. Those tools tend to manage the artifacts of an Agile process: tracking the “stories” and features that should be built, what phase of the development cycles they fit in (the “iteration”), who’s working on the item, and how far along it is up to completion.
In addition to that issue tracker, there’s version control and your build system. Both of those have been ripe for moving into the cloud, and the ability git provides to do synchronized web style use in git (meaning: you can pile up changes and even use the tool offline) takes care of the unreliable cloud problem most people would probably carp on.
(“Send moar minis” from Christopher Blizzard)
Cloud-based builds are an area that many people, and stealthy startups, have been interested in over the past few months. It makes sense: builds are processor intensive and, as such, a perfect match for the “bursty,” elastic functionality a cloud would provide. Also, as one of Sun’s hosted projects was shooting for, cloud-based builds open up all sorts of platform testing and compiling options: maybe it’s easier to compile to some weird HP-UX version if you just rent that node as part of your build cloud.
The tough nut here will be convincing developers that this system is as open as TaskTop and SpringSource would tell you it is. While SpringSource obviously wants you to use their stack top to bottom, Code2Cloud properties to be an open and interoperable pile of components. Thus, even if you weren’t using Spring, you could use it. One Spring use I talked with said he liked the setup, but didn’t use Spring’s Tools so he wouldn’t be able to use it. And, besides, he said, he already had all that ALM stuff setup. That’s the kind of quick perception to get over by showing, not marketing, as it were. We’ll see once it comes out, sometime next year they say.
I have a short, video interview with TaskTop on Code2Cloud that should be up soon. Also check out Israel Gat’s take: as someone who’s interested in optimizing the development process from the perspective of management, he’s esp. interested in the ALM-we-shall-not-call-ALM innovation here.
Google Partnership
Also of interest were the three integrations that Google and SpringSource announced.
Sorting out Google’s angle on the developer-front can be a freaky walk down memory lane. At the end of the day, the reason they do most things is “to make the web a better place.” The more people that use and enjoy the web, the more Google ads they see, the more clicks there will be, and the more money is made, and layering in the collection of data that allows Google to better do that targeting and connivence advertisers that they’ve finally solved Wanamaker 50% waste rule of advertising, and you’re set.
When the stranger lady dumps billions of dollars on your desk each quarter, you don’t worry too much about direct revenue producing products on a quarterly basis. Hence the feeling all too often that Google isn’t operating under the same strategic pressures as other companies.
That’s all to say, when you look at partnerships Google does, you can’t always look at it through the same lense you would other companies. You almost have to take on that cutely, starry eyed attitude most Googleers have: we just thought it was a good idea and Larry and Sergey agreed!
To the Google/SpringSource announcement, then. The first two items – integrating Roo and GWT can be taken at face value as just a “good idea.” GWT has been successful, and it’s certainly one of the UI toolkits I about (Java) hear people using frequently.
Integrating together Spring Insight and Google Speed Tracer is half “just a good idea,” but also ties up with Google’s enterprise cloud strategy, AppEngine. As Oracle’s William Vambenepe recently showed, the management piece of a PaaS is an extremely complex and demanding set of functionality: you can’t just expect people to sort out diagnosing cloud-based applications on their own, they’ll need tools that are designed to work with that platform. They need a Wily for the cloud, which is what this tie-up is going for: doing end-to-end tracing of a request from glass to metal, from front-end (if it’s Chrome) to database.
The demos are compelling, but, of course, limited to the Spring stack.
The third announcement ties much of this together and gives you some tea leaves. Hidden in the messaging around the “SpringSource Tool Suite and Google Plugin for Eclipse” is the fact that the Spring Framework is essentially being “certified” (thought they don’t call it that) to run on Google AppEngine. AppEngine has long been a weird-beast of Java: it has a whitelist of classes that will work and support, which is a fancy way of saying it’s not 100% Java compatible. Having Spring, more or less, “certified” to run on AppEngine means developers can worry a little less about that weirdness…if they develop on Spring.
At that point, tying in the ETE monitoring that Spring Insight and Speed Tracer brings you makes sense – it’s part of that stack.
For VMWare, this is another cloud partner that Spring is paving the path for. SalesForce, of course, is the other prominent one. It’s interesting to watch the “use Spring as PaaS interop” as part of VMWare’s cloud strategy, and I’d expect to see more such moves as they try to get their tendrils into as many “clouds” as possible. In a post open source world (pardon the phrase), it’s worth thinking on the question: if your code runs on most of the (proprietary clouds), does that mean it’s interoperable, or lock-in madness? The answer is a little less clear than you’d think if you grew up in the era of rainbows and sandals (like this guy did, dear readers).
It’ll certainly roil up the usual Java suspects, esp. those who have their own cloud agenda to push (mostly RedHat and IBM, and Oracle if you slap in their “cloud is everything, so, yes, we’re doing cloud” world-view).
The New SDKs: Social, Mobile, Big Data
Next up, SpringSource started tossing out some vision in a rare escape from the highly technical (and welcome) content they usually put out at SpringOne. Rod Johnson and others pointed out that “social” and “mobile” are two huge areas of interest looming in the future (and in the here and now if you’re lucky to work on it). They’ve been hammering away at projects in both spaces, represented by their running reference application, Greenhouse.
Here, the pivot you need to make is thinking about all those social networking sites and services (from Facebook to LinkedIn to Twitter) as “the new APIs” that the Spring Framework will wrap. That’s been Spring’s thing since the beginning: finding the APIs (and, implicitly, the actual running code underneath the interfaces) that are popular and powerful, but terrible to actually use – J2EE, for example. Then take wrap those APIs in the Spring to make them easier to use. From that, the rest of the Spring empire was built.
Now, there’s less action in the framework and API world than their used to be. There’s still plenty for sure – but the real interesting action are in the APIs that social services host: the Twitter API, Facebook connect. These aren’t things that will show up as an open source project somewhere, they just exist as the one API in the cloud.
For SpringSource, then, the shift is to treat those hosted APIs the same as they did J2EE, and try to figure out how to integrate them into (corporate, mostly) Java developers’ work.
Mobile is another form factor, another UI. The thick-client model mobile encourages seems to be having some interesting effects on the old MVC monopoly, and once you throw in JavaScript as first class citizen (something SpringSource hasn’t done yet), things do start to look different.
And, then there’s NoSQL, which means to SpringSource, as Rod Johnson said, “We mean ‘Not Only SQL.'” Their GemFire buy gets them into some credible discussion here, as does the work with neo4j. RedMonk has been field many inquiries about using NoSQL, so I can’t help but agree with the sentiment I heard several times from SpringSource folks that now is the time to start sorting out when to use Not Only SQL.
Disclosure: VMWare is a client, and paid air and hotel for this trip. TaskTop is a client as well. IBM, RedHat, and Neo Technology are clients as well. As always, see the RedMonk client list for others in this space.
http://www.truereligions.in/