Web 2.0 is Distributed Internet Applications
DIGG IT!
19
Comments
Published
Sunday, October 15, 2006
at
1:57 PM
.
The applications driving Web 2.0 shift processing to the end users computer leveraging the idle distributed computing capability of web clients. We are entering the era of Distributed Internet Applications. These applications have all the benefits of desktop applications yet leverage the Internet while remaining easily deployable to a mass market. Here is my take on the trends we will see as distributed computing goes mainstream.
Real-time & Multi-User - We will see an explosion of applications that allow many users to work together in real-time. The solo internet experience is dead and social applications have highlighted the importance of shared experience. We will see an explosion of applications leveraging Socket connections enabling bi-directional push data exchange. I have witnessed many developers exploring integration of XMPP, SVN, VOIP, RTMP, XMLSocket, Messaging, Data synchronization into applications. This trend will only grow.
Online/Offline - We will see applications that let users work online or offline seamlessly. These applications will be able to detect Internet availability and execute logic accordingly. I will fill out my expense report on the plane offline and when connected, my expense report will be submitted automagically.
Rich, Beautiful, Amazing - We will see applications that seamlessly integrate audio, video, images, animation, data, and text. These applications will be easy to use and provide a greater UI experience than anything available today. End users want graphically rich applications that are both intuitive and productive.
Simple Server APIs - Servers will get much simpler as the presentation layer is removed and they evolve into APIs. Instead of serving data embedded into the presentation layer of HTML, we will see servers publish an API that implements a standard integration format, like SOAP, REST, AMF. These API standards will allow mash-up applications to be created by mixing data from distributed services. We will see faceless API's being sold/leased to power these distributed applications. If I want a backend for a "Job Board" I will rent a API/backend that allows for seamless integration into my application.
Flash Player/Apollo is the client - We will see Flash Player and Apollo become the defacto standard for web/desktop application development and deployment. Given support for MP3, XML, AS3, E4X, Socket, Fonts, Messaging, vector graphics, GIF, JPG, PNG, SWF, ByteArray, FLV, zlib, AMF3, On2, Sorenson, Nellymoser, File Upload/Download, Full Screen, components, RSL, Local Shared Objects, filters, animation, Read/Write FileSystem Access, Desktop Integration, Shared Object, and Streaming video/audio upload/download, we will see amazing applications created. These applications will be rich and seamlessly deployed atop Flash Players wide platform support. Apollo will allow these rich applications to jump outside the browser yet integrate existing browser content seamlessly and compatibly. Yes, Apollo has a standards compliant web browser inside independent of the operating system (custom browser in 5 minutes).
Cross-platform - Given the rise of Apple OSX and Linux platforms, applications must support cross-platform. We have reached the end of the Windows era and Windows-only or Vista-only (plus hardware) options are a dead losers for development. WPF will be the biggest flop in the history of Microsoft because it is hardware dependent, not cross-windows, and not cross-platform. WPFE will be the equivalent of SVG, and thus DOA. It is simply no longer acceptable to create applications that do not work cross-platform. With Apollo we will see the first binary compatible application delivery model for Windows, Apple OSX, and Linux. Yes a single binary will install on 3 platforms. Why would anyone create applications with a limited reach?
It will be interesting to watch and participate in these groundbreaking changes moving forward. If anything is constant in technology, it is change itself.
My 2 Cents,
Ted :)
Wow I had to actually get my Web 2.0 dictionary out for some of this lol.
Very good insights Ted!
Campbell [xsive.co.nz]
I sure wish comments were real-time and push based. I am going offline now to play some softball.
Cheers,
Ted :)
I think you're right on target here. Especially with the shared experience and being able to work with Internet Apps while online or offline. These features aren't going to exactly easy. I have no doubt that the success of many websites will hinge around how well they enable this feature.
Now that's what I call Evanghelism!
Right on ;)
Well said Ted.
Quite interesting actually on the functional part but please don't try to bet on "cross-platform" or "independence" hype.
Your world is quite great but it is MONO-PLatform aka Flash Based : you replace windows or osx dependances by yours !
I am not worried by that but just stop this independence propaganda that lowers the power of your talk
"I sure wish comments were real-time and push based."
Reduce the price of FDS Enterprise by an order of magnitude or two and your wish would be much more likely to become reality.
Adobe and Macromedia have been very good custodians with Flash Player to date.
- The Flash Player is free.
- The Flash Player SDK is open for writing your own SWF files.
- The Flex SDK is Free allowing you to build Flex SWF files without cost.
- The Flex Data Services J2EE Server is free on 1CPU server side.
- File size remains small for Flash Player.
- We accept and embrace competition within the SWF format, there are lots of options for creating SWF/FLV with non-Adobe tools.
I am personally biased as hell towards Flash/Flex/Apollo but not because I work at the company. I was biased long before becoming an Adobe employee 4 months ago, check the blog archives. I was a customer for 10 years before becoming an Adobe employee.
There is a clear difference with the Flash Platform vs Microsoft Platform, Adobe makes free players and does not change the end user money. There is ZERO cost to the end user to use Flash/Flex/Apollo. This is wildly different.
My 2 cents,
Ted :)
Hans,
Free is more than an order of magnitude!!!
Flex Data Services Express is free on 1 CPU.
FDS only costs money when you need failover and clustering support in larger implementations.
Question: Do you currently have clustering/failover support on your HTTP server?
5 Points to Hans for recognising that FDS is a serious multi-user server built on J2EE. It is much more than remoting.
Ted :)
If Adobe really want to revolutionize the way we build and distribute internet applications they need to add P2P to Apollo. Then not only will the apps be distributed but also the bandwidth.
Apollo is definitly a step in the rigth direction.
P2P in Apollo? Hmmmm....
Flash Player supports:
flash.net.Socket, AKA Binary Socket for 2 way data exchange of binary data.
Code here is hypothetical!!!
import apollo.net.Server
myServer:Server = new Server();
myServer.addEventListener( Server.CONNECT, connectHandler );
myServer.addEventListener( Server.DATA, dataHandler );
myServer.addEventListener( Server.DISCONNECT, disconnectHandler );
myServer.ports = [80,8080,1492,1976];
myServer.listen();
Technically its feasable. Security and Legal will be the barriers on this one.
Ted :)
he... been going down that road too. It would be great to see this happening. I know Adobe is working hard on VOIP, but VOIP without going through P2P and force the use of FMS will not be a success... imho
"Free is more than an order of magnitude!!!"
FDS costs $40K the moment I need, want, or happen to have a dual CPU box or a second server. THAT is more than an order of magnitude!!!
The best way to support the Flex community--and to encourage far more developers to join the community--would be to do away with this 'bait and switch' pricing model. $20K per CPU to play with the cool kids after the first CPU makes Flex as a whole less cool... especially to developers outside of the regular Adobe community. That's the buzz I'm hearing on the street... especially in the startup scene, where the next killer apps are likely to come from.
"Question: Do you currently have clustering/failover support on your HTTP server?"
Technically no. However, my HTTP server is a dual processor machine. And I wouldn't mind being able to add additional servers going forward either.
Hans,
We do offer a departmental license at $6K per CPU so that would be $12K total for a clustered configuration. That would be 4X less.
Also for non-profit/non-commercial use licensing FDS is free.
Also the license states that if you limit the JVM to 1 CPU, you can utilize FDS on a dual CPU machine. This was added to support virtualization issues.
Regardless we need to do a better job of making FDS pricing/options clearer for developers. Most people I talk to think that FDS is just for RPC remoting which is pretty far from the truth.
The other key here is that you do not need FDS to use Flex. Many think that the server is required which is a false statement.
There is just too much FUD roaming around for FDS. Time to clear the FUD.
Ted :)
Thanks for posting this Ted! It's exactly what our team is creating.
I hadn't noticed the change to the Express license, so that's nice to know.
Doesn't address my basic point though, which is that current packaging/pricing precludes FDS from much of Web 2.0. Far from FUD, this is basic economics of Web 2.0 apps.
No Web 2.0 startup believes they'll only need a single CPU for their services tier, nor would any serious Web 2.0 company not put in place at least some level of redundancy. They want to appear on digg, techcrunch, and slashdot; and need to account for large possible spikes in traffic. So in that sense, it would appear Enterprise is the only FDS license that currently works for their needs.
But an enterprise license is orders of magnitude higher than could be covered using the majority of Web 2.0 business models or operations strategies... Unless Adobe is willing to defer payment until if and when a company is purchased by a Google or Yahoo.
Web services and HTTP requests are certainly alternatives to FDS, but the perception this leaves in the community is similar to 'bait and switch'. "We'll give you the basic functionality free, then knock you off your feet if you want the cool stuff." This strategy may work in the traditional Enterprise, but it's incompatible with the long tail, lots of cheap servers, lower startup capital world of Web 2.0. Too bad, as it's certainly not a problem with the technology itself.
Does Adobe honestly doubt they could sell more than 10x the number of "enterprise" licenses at a price point 10x lower?
I agree it's time to clear the FUD. Do so by making the technology that could be behind the next killer app more accessible to the folks who are most often responsible for killer apps. And that ain't the enterprise.
I would like to see Adobe allow us to write plugins for Apollo (similar to Zinc or even Firefox), so we can extend the platform for various forms of P2P or whatever else. It would make the platform so much more powerful and extensible (obviously).
There is quite a but of confusion over the fds licensing. My experience is there are other options Adobe will consider. If you are serious about using fds, contact Adobe sales reps and talk about your project and what you are doing. I found them to be helpful and flexible. They will also put you in touch with the right people to answer very specific and technical questions to determine if fds is right for you.
As many have mentioned, fds is not remoting, it is a whole lot more than that. If all you need is remoting there are other options out there.
The issue with Flash as the app delivery is that it is IMPOSSIBLE to flex the objects inside without major centralized programming. This kills it as a rich seamless integration that is truly open.
Also the penetration of IE in the market is more than Flash. With the closest competitor to IE (Firefox) can be made IE compliant with an add-in (IETab, I think), programming specifically for firefox or flash is not only expensive, it is plain stupid.
True that flash looks nice if you spend weeks and months creating an interface (and tons of dollars), most such applications have been highly constraining. Goowy and a FEW others being the ONLY implementation that has been anything major on Flash, and they too have reached their limit. The point is, Flash/Apollo becoming the development standard is not going to happen. However, the browser and javascript becoming the defacto app development standard is MUCH more likely.
Ted's article is for the most part very very appropriate - esp. in regards to browser being the platform and not the O/S.