"Applistructure"? Give me a break
Lately I just keep falling over this word. (See
here,
here, and
here, and
here).
Perhaps I'm having a bad day, but this is really starting to get on my nerves.
Applistructure?
Applistructure?Customer:
I'd like some applistructure, please!Vendor:
Certainly, sir. How much would you like?My 2p: forget applistructure. In fact, forget
applications too.
It's
all infrastructure.
One person's application is another man's infrastructure. Web servers are applications to an operating system. SMTP is an application layer protocol to a network engineer. And "applications"? They're business infrastructure. (Think about that last one).
It's all infrastructure to someone.
"Loosely Coupled" reinvents Passport
The
Loosely Coupled blog authored by Phil Wainewright published an entry on
Identity as a service yesterday.
What Phil says here makes a lot of sense:
One of the things that's becoming evident as organizations deploy service-oriented architectures is that identity management (access control, user authorizations) has to be implemented as a service. Anything else rapidly becomes too unwieldy to maintain and manage as the number of discrete application services increases.
What's true within a single enterprise infrastructure surely holds true even more in the WorldWide Web. But at the moment, each separate service provider (Google, Amazon.com, eBay, Yahoo!, etc) either has their own identity management stack — if not several — or else it has none at all (eg, every site that publishes an RSS feed).
It's true, there is a need for an open, interoperable, vendor-independent infrastructure for delivering identity which puts the user in control. This is the objective of Kim Cameron's
7 laws of identity and the
identity metasystem - basically to do for identity what TCP/IP did for networking.
But then he goes on:
That's why identity as a service is the killer app. Not as a service offered in its own right to individuals, but as a service to websites and providers that have no workable identity management infrastructure of their own to offer their users. Restricting access on a named-user basis to individual URLs — RSS feeds, screencasts, PDF files or web service URIs — is the key that would enable such sites to realize value from those assets. At present it's not a viable option because of the cost and/or hassle of maintaining their own secure identity management system. But if the site owner could sign up to a third-party identity service, and have an embedded sign-up process that meant the service provider would take care of allocating rights to the user profile and then authorizing access to the relevant URLs — perhaps with options to measure or limit usage over a certain period — it opens up a whole new world of possibilities. Make it cheap enough — no more than a dollar a month per ID — and at a stroke the fabled thousand flowers would bloom as businesses found new ways to monetize information flows and online services by restricting them to named users, whether they be employees, customers or even other websites and service aggregators.
Hmmm - Phil, haven't you just invented
Passport? ;-)
The challenge isn't really about technology - it's about trust (which is something that Microsoft
fell over with Passport and "
Hailstorm"). Who is going to be trusted by the various stakeholders to actually manage identities? Government? (The UK identity card furore would suggest otherwise.) Financial services companies? (The identity theft furore around credit card data is not a good sign.) Lastly - any such solution would ultimately require co-operation between such service providers since no one organisation is big enough.
Plumtree becomes AquaLogic User Interaction
When BEA announced its planned acquisition of Plumtree, I
commented that the company's justification omitted what I felt was an important factor underlying its $200 million investment:
"
John Kunze, the CEO of Plumtree, discussed composite applications as part of his contribution to the announcement. Whilst this did not figure as prominently in terms of the justification for the acquisition, I can’t help thinking that this is also significant. When BEA announced AquaLogic the company emphasised a shift away from application development through coding to service composition and even talked of an AquaLogic ‘Composer’ for use by non-developers. But it remains just that – talk – and the company currently relies on its existing WebLogic Integration and Portal products to compose services into higher level integration processes which, together with data and information services provided by the AquaLogic Data Services Platform, can be accessed by users. The acquisition of Plumtree will bolster BEA’s capabilities here, particularly in terms of reducing the reliance on developers but, as with the multi-platform proposition, there is still work to do."
Well, it seems I was right. With the closure of the acquisition on Thursday BEA announced that Plumtree's portal will be sold and marketed as
BEA AquaLogic User Interaction, which the company positions as "
a new, integrated family of AquaLogic™ products used to create enterprise portals, collaborative communities and composite applications, all built on a Service Infrastructure." Whilst this is a necessary move by BEA, given that the user interaction component of the AquaLogic portfolio was an acknowledged gap, the company is still going to have its work cut out to clarify how it relates to the WebLogic Portal and to extend the
Swiss characteristics of the Plumtree product to the remainder of the AquaLogic products.
Service notification
How does a service consumer become aware of new services? Standards inititiatives, most notably UDDI, work on a polling model, where the consumer searches the registry for services of interest. The parallels here with browsing are obvious - in the early days of the web I would have to periodically visit a site to see if it had anything of of interest. With RSS/ATOM the content now comes to me. IBM's
James Snell shows how the same approach can be applied to service notification, in this case using ATOM.
Stoking the Sun database fire
Back in February, News.com
reported how Scott McNealy suggested in a presentation to financial analysts that Sun might offer its customers its own database in direct competition to the likes of Oracle, IBM and Microsoft. At the time, he would say no more than "watch this space". In an interview with Sun president Jonathan Schwartz soon afterwards he indicated that databases are one area where the company may look to extend its open source offerings. Earlier this week Sun's software chief, John Loiacono, added
further fuel to the fire and is quoted as saying "...we are looking at PostgreSQL right now".
My gut reaction back in February was that McNealy and Schwartz's hints had all the hallmarks of a typical stunt by Sun. It seems highly unlikely that any customers have been saying "please Mr McNealy, we need a supported open source alternative to that nasty database from Mr Ellison."
Sun’s strategy with the Java Enterprise System (JES) is to offer customers an integrated technology stack to enable application development and deployment. JES, in its current guise, has one obvious omission – a database. In the past the company has relied on its partnership with Oracle to plug that gap and would not have wanted to risk alienating a key partner in generating server sales. Now, with Oracle clearly shifting its strategy away from large UNIX-based multi-processor servers from the likes of Sun and towards clusters of small, x86-based Linux servers from Dell in particular, Sun has less to lose in attempting to plug the gap itself.
However, it makes no sense for Sun to go back to the drawing board and build a database from scratch. Sun already uses Sleepycat’s BerkleyDB but it is not a general-purpose database. There are plenty of open source databases to choose from but McNealy’s presentation appeared to position the most likely candidates, MySQL and PostgreSQL, alongside Oracle and DB2 leaving CA's Ingres as the most obvious alternative back then. Loiacono's comments indicate that Sun has changed its tune (perhaps the legal machinations required to rationalise Sun's Community Development and Distribution License (CDDL) with CA's Trusted Open Source License were too much).
The database market, as the presence of viable open source alternatives indicates, is a mature market and is dominated by the big three: IBM, Oracle and Microsoft. I hope that Sun isn’t looking at this as a significant revenue opportunity. Rather, with Oracle and Sun moving further apart and the former offering an infrastructure stack which competes directly with JES, any move into the market by Sun would be a predominantly defensive strategy.
Sun and Google collaboration: oh well, you can dream...
OK, so it's not as exciting as many of us might have thought...but it might become more interesting...maybe.
In a nutshell:
- Sun is altering its Java client download/update process to act as a carrier for the Google toolbar (users will have to explicitly choose to opt out of having the Google toolbar installed along with their Java update). Sun will get paid for this, but obviously no-one knows how much - and it's likely in reality to be partly a
quid pro quo for...
- Google is becoming a Sun customer - for server hardware, software and associated services (though again, they're not saying what Google will be buying)
- the two companies have agreed to explore ways of bringing OpenOffice technology closer together with some of Google's services - at some point.
Are there any profound implications of this?
Obviously having Google as a customer will be a nice scoop for Sun. Getting the Google toolbar streamed into to 20m+ Java client downloads per month will be a nice boost for Google, too. But we probably won't hear anything more interesting from these guys until the middle of 2006, is my guess...which is a timeframe that coincides nicely with the planned launch of Office 12.
Google + Sun = a fundamental shift or NC redux?
I know it's a bit "previous" to try and analyse something that hasn't even happened yet, but I thought it might be fun to slap some thoughts down about this, so that I can come back (after 10.30am PST, when Sun and Google are to dis
cuss a collaboration effort of some kind) and see if we're just talking crap. Having talked to the "other Neil" (he's way smarter than I am) below are three completely self-generated (we haven't been prebriefed) predictions about what might be on the cards:
- Google will offer a hosted version of StarOffice, with an AJAX user interface (a la Gmail)
- Google will integrate Gmail, Google Talk into StarOffice and the Java Desktop System (JDS), adding collaboration features
- Google will work with Sun to extend nascent Google services and integrate them into StarOffice/JDS - maybe including an online filestore, or an extended version of Google Groups which provides Sharepoint-like content management functionality.
Of course it might not be any of these - but I suspect that something like one of these things will be involved (certainly if
Jonathan Schwartz's blog is anything to go by).
These companies are intimately intertwined via Eric Schmidt (who held various senior positions at Sun), and both companies (and Eric Schmidt personally, from his time at the head of Novell) are resolutely set against Microsoft as a competitor. With Google on board, I suppose anything's possible (just look at the
market cap - currently 7 x
Sun's - maybe it's a precursor to a union? ;-). But even if the collaborative effort only succeeds as far as Sun's
previous "big idea" effort to outflank Microsoft, it will at least force Redmond to seriously re-think how it delivers value to users in the Web 2.0 era - which can only be a good thing.
