BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Interviews Tim Bray on the Future of the Web

Tim Bray on the Future of the Web

Bookmarks
   

1. Hi my name is Dionysios Synodinos and we are here at QCon San Francisco with Tim Bray from Sun Microsystems, to talk about the Future of the Web. Mister Bray with all the buzz about Rich Internet Applications there are many that believe that the future of the Web is synonymous to RIA technologies. What do you think of the RIA notion in general?

So when people talk about Rich Internet Applications unfortunately what they seem to usually mean is like Flash. Things that respond to key strokes and wiggle and morph and have video and move around, and they say that we need these things because the web needs to be more responsive, and more immersive and more reactive, and I am generally speaking massively unconvinced. I am old enough to remember before the web when everybody spent all day every day dealing with reactive immersive response compelled applications usually written in Visual Basic or Motif or something like that and mostly really bad. Because designing user interfaces is a hard thing and most of them aren't done well and most of them are bad.

When the web came along people shriked with glee and universally abandoned all those rich immersive responsive pre-internet applications and ran into the arms of the web. I can remember like yesterday content management conference that was held sometimes in the middle late nineties and it was a woman from a large manufacturing company talking about the content management for the technical documentation, which was a pretty big project, and she said "Oh it was so great when the vendors all brought in the web interfaces because it forced them to get rid of all these weird cascading menus and options that nobody ever used, and brutally simplified everything down" and at the end of the day the interface the browser presents is something that people are comfortable with. Over the years since then I have regularly and steadily heard them saying: "We need something that is more immersive, more responsive, more interactive".

Every time without exception that somebody said that to me, they have either been a developer or a vendor who wants to sell the technology that is immersive or responsive, or something like that. I have not once in all those years heard an ordinary user say "Oh I wish we go back to before the days of the web when every application was different and idiosyncratic ... ". On the other hand richness is a good thing but I would rather take an old fashioned point of view and if you look at the world's most popular actual real Internet applications you'll see things like Google and Facebook and Wikipedia, and so on kind of which I play all day web applications, and they are rich all right, they are rich because they expose you to lots of deep high quality content and allow you to communicate with interesting people and I think a dollar with that kind of richness is worth a thousand dollars of things that wiggle when you put the mouse over them So I tend to be highly cynical about this whole subject.

   

2. To the extend that web applications need to become richer, do you think Ajax is the horse to bet on? Also do you think that web browser is sufficiently interactive to facilitate highly engaging user experience?

Regarding the answer to the last question, the answer to this one will be fairly obvious. Yes, I mean Ajax is getting awfully good in particular with the advances that are being made in the browser technology with the increased compatibility between things like Firefox and Safari and so on and the new canvas element and the fact that the new browsers have these fantastically high performance JavaScript engines in them. I suspect that the gap in the ecosystem that lies between what you could achieve with Ajax and what you need something like Flash or JavaFX or Silverlight to achieve it's not that big enough to be terribly interesting.

Interactivity is important but you know what else is really important? The back button. Ordinary people who have to use computers to get their daily jobs done, are sitting there in the web browser they really like the back button because applications are confusing, nobody has ever done an application that isn't confusing some times and when you are confused you say "I will just get back out of here". Anything that discards the function of the back button is a step backwards.

   

3. Something that people often associate RIA with is the Comet programming model for pushing data to the client. This push based model is usually credited with being more scalable than polling. Yet on September you wrote on Twitter and I quote "Any time someone says polling doesn't scale, God kills a kitten". Do you find that the claims that people put on Comet for low latency and scalability are exaggerated?

I just don't think they are based in evidence, I mean the notion tha polling doesn't scale is ridiculous. The whole web runs on polling and the whole universe of RSS and feeds runs on polling. It scales beautifully it works perfectly with the existing caching mechanisms that are built into the web and the deployment mechanisms, and the load sharing mechanisms and all that stuff. A notion that I can successfully keep persistently open channels to a huge number of clients and that is going to somehow scale better then the clients occasionally calling to see what's newI is violently intuitive so anybody who is going to make a claim like that needs to come up with some powerful evidence saying "I think it's more scalable here and the numbers that I have approves that is true".

So I simply don't think it's true. Now clearly there are situations where you need to push, where the client does not want to poll, the client wants to sign up and get pushed when something important happened. The success of the Blackberry if nothing else should be evidence of that but the cost of doing that is pretty high. I mean it's really a massively heavier load on the server when it has to be prepared to push, and then there are arrangements such as reverse polling, where you essentially want a server on the client and you say "Ok, I want you to push data to me but it doesn't mean that you have to keep a connection open because here is the address of my server, so call my server and tell me when something is changing" as the remote devices become more and more powerful that becomes a much more interesting model, if you look at the Azure stuff that Microsoft announced they have got a Workflow module in there and the way it works, is you call up, and what happens is when you use that library to say I want to be notified in advance what you end up with is atompub server end point on the client and then the server when it has to tell you wakes up opens a connection and pushes it up at you.

So the notion that push has to be associated with persistent communication is also unsupported by the evidence I think and then finally there are really truly cases where you do want to keep a connection open and people are chatting with each other or something like that and then there is lots of interesting work that has been going around for example XMPP to support that and there are some really smart people who think that there is a large chunk of the whole server spectrum that is going to be better implemented in XMPP as opposed to via polling I tend to think that they need to have strong proof statements because ... polling historically worked so well, we'll see how that plays out.

   

4. Concurrency and the utilization of the multi core processors is getting much attention lately. How relevant do you think this is for the web in terms of application architecture and development? Will the shift to concurrency oriented programming become the norm for web applications?

Clearly it's not hard to understand the reason why this is becoming a big deal is that Moore's Law is still working you can still put twice as many transistors on the chip every eighteen months or so. But historically those transistors were all deployed fanatically to the goal of making a cycle. And if the cycle time has increased according to Moor's Law we'd be acting like twelve to fifteen GHz now and the fastest chip in the world you can buy is five GHz PC part from IBM that is insanely expensive and probably requires a cooling tower to keep it cool and it is a mainframe class thing.

Typically the GHzrace has run somewhere between two and three GHzand so instead of making it faster you are making it wider so the notion is you take a part like we ship at Sun the new CMT Spark parts that have eight cores with four eight threads per core and run at lest than two GHzat one point four GHzand as such generate a lot less power shoot, they draw less power and they generate less heat and so they have an overwhelming economic advantages. Now the problem used to be that if you had a Perl script that wasn't running fast enough you could spend six months making your Perl scipt run faster or you could go and play in a rock band for six months and have fun and when you came back your Perl script would now run faster.

I didn't make that story up I read it on the web somewhere. It's not like that anymore I our single threaded aren't spontaneously getting faster. Now it turns out that for those of us in the web applications community we are actually better off than the rest of the world because web applications naturally work really well on slow multi core processors because web applications are typically not compute intensive. You get an http message over the wire, you go and parse it, you go poke around in some databases, pull some information out, maybe update the database and then generate html around the output. Where's the computation? It isn't much. So running on a lot of slow cores tends to work pretty well. If you are running on classic Java EE platform you can just drop it on one of these things, it will just work.

Even if you are on Rails, or Django, or PHP or something like that there is a variety of ways to get the scale out as opposed to scale up without suffering too much pain, Now the people who are really hurting are the people with production critical Perl scripts and they go C programs and Fortran jobs, because the world has some of those too, there actually remain some jobs where you have to do a substantial amount of computation. The place where this bit me recently was I have a popular blog like everybody else I do log file analysis, and I moved from Perl to Ruby, because Ruby is more modern and my Ruby script has analyzed my log files run faster on my MacBook then they do on big expensive Sun servers. That's kind of painful. So, for those of us who need to run scripts and we need to provide some infrastructure to make that more amenable to running on slow multi core machines. But by enlarge I wouldn't call this a particular pain point in the web context.

   

5. When some organizations decide on the use of a certain technology, they invest a lot of time and effort for things like education, libraries, infrastructure and custom components. Although this kind of investment makes them more productive at the beginning, it might be prohibiting them to use new technologies which might prove more valuable in the future. On the other hand there are organizations that do minimum investment on a certain technology and are quick to incorporate the latest and greatest that promises to leap frog productivity. With the fast pace that the web technologies evolve, where would you stand on this issue?

There is some good news. Given that more and more the technologies that people might reasonably want to deploy are open source and free, the cost of adopting and deploying them is substantially lower. Now the cost of training is still a real issue. But this is a very difficult issue and I don't know the answer to it. I have recently been doing presentations to bankers to large financial institutions, who are interested in new technologies like Rails and Django and things like that, and really the business driver for them is time to market, they have heard that using the technologies that carry the web 2.0 label take and deploy non trivial web applications, in a single digit number of weeks as opposed to a double digit of number of months, and you don' have to be a business genius to see that's a big win.

But obviously it causes them discomfort, these guys are typically very huge Java shops with immense amounts of exactly what you describe, investments in Java tools, Java training and so on, and I was talking to one of the we had this exchange last month, I won't name the bank, and I was explaining this and they were actually quite seduced by the notion that they could get productivity increases with Rails and so on particularly since they could run it on the Java platform with JRuby and so on. This makes me nervous because we've got this huge investment in standardizing on Java and building school except of course the old Cobol is still around but beyond that it's all Java and so I said "Yeah, and back in the days when you had this huge investment, standardized on Cobol, how did Java get on the door?" At some point you do have to strike a balance between developing expertise and tooling around your deployed standard infrastructure and openness to new ideas.

And I have to say most of my time out in the wild frontier of open source, start up, web, socially oriented community based applications and technology goals between what's happening there and what happens in the enterprise is pretty painful, and I would suspect that the large enterprises who figure out how to judiciously and tactfully start deploying some of these new technologies, are going to get a major business advantage from doing so, but I am not going to claim that it's going to be easier or painless.

   

6. Over the past year or so we have seen much debate around Web Oriented Architecture and it's relation to Service Oriented Architecture. What's your view on this matter and about the web as an emerging integration platform?

That's a long answer. I mean the applications typically don't run on individual computers they run on networks, individual applications run on networks that are heterogeneous, that's just the way it is. No matter how hard the CIO tries to standardize they are going to have Windows, Java, PHP, you are going to have this stuff and that's reality. So how do we build applications that run smoothly across networks and we as the IT professionals have been grinding away of this problem for decades and by enlarge we have done very poorly, we invested billions in Corba and that was kind of a disappointment. Our friends at Microsoft invested more billions in DCOM and that was kind of a disappointment.

And then all of a sudden twelve fifteen years ago, there was this platform burst out to the sea that scaled to billions of users and millions of servers, was radically heterogeneous and it didn't matter whether you were a Mac Linux box talking to an IBM box, you couldn't even tell most times, it just worked. And that was the web of course. And non un-reasonably the IT architects looked at that and said "I want that kind of scalability and that kind of heterogeneity and that kind of integration" and even back in the old days in the old search engines and so on, people were doing web oriented applications, and saying "I will go and make some HTTP calls to various servers and piece them together and generate the result from my user".

Worked fine kind of ad-hoc there was really no formal framework around doing that and then XML came along, in 1996 to 1998 providing everybody "Ok that's a good enough format to use for our pay loads", and so you take HTTP and you ship XML around and do some quick and dirty duck tape style integration and it worked pretty well. So then people said well this seams to work we should maybe formalize it. And thus was born the notion of web services often called in the old days XML web services. And unfortunately that went radically off the rails, because of the construction of the SOAP and WSDL based WS-* stack and there were a bunch of reasons why that went wrong and I said it on my blog, I am not going to repeat them here but by large the stuff as it has been released on the world it tends to be brutal expensive and have a lousy interoperability and so on and so forth. Meanwhile, people kept on doing quick and dirty plain old XML integration all the time and it worked pretty well.

And then people started to pay attention to the notion of REST which is sort of a formalization of how the right way is to think about doing web style integration and near as I can tell there isn't really any difference between what people have been calling WOA and REST they are just two different labels for the same thing. And this is basically just an attempt to use web thinking in general and HTTP in particular the way they were designed to be used and take advantage of the caching and various other kinds of content delivery infrastructure of the web offers and given that the WS-* stack is not quite totally stone cold dead but not of general purpose interest anymore, it's pretty clear that at the moment REST is the horse that most people are betting on.

   

7. HTTP which is considered the backbone of the Web has been around for a long time. Do you feel it needs a major update? Maybe something in terms of extensions?

Well, if I weren't sitting and talking to you I would be upstairs in the REST track talking about the project to revise the HTTP specifications over at the IETF the original author of the specifications is involved in that work so that is good, I think though that the main goal of that work is not so much to extend and improve HTTP as simply to clean up the spec to remove some errors of ambiguity and make it more usable for implementers. So I at the moment don't particularly perceive a strong need for any radical improvement in HTTP. But the nice thing is that for the first few years the web frameworks were being invented and deployed in the Java EE world and things like that, in the .Net world and they struggled against http they wanted to try and make it look like it was actually distributed objects with object models going across the web things like that.

And if you look at the new frameworks, things like Rails and Merb and Django and so on, they are actually trying to go with the flow of HTTP and be good citizens and get the caching right and get the e-tags right and all the things that really actually make HTTP work. So I think that the work those guys are doing is valuable, I think we are moving in the good direction anyhow.

   

8. So you are not foreseeing HTTP going away or changing radically?

No, I don't and it's the single most widely deployed protocol aside from the basic TCP/IP that makes a network and it's got a tremendous momentum and there are a few but really very few deployed applications where HTTP is a pain point. It tends to be the part of your application that mostly tends to just work. So I suspect that it would be pretty stable for the next short term anyhow.

   

9. Someone has said and I quote "Crisis accelerates time, stops trends and breaks continuity". Now what could that mean for the evolution of the Web with respect to the current financial turmoil?

Clearly we are not in the same landscape that we were in six months ago. And from the business point of view we are going to see that a lot of traditional application planning a deployment cycles are simply going to be broken. The notion that you can use the waterfall model to spec out a project and start by buying Oracle licenses and hardware servers for seven figures and plan for deployment fourteen months from now, the senior VP isn't going to sign off on that anymore. They are worried about getting over the next six weeks and not about the next fourteen months.

I think that this is probably a very powerful force, in favor of things like Agile methods and Open Source Software and the Cloud all the things that are both monetization on the point of value. Technologies that are going to succeed in a tough times are going to be the ones that are free to adopt, and cheap to deploy and then when they actually start to go to production that's when you are willing to pay some real money for them, because you saw. So I think that moves us from services and support business model to big up front license and cost business model from deployment to the cloud as opposed to deployment into privately held servers. I think that it is easy to see a bunch of existing technologies, that are going to be encouraged and promoted like Agile like Cloud, like Open Source. Will the current climate of crisis produce some radically new technologies? I wouldn't be surprised if it did, I am not smart enough to see what they are right now.

   

11. Can you tell us a little bit about how you see this going forward?

Sun hasn't said very much. I mean we did the network.com a couple of years ago we had the Sun Grid and that was pretty successful actually, but only for big jobs, so we made actually a certain amount of money, renting a thousand computers for people to do protein folding or oil field modeling or silicon chip emulation or things done. But in terms of being a service oriented offering we haven't really done anything yet that is very interesting. So right now at Sun we are thinking what's the right position for Sun to be in and we haven't announced anything, and interesting questions include should Sun try and be a major cloud operable or is our better positioned to be a provider of tools and infrastructure for people who are going to be operating the Clouds. But nothing really has been announced.

   

12. Personally do you see the cloud computing vision to continue to go strong?

Absolutely. It is already here, everybody has outsourced search and email to the cloud. Amazon is doing very well with .EC2 and S3, but I think there are two or three problems that we have to solve before the Cloud can realize its full potential. First is what is the right level to operate? So Amazon offers you these naked virtual CPU instances and naked storage blobs, Google app engine offers you a much higher level platform to deployment of Python code in the Cloud. There are things like Morph labs that do essentially Rails level, stage includes copy of Rails into the cloud and it runs that way. And I don't think we have got good consensus yet to what the most productive, is it platform as a service, is it CPU as a service, is it who knows? And we are still working through that.

The second thing is fear of lock-in, I mean right at the moment if you go and deploy a Google app engine and build an application that happens to use Google in it, well you are locked in. And I would think that the smart CIOs of the world having gone through the history of the last few years where many of them are currently suffering from both Oracle and Microsoft lock in and you are in a situation when you are down turn but there are external vendors who have control over portions of your IT budget. I mean Oracle raised the licensing prices dramatically in the last couple of quarters and they don't care if you are having a budget crisis, if you want to keep running Oracle you have to pay the rent.

So I think that CIOs are going to be justifiably extremely paranoid about lock in and before I deploy a substantial enterprise application into the cloud, I need to be very confident that if I am not happy with the level of service I get I can un-deploy it and put it somewhere else. Of course the third thing is just security, I mean if I am a CIO am I going to take customer banking application and put it into the cloud? Well maybe but you need t have a very convincing story about encapsulation and isolation saying "My data is not going to be inevertably mixed up with somebody else or revealed with somebody else". I think the economic arguments in favor of cloud computing are very strong, but we have got some technology and policy and locking issues that we are going to have to resolve together.

   

13. Don't you think it would be interesting to have a VM, Cloud VM something that would abstract all these services and would offer some kind of interface or specification so that we can decouple the application from the cloud?

Google app engine takes the view of Python plus BigTable is that, Morph Lab takes the position of Rails in the Cloud VM. My feeling is that rather than trying to inventa new cloud VM why not use one of the existing web application frameworks like Rails or Django or something like that. And simply offer that because we already have a lot of tooling and expertise which is around it and you know the task of building a new one would be demanding and time consuming.

   

14. What do you think the ideal of developing web applications would be in five years and what do you think the reality of developing web applications would be in five years?

At Sun we have these occasional summits, when we have chief technologies, from the various parts of the company together to talk to each other prognosticating and so on. The guys who are building the CPUs talk about the things that are going to be shipping in Q3 2011 and things like that. The guys who do Solaris talk about their role and schedules of six months releases going in this year, and then it comes round and they look at me and I say "I didn't know last year that Twitter was going to be hot". Things on the web tend to come and go in weeks not years, so it beats the hell out of me.

I would hope, the direction we have been following is fairly clear from Java EE to PHP to Rails, the direction is that we are trying simultaneously to reduce the barriers to entry to building web applications, while, at the same time improving the cleanliness and maintainability. Obviously the value proposition of something like Rails or Merb or Django is to get the low barrier entry and ease of use that PHP offers, well at the same time getting use of something that is clean and maintainable and test driven and MVC and so on. I would hope that both of those directions are such obviously good things that you hope to see them continue. Now you see attempts like Yahoo pipes where there is an attempt to take away the need to program entirely and do it by moving blocks around the screen.

I tend to be a little bit skeptical of those because I can remember the 4GLs that were around back in the 80s and 90s we were supposed to do away with procedural programming life kind of has if statements and I suspect that necessity for writing code won't never be entirely done away with. On the client, JavaScript is really going through a golden age JQuery is very very good, presumably the ease which you can achieve JavaScript effects without having to sweat too much about different kinds of browsers will continue to increase and get better, five year I am not remotely smart to begin to see that. One thing though every killer app on the Internet, every success story on the Internet entirely without exception has been about communication.

The killer app of the Internet is people there is always people I don't think any reason to think that it is not going to be people, email, the web, lightweight publishing, chat, IM, Twitter, Facebook, Yahoo, Flick, Youtube, it's all about finding new ways of sharing with other people. We have got all these communication channels and a couple of centuries ago to talk and be in the same room and the phone came along and then eventually email came along, and then chat came along and IRC and IM and Twitter and until Twitter existing nobody could have predicted that you needed a thing like that. But now for many of us it's an essential part of our daily work environment and how many other communication channels that we don't know we need are going to be invented and quick become essential. So I think that we can safely predict that as long as the Internet grows, its primary effect will be to facilitate easier and richer communications between human beings, the infrastructure we use to build that effect is to be invented.

   

15. For enterprises that are currently using WS-* and which like WS-* what do you think will be the driver for them to adopt a more RESTful solution?

I don't know those people... very well. Particularly in the financial world I gather that there are some widely deployed WS-* services for things like financial instrument pricing and so on, things when installed software tends to last a long time. I see very few instances of interesting new WS-* stuff being stood up. And I would think that as we move in a more service oriented and web oriented direction, increasing the interesting services are going to be RESTful. Kinds of services and the pressure to integrate with and use those will push things in the right direction.

Even Microsoft which was clearly the leader or co-leader with IBM with WS-* movement, in the next generation of WCF everything is starting to look a whole lot more RESTful and Microsoft Azure has built around AtomPub in large parts. The vendors are pulling and pushing and the services are pulling and pushing. So I think the movement will happen fairly organically.

Mar 23, 2009

BT