tag:blogger.com,1999:blog-7181827288078342442024-03-04T20:12:01.607-08:00Will's BlogTLDRWill Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-718182728807834244.post-19968925485542723632011-07-10T16:20:00.001-07:002011-07-10T17:11:17.037-07:00<div>So, <a href="http://www.ebpml.org/blog2/index.php/2011/06/29/unrest">jdubray at Carnets de bord</a> has thrown down the gauntlet, I guess. He proposes "unREST". What is unREST? It's, umm, not REST. Simply put, it's RPC. Pretty bold proposition, don't you think?</div><div><br /></div><div>Here's to hoping that unREST sweeps the internet so that the Restafarians can focus on working out the details of trying to apply REST as given rather than cleaning up everyone's misconception that REST is using GET over HTTP for RPC. </div><div><br /></div><div>Let us put an end to "RESTful" web services and "RESTful" URLs, all things REST doesn't really have much of a say over or a care for. Lets hear it for "unRESTful" web services and "unRESTful" URLs. +1 to that.</div><div><br /></div><div>J (can I call jdubray J? Hope so...) starts off with:</div><div><br /></div><div><blockquote>REST was designed with an end-user in mind, operating a user agent: the browser (I know Roy is going to get mad if he reads this). Everything that has been written to apply REST principles to a software agent-to-server scenario is simply wrong.</blockquote></div><div><br /></div><div>Actually, no. REST has nothing to do with browsers, but unfortunately, the browser model is so pervasive, and it happens to use hypermedia, that it's a reasonable go-to artifact that can be used to help explain the concepts. A common ground between the theory and practice, especially over the limited bandwidth of things like blogs and forum posts. But, naturally, folks take the example given as law and miss the forest for the trees.</div><div><br /></div><div>He next cites three of Roy's REST premises, and damns them because "nobody" actually implements these concepts.</div><div><br /></div><div>Finally, he boils it down that nobody does this because there's not tooling for it. That all of the other RPC mechanisms give us the mechanism of exchange "for free".</div><div><br /></div><div>SOAP gives us WSDL "for free", CORBA gives us IDL "for free", and Java RMI uses Java classes "for free".</div><div><br /></div><div>SOAP, CORBA, and RMI are all popular, especially behind the firewalls. On the public internet, eh, not so much. </div><div><br /></div><div>Why is that? Why are these protocols not pervasive in the wild, cage free, free range internet when they give us all this functionality "for free"?</div><div><br /></div><div>Because the underlying complexity of these protocols inhibit casual adoption. There are rules to follow. Folks hate rules. Because of their complexity, the universal "we" are effectively forced to use tooling to participate. When you have to rely on the tools to do the work, as a participant you tend to ignore the details on the wire. Let the tools enforce the rules.</div><div><br /></div><div>Consider Java RMI or Remote EJB. As developers, we would create our Java interfaces, methods, parameters, etc. and publish them far and wide using the built in software. In use, did we ever actually look at the byte stream going back and forth? No. It's an opaque binary blob of unintelligible rubbish. And if there was some conflict or problem in the protocol, it certainly wasn't our problem, it was the toolings problem. We coded to the high level interface, and left the nitty gritty to the tooling. </div><div><br /></div><div>Just like we do today with TCP packets. We don't care what the bits and bytes and network order and packet buffers and sync handshakes or whatever. Open socket, socket.write(stuff), close socket. Shazam.</div><div><br /></div><div>SOAP, however, is "just XML". It bares its wire protocol to all. If anything the SOAP stacks over complicate things because they give the false hope that we actually have some control over the wire format, when in truth, we really don't. XML it may be, but what goes over the wire is STILL the tooling's problem.</div><div><br /></div><div>And that's the rub. When Tooling implementation A interprets the specification one way, and implementation B interprets it another, then it's happy fun time for the poor, powerless end developers that need to make it work.</div><div><br /></div><div>SOAP has matured greatly over the years, and interoperability is always getting better, but developers are still relying on tooling to do the heavy lifting. For J, that's a good thing. If the REST APIs had tooling to where he could drag and drop the interfaces, we'd likely not be having this discussion.</div><div><br /></div><div>However, if REST APIs had the tooling to do all that, then there would be effectively no difference from HTTP REST implementations and SOAP implementations. Much of the complexity that's baked in to SOAP is there for a reason. On its surface, SOAP is really (really!) simple. It's an XML header and payload. It's really trivial. All of the specifications go in to details about what's IN the payload, the SOAP envelope itself is straight forward.</div><div><br /></div><div>(Here's a secret, did you know you could implement a REST system on top of SOAP?? Really, it's true! REST doesn't care about the protocol. Does. Not. Care. It's an architecture.)</div><div><br /></div><div>J mentions agent-to-server, and when we talk about agent-to-server and both the agents and the server are machines, we talk about Machine-to-Machine, or M2M communications.</div><div><br /></div><div>REST represents the server architecture, and client expectations. A "well behaved" REST client can be quite complicated to be able to handle and support the flexibility that the server can leverage in order to get value out of REST. But here's the news. A BAD REST client, a client that ignores all of the pre-cepts and guidelines that are part of the contract of the REST server, does NOT invalidate the REST architecture. Just because one side does not play along by the rules, does not mean the design or implementation of the server is wrong.</div><div><br /></div><div>What is a bad REST client? It's something that make presumptions about everything. Normally, a REST client starts at the beginning of a graph that represents the REST server. The initial entry point. From there, the server lets the client know where it can go, and what it can do, what it should do next. A bad REST client may simply go "yea, yea, yea, I've been here before" and go stomping through the servers endpoints as if they own the place.</div><div><br /></div><div>That's what many systems do today by hard coding endpoint addresses, and making assumptions about payload, and format, and next steps. That's what we do when we write code. "Open socket, send this, get that, send this other thing, get that other thing, close socket". We code the recipe in to our clients, because "we know the way".</div><div><br /></div><div>Have you ever gone someplace you've been before, made the right, turned left, went down two streets, and turned in to the driveway to find what you were looking for wasn't there any more? "Wa..wa..wait a second, it was just here!" That's a bad REST client.</div><div><br /></div><div>Ideally, you would have called ahead (like your wife said you should). Perhaps the phone number changed, and you would have called that number instead. Then you would have asked "Hi, where are you located?", and got the new address. That's what a "good" REST client does. Every. Single. Time. That's a major part of HATEOS, in a nutshell.</div><div><br /></div><div>We don't do that in normal life, because we "know" that, as a rule, things simply don't change that often. There's no way I'm calling the grocery store every week to check on their hours or make sure they're still in the same shopping center I left them in last week.</div><div><br /></div><div>And that's why bad REST clients can "get by", and why folks see perhaps less value in REST. Because most people that write systems, write small systems. They write systems that they likely control both the server and client side of the equation. When the server moves, the pain of updating the clients to use the new locations is minor one off integration work.</div><div><br /></div><div>Because what happens to a bad REST client when the server changes? It breaks. It gets to the parking lot and cries "Oh no, Disneyland burned down!". Then it fills your logs with stack traces all weekend, and nothing gets done.</div><div><br /></div><div>Folks seem to feel there is some magic in REST clients, that since "REST is all about browsers and humans" that the clients should be some Skynet powered super cyber-being. Hogwash. Just code, people, they're just code.</div><div><br /></div><div>Code that knows to ask for what it wants, code that knows to ask for directions, code that knows how to parse and process the payload as it sees them. What happens when the code gets stuff it doesn't understand? Why, it breaks! Imagine that.</div><div><br /></div><div>Just like in real life, with humans. You know what happens when you reorganize a web page and move the BUY NOW button to the other side of the screen? The phone rings. People decry "What have you done?" "Where's the BUY NOW button?" "How do I ...". In other words, the agent breaks. Most people are resilient enough to adapt to the change. Most people.</div><div><br /></div><div>Proper REST clients are more resilient to change. REST clients are kind of like the Unit Tests of RPC. Unit tests help enable development teams to move quickly because the unit tests can inform the team when something unexpected breaks. With resilient REST clients, the REST server can move forward, quickly, with some confidence that the clients will "keep up". They may not understand the newest features, or additional data elements, but they won't necessarily break on the changes to the old ones. When you can count on the phone not ringing everytime you push a change, you tend to be able to move more quickly in advancing the system. Because we all know how much we hate it when the phone rings. At 3am. On your honeymoon...</div><div><br /></div><div>If you have an in house server with two in house clients, this kind of resilience is not a value add for you. The cost of implementing a proper REST client may well not pay back any time soon, it's simply cheaper to implement, keep track of, and fix bad clients.</div><div><br /></div><div>But recall, a bad client doesn't invalidate REST. A bad client works just fine with a solid REST server, at least for some length of time.</div><div><br /></div><div>With cooperative clients, if the server maintains some backward compatibility, then it offers more time for the clients to be recoded/retrained to take advantage of the new features. With cooperative/compliant clients, clients that actually use the information given to them rather than just making stuff up as they go, the server has more flexibility in the changes that it can make without the phone ringing. That's why the server controls the URL space, and the clients don't. It's not their URLs, it's the server URLs. </div><div><br /></div><div>Giving the clients control over the URLs is like giving the clients control over what office you work in. "Yea, I'd like to move to the office with the window over the beach volleyball court, but, 8 months ago I told UPS what office I was in -- so I guess I'm stuck here." </div><div><br /></div><div>L O L you say. Absurd you say. But that's what happens when you give the power of the location of your services over to your clients. No beach volleyball for you. Ensure that your clients can look stuff up, and this isn't a problem. Forget UPS, they can call me. Now I just need a set of binoculars.</div><div><br /></div><div>This is also why the use of ubiquitous media types are important. It's the same process. The media types in a REST system DO NOT carry semantics. The media type is rules about parsing and locating information within the media type. GIF is a media type. Blurry cell phone photos of scantily clad volleyball players is semantics (it means I have a better office that you do). The server defines what goes in to the media type, in terms of actual, interesting data and the application defines the semantics. Using ubiquitous media types means that there is a good chance other systems will ALREADY KNOW how to process it. "That's good, one less thing." -- F. Gump.</div><div><br /></div><div>In Healthcare IT, there is solid movement behind representing clincial information. One of those efforts is the Clinical Document Architecture, which is based on the HL7 v3 RIM model. There's enough documentation to represent these documents to make a nice, home leaf and flower press. But once understood, and once wide spread, implementors and architects will all be able to leverage and utilize all the work being done classifying disease, medications, procedures and preserving daisies and poppies to enable the flexibility that the ubiquity of the data formats bring. Much like we say today "do you have a fax machine" or "do you have email", we'll be able to say "do you understand a CDA C32" and send a great amount of interesting information. "For free."</div><div><br /></div><div>Why isn't XML or JSON a "valid" REST format? Even though everyone and their sisters cell phone can process it? Same reason XML isn't an Health IT format. Because REST wants hypermedia formats, not just fancy CSV. It wants something more. HTML is a hypermedia format, XHTML is one that just so happens to be XML as well. So is Atom. XML and JSON, "in the raw", are not. They're just fancy CSV. Others are trying to build better, REST happy hypermedia formats on top of XML and JSON.</div><div><br /></div><div>Once you get the media type out of the way, you can dwell on the details of the content that are important for the transaction. And from this you can train your systems to work with the interesting data that really matters.</div><div><br /></div><div>That's why REST promotes using standard formats. So we don't have to learn Yet One More thing. Let's create tools around the existing specifications rather than recreating them, and retooling, and re-documenting, and re-training EVERYONE (and every thing) to use the new ones.</div><div><br /></div><div>There's this notion, again, that M2M clients are some kind of super powered, semantic inferring, cognitive creation. The whole "out of band information" issue.</div><div><br /></div><div>Humans (mostly) have this power, but this isn't what REST is talking about. This inference and deduction process of figuring stuff out on the fly. Consider a web site. Arguably the most RESTy thing we have today. Common formats, hyper media, caching, the whole kit.</div><div><br /></div><div>But, see, this web site is in Japanese. Know what? I can't understand Japanese. At all. Such a website would be total, utter gibberish to me. Does that make it not REST? Hardly.</div><div><br /></div><div>What about a DNA sequencing system. Do you know anything about the process of DNA sequencing? I don't know anything about DNA sequencing. Even in english I wouldn't know what such a system did, what I would do with it, or why I would do something with it. Does that make the system not REST? Hardly again.</div><div><br /></div><div>Gonna need some training here. Probably a Phd would help as well. REST doesn't fix this issue. This may be a revelation to some. Amazing, I know.</div><div><br /></div><div>So get this notion about REST being only for web sites. It's not. It's an architecture for system using coarser data than we perhaps like, capable of being more fluid that we'd like to code for, using data formats we might rather not use. REST tooling is ubiquitous but at the same time, still more in the hand tool stage than the megabytes of frameworks and code generators out there. More integration would be better.</div><div><br /></div><div>But the true thing that's missing from REST development is the habits and experience of using it. Getting some solid good REST clients out in the wild with a code set amiable to re-use and building of other REST clients. Most folks don't get that far. Software is about abstractions, and REST systems present some very nice ones. But habitually, right now, it's simply easier to write bad clients against harsh servers and deal with the realities of not choosing the more flexible path. For most folks, the value that REST provides is simply unnecessary.</div><div><br /></div><div>All of the issues and problems that existed with RPC then, before REST was all written down, is still wrong with it today. So, unREST away, please. With your RPC and HTTP tunnels and XML payloads honed to the keenest edge, but do it over there please.</div><div><br /></div><div>Can I create an unREST tag on SO now?</div><div><br /></div><div><br /></div>Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0tag:blogger.com,1999:blog-718182728807834244.post-82111467467117267302011-06-17T16:49:00.000-07:002011-06-17T17:02:42.900-07:00It's Friday the Grosjeanth!Well, unrelated to any at all that's important. I'm having a strange <a href="http://www.urbandictionary.com/define.php?term=Grosjean%20Number">Grosjean</a> Numbers day.<div><br /></div><div>On <a href="http://stackoverflow.com/">StackOverflow</a>, of all things, my score, rep, cred, karma, whatever it is they call it there reached 23,456.</div><div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDK1qoTBGeg2m_vIxN7HnvT2dPgP1tXnyiviTW1q2E58GB3WzyrVcgZs3hy3-B4tktaqkuLmZH1U7a4loN83hPi57nKxgG8lHW2QjwdQ00Bo3XeST5_Q3t_OKXmw8V2K9JmAIhCv3Hz0Pl/s1600/Screen+shot+2011-06-17+at+4.56.59+PM.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><br /></a></div><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXJb7qF_Gj2d25MIGdqaFPTly9oIVnnQf2mnHGCHuVaKrN5SrHzvMCkEsbG8-yst_fhGPib-6DAcBFShzeKxxaPrY1oXNhAC4nnzaysR1zJi58tMUzhqHohTO6-Z5LWjf02iToj8ozFQZd/s1600/Screen+shot+2011-06-17+at+4.55.07+PM.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 244px; height: 30px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXJb7qF_Gj2d25MIGdqaFPTly9oIVnnQf2mnHGCHuVaKrN5SrHzvMCkEsbG8-yst_fhGPib-6DAcBFShzeKxxaPrY1oXNhAC4nnzaysR1zJi58tMUzhqHohTO6-Z5LWjf02iToj8ozFQZd/s320/Screen+shot+2011-06-17+at+4.55.07+PM.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5619341839423349554" /></a><br /><div>At the same time, my Google inbox is showing 3456 unread messages (don't ask).</div><div><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDK1qoTBGeg2m_vIxN7HnvT2dPgP1tXnyiviTW1q2E58GB3WzyrVcgZs3hy3-B4tktaqkuLmZH1U7a4loN83hPi57nKxgG8lHW2QjwdQ00Bo3XeST5_Q3t_OKXmw8V2K9JmAIhCv3Hz0Pl/s1600/Screen+shot+2011-06-17+at+4.56.59+PM.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDK1qoTBGeg2m_vIxN7HnvT2dPgP1tXnyiviTW1q2E58GB3WzyrVcgZs3hy3-B4tktaqkuLmZH1U7a4loN83hPi57nKxgG8lHW2QjwdQ00Bo3XeST5_Q3t_OKXmw8V2K9JmAIhCv3Hz0Pl/s320/Screen+shot+2011-06-17+at+4.56.59+PM.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5619342187894746786" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 104px; height: 22px; " /></a></div><div>It's stupid enough to be worth capturing for all eternity on my little non-corner of the internet.</div><div><br /></div><div>I don't dare query a Numerologist. It probably has some long term ramifications such as catching all the red lights on my way home tonight. Why taunt fate? </div><div><br /></div>Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com1tag:blogger.com,1999:blog-718182728807834244.post-44748234249095906562010-07-14T14:28:00.001-07:002010-07-22T11:20:42.992-07:00Couch 1.0 retrospectSurprise, to me, CouchDB 1.0 hit today.<div><br /></div><div>A call went out for folks to chime in about their experiences with CouchDB.</div><div><br /></div><div>I'm a casual participant, follower, and non-user of CouchDB since around 0.9. I have dabbled with it, but have not been able to employ it anywhere in my projects. The tool is in the box, just doesn't fit anything I need right now.</div><div><br /></div><div>I didn't head over to the Couch project trying to fill a need, rather when a friend started using it, I went over to see what the buzz was about. I learned a bit and started to linger in IRC and on the mailing list.</div><div><br /></div><div>I made an effort to understand CouchDB. I have a solid understanding of RDBMS systems, so I really wanted to understand this "new" thing. With the understanding I have, I post random stuff on things like Stack Overflow to help answer Couch questions, and offer other bits of support.</div><div><br /></div><div>As a "non-user", I found the community to be great. The principals live on the mailing lists and IRC. They don't just talk, they listen, and discuss the finest nuances of the systems with random strangers that just happen to show up.</div><div><br /></div><div>For me, the Couch community is the center of the NoSQL world. I think they have a unique perspective and are doing things different from what the other DB projects are trying to do. Because of its uniqueness, it's a great place to start and radiate out in to the large DB world.</div><div><br /></div><div>CouchDB 1.0 is exciting as it "finishes" the first leg of their journey. But the journey will continue and I wish them the best.</div><div><br /></div><div>Congrats to the CouchDB team and un-team.</div><div><br /></div>Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0tag:blogger.com,1999:blog-718182728807834244.post-90036052939488938032010-04-09T07:40:00.000-07:002010-04-09T08:59:50.281-07:00The first rule of Apple iPhone OS Development<div><br /></div>The first rule of Apple iPhone OS development, is never talk about Apple iPhone OS development. So says Tyler^H^H^H^H^HSteve.<div><br /></div><div>Apple previewed and released their iPhone OS v4 yesterday. Along with the new features comes a new development agreement. The development agreement is under NDA, but that didn't last long.</div><div><br /></div><div>The big news tweeting up the servers is this clause from the agreement:</div><div><br /></div><div><blockquote>3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).</blockquote>What this basically says is that you can no longer write iPhone OS applications in whatever toolkit you want, rather you must use Obj-C, C, C++ or JavaScript.</div><div><br /></div><div>It's an interesting limitation, and I've not heard of such a limitation on any other platform in the history of computing. It may well have happened before, perhaps back in the dark ages when IBM ruled the mainframe world with an iron fist. But certainly not at all recently.</div><div><br /></div><div>Currently, there are several toolkits that let you create iPhone apps using languages other than C. A popular one is the Unity Framework, used in many games. This toolkit uses C# to write the programs. MonoTouch is another C# framework.</div><div><br /></div><div>But this isn't just about what language you can use. The second clause about linking and compatibility layers is equally important, if not more so.</div><div><br /></div><div>The compatibility layer clause eliminates toolkits that offer a single API to run across platforms. Such as QT or GTK. With those toolsets you can write a C program that runs the same on Windows, Mac, or Linux.</div><div><br /></div><div>From the two clauses, it's clear what Apple wants. To quote Steve Balmer, "Developers, Developers, Developers, Developers". The key here, however, is that they don't want Mobile Platform developers. They want iPhone developers. They want developers specializing in and writing specifically for the iPhone.</div><div><br /></div><div>This clause does a couple of things.</div><div><br /></div><div>First, is strangles other mobile platforms. No longer can you write common code that will potentially run on all of the major mobile platforms, notably Android, which is Java based, and the upcoming Windows 7, which is Silverlight based.</div><div><br /></div><div>By requiring developers to use their tools and libraries directly, they can't write code (easily) that will directly compile on other platforms, and therefore will require somewhat significant porting effort if a company wishes to distribute an application on to another mobile device.</div><div><br /></div><div>That means that a company wishing to create an application for mobile devices will have to dedicate a team specifically for the iPhone. This is just like what happens today in the desktop world. A company has to choose whether their application is going to run on Windows, Linux, or Macintosh.</div><div><br /></div><div>You can observe the effect this has had over the years, with Windows being the most popular desktop platform, it, by far, has the most desktop applications running on it. Microsoft development tools have no reason to make it easy for developers to port applications written for Windows on to other platforms.</div><div><br /></div><div>Other providers, however, have reached out to meet that need for cross platform code bases, and many toolkits and development environments have appeared to fill the need. </div><div><br /></div><div>Java is the dominant leader in cross platform runtimes today. "Write once, run everywhere" so the t-shirt says. This is mostly true. There's some "Write once, debug everywhere" involved, but Java is mostly portable. And this portability along with other aspects of the Java system have pushed Java to the top of the charts, especially in the server and enterprise space.</div><div><br /></div><div>However, Java has not had the success in the desktop arena that they'd like to have. In fact, Java has it's own mini-platform battle being waged within its own ranks. Without digging deep in to the sordid history of why desktop Java isn't ruling the world, let me boil it down to two words: User Experience.</div><div><br /></div><div>The User Experience, especially earlier in Java's life, was simply not as good as native applications. The major reason was that Java had to reinvent all of the buttons, windows, sliders, etc. that user applications use so that they can use them on all of their supported platforms. So, out the gate, Java applications looked like, well, Java applications. Not Windows apps, not Mac apps, not even Linux apps (which is saying something, what does a Linux app look like anyway?). No, they look and behave like Java apps. </div><div><br /></div><div>The basics work, but the nuances aren't there. The speed wasn't there, the perfect integration wasn't there. Functional apps indeed, just not particularly desirable apps.</div><div><br /></div><div>If you have worked with an iPhone, it may have occurred to you that Apple has very strong views on how the UI looks, and on how it functions. They spend a lot of time on the "look and feel" of the user interface. Spectacular UIs is something that Apple is famous for, and it's part of the overall identity of their products.</div><div><br /></div><div>So, now imagine if something like Java came along to try and create applications on the iPhone. Basically the folks creating the application would have to "reinvent" all of the widgets that the iPhone provides. As history has shown, since it would be a black box reverse engineering effort, the result would be functional, but imperfect. It wouldn't quite work the same. You could just tell that the app is a little bit off. Making a cross platform application that works like that targeted platforms, is hard work.</div><div><br /></div><div>How many hours do you think Apple spent tweaking how fast a panel slides, how far the scrolling list bounces, or tuning all of the beeps and boops? And how important do you think all of those subtle tweeks are to the overall effect and feel of the UI? I'm pretty sure it wasn't all decided in a Friday meeting after a wet lunch.</div><div><br /></div><div>Apple has done some cross platform work. The example is the iPhone Users Guide. What many do not realize is that this iPhone application is really an embedded web application that runs on the internal Safari browser. 100% JavaScript.</div><div><br /></div><div>The trick is, that all of the animations and such within the app, all of the look and feel that makes it feel like an iPhone app, is coded, by hand, within the app itself. Within JavaScript. A glaring example is the scrolling.</div><div><br /></div><div>In a normal web app, you let the browser do the scrolling. You make a large list, print it out, and the browser pops up a scroll bar, and away it goes. Within the Users Guide, all of the scrolling is done in JavaScript. They rewrote that fundamental behavior to ensure that it looks and behaves properly. That's a lot of work for basically a bunch of webpages for something as mundane as a Users Guide.</div><div><br /></div><div>But it demonstrates the drive within Apple on how apps should present themselves on the iPhone.</div><div><br /></div><div>So, a side affect of forcing developers to use their toolkit, is that they help preserve the User Experience on the device. If Apple has proven anything, while applications empower a device, the experience they provide define the device. We have all seen GUI horrors that take perfectly good computer and make them miserable to use. Apple wants to prevent that from happening with apps on the app store.</div><div><br /></div><div>Mind, this is a secondary benefit of the policy, a side effect, albeit a desirable one for Apple, but it's not the primary goal.</div><div><br /></div><div>The primary goal to make iPhone OS the premiere mobile platform. Developers have been flocking to the iPhone already, and the iPad just works them up in to an even frothier frenzy. By restricting the toolset, Apple want the iPhone OS to be like Windows OS. Which means they want it to be the primary platform developers use when they want to target the mobile space.</div><div><br /></div><div>If a developer does so, then they immediately give the iPhone OS a potential time to market advantage, because, at the moment, it's not trivial to port an iPhone application to another device. Most mobile applications are 90% UI, and with the iPhone, all of that UI will be tied up within Apple specific code. To port to another platform, you can take your 10% of logic and rewrite the entire user experience on another device. </div><div><br /></div><div>That will take a lot of time and resources. If the iPhone market is Big Enough, many developers simply won't bother to port the application, much like many Windows developers don't port their applications to Linux or Macintosh. Now, if they had chosen a cross platform dev kit instead of, likely, a Microsoft specific dev kit in the first place, they may well port to the other platforms. But they didn't, so they don't. </div><div><br /></div><div>The new Apple clause helps ensure that modern iPhone OS developers don't have that option of a cross platform dev kit. Well, specifically they don't have the option of using a higher level, generic dev kit that then targets multiple platforms. We have to yet wait and see if someone decided to create something that will lets an iPhone OS source base in Obj-C compile and deploy against another platform. It could happen.</div><div><br /></div><div>All of these limitation buy Apple time. The mobile space is very hot now, Android and Microsoft are very credible. Apple WILL, in time, "lose" this war, much like Microsoft is "losing" war today with the rise of popularity of Linux and Macintosh desktops. </div><div><br /></div><div>But as well all know, software development is the building of abstractions upon underlying foundations. This process gives code and development a momentum. A project once started on a specific development stack can be difficult to turn.</div><div><br /></div><div>Apple has the market presence and momentum right now attracting developers. Developers are expensive to collect, so Apple is taking this opportunity to make the attractiveness of the iPhone platform a faustian bargain and building even more momentum for the platform. Doing this will help ensure, for the time being, that the iPhone OS will get the apps, and get them first.</div><div><br /></div><div><br /></div>Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0tag:blogger.com,1999:blog-718182728807834244.post-50889774537949769652009-04-16T22:30:00.000-07:002009-04-16T22:36:46.631-07:00Google broke Java -- Boo Hoo!Seems to be a lot of teeth gnashing over Googles incomplete Java support in their new Java Google App Engine.<br /><br />Talk about looking a gift horse in the mouth.<div><br /></div><div>This new limited JGAE environment single handedly advanced the Java Online presence farther than anyone, including Sun, ESPECIALLY Sun, could have.</div><div><br /></div><div>Up till now, if you wanted to host a Java application, you couldn't do it cheap, much less free, without being severely hamstrung in terms of the actual environment you were forced to live. Both stability and resources were severely limited for the "cheap" plans. If you wanted to host a Java application before now, you were pretty much relegated to finding a VPS for it.</div><div><br /></div><div>VPS's are wonderful, but they're expensive, and you get the great joy of effectively being responsible for every aspect of the underlying system. You get to become admin, deployer, programmer, the whole kit. </div><div><br /></div><div>Sure, it's fun!</div><div><br /></div><div>Sorta...</div><div><br /></div><div>Well...once. Maybe. </div><div><br /></div><div>Actually...Yea. </div><div><br /></div><div>Actually it's not fun at all. Cron jobs, backups, init scripts. No thanx.</div><div><br /></div><div>Coding is better.</div><div><br /></div><div>Now, with JGAE, you get to focus pretty solely on your code. The administration is handled for you. You don't get a "machine" any more, you get a folder, on some cloud, in some unmarked, nameless data center. You don't even have to maintain the database. How cool is that?</div><div><br /></div><div>Oh, and it's also Free. Gratis. Even with the upcoming reductions in the Free quotas, you get a LOT of capacity for nothing more than a login.</div><div><br /></div><div>So, now Java has a truly cheap hosting platform which can do nothing if not accelerate the adoption of Java as a server programming language, especially for the hobbyists, hackers and other practitioners that have made PHP what it is today (for good and bad).</div><div><br /></div><div>But are you coding Java? Really? With the whitelist, and other limitations? Of course you are. Despite these limitations, there is an enormous amount of existing Java code that will run on this platform. The Java code itself won't have to change to run here, though your designs most certainly will.</div><div><br /></div><div>Python programmers certainly had to go through the same process as JGAE coders will, adapting to the new platform. Now, I don't frequent the Python community, so I don't know what kind of backlash the original GAE might have brought. No doubt, someone, somewhere, was cranky about something (it IS the Internet, after all).</div><div><br /></div><div>But, even so, the Python community doesn't have the standard base that the Java community has. I think the Java folks have a fair gripe about the whitelist, as, like it or not, the Java Library IS part of what makes Java, well, Java. But, saying that, that doesn't mean the Google couldn't have necessarily offered a similarly limited platform while still staying within the Java specification. "Sure, we have all these classes, you simply can't use them."</div><div><br /></div><div>If Google had release a fully compliant Java library, but locked it down hard using the Security policies, would the outcry be the same? Are folks really arguing pedantic nits about The Standard when a compliant, but equally restricted library could have offered the same lack of functionality?</div><div><br /></div><div>Perhaps Google simply didn't want to take the time to vet the entire library for their platform in order to get something out (it is Beta, after all, but then, so is most everything Google releases). Rather, they started with the base assumption of what they wanted to offer, a Java Servlet environment, and worked forward from there to a point when they felt they had a large enough chunk of the platform to do what they needed to pull that off.</div><div><br /></div><div>See, someone like Sun could NOT have done what Google did. The Sun way would be trying to make the whole of the Java platform workable, to keep it as "unlimited" as practical. They really have such a commitment and investment to Java that if they did what Google did, it would have hurt far more than it would have helped. It would be like hobbling your own children for expediency sake. Imagine the screams if Sun had released this rather than Google.</div><div><br /></div><div>But as for Google, Java isn't their "baby", and they can be more pragmatic. Taking what they need and tossing aside the rest, and shrug off the criticism. They're not the flag holder for the Java banners. Google isn't making a Java platform that runs Servlets, they're making a Servlet platform and all the Java they need to support that.</div><div><br /></div><div>The complaints about missing APIs will be addressed, to a point, in time. "Here's the Swing classes, but, no you can't render anything."</div><div><br /></div><div>In the meantime, though, even with the limitations, I think that the benefit of what Google offers to Java programmers, particularly new programmers, is a greater good than the damage they may cause by offering that opportunity on a limited platform.</div>Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com1tag:blogger.com,1999:blog-718182728807834244.post-34581212552828276972008-07-01T10:24:00.000-07:002008-07-01T10:30:46.307-07:00VM's getting scared?Over on <a href="http://weblogs.java.net/blog/editors/archives/2008/07/wicked_game.html">java.net</a>, they're commenting on whether Google has chosen poorly buy backing the RIA via JavaScript/CSS/DOM/HTML rather than the VM model using Java/Flash/Silverlight.<br /><br />I look at it from an opposite point of view. Originally I was going to post this as a comment on their site, but for some reason they wouldn't let me.<br /><br />But I have my OWN voice! Squeak in the wind it may be, I shall NOT BE SILENCED by whimsical corporate overlords. Or, something like that -- geez...not changing the world here.<br /><br />Anyway.<br /><br />You can argue that Google and Apple soldiering on with the web platform can be likened to those early pioneers that did the same with the Java Platform, back when it WAS slow, had platform issues, and other teething problems.<br /><br />If it weren't for the likes of GMail and other RIA browser apps, the browser makers would have less incentive to push the browser as a platform. Yet, now we see that, while not perfect, the browser as RIA runtime is viable for a large class of applications, and it's just getting better.<br /><br />Witness the improvements to the runtimes both via Adobes new JavaScript runtime, as well as Apples. Plus the new version of JS as a language. Also, we have the DOM changes with things like the better CANVAS tags to handle graphics, as well as improved SVG support.<br /><br />All of these changes are to drive the platform farther to become more flexible and more performant in order to handle more advanced applications.<br /><br />Is it perfect? No, of course not. If you want something more robust and fluid than what a browser RIA can provide today, then by all means go the VM route. But there are a lot of valid reasons to stay out of the VM.<br /><br />VMs add more overhead to an already big system. You still need the browser to launch the application, and when you load that browser, you pretty much get the entire runtime as well. Heck, you can barely launch Flash today properly without JavaScript. So now you pay for both runtimes.<br /><br />Of course, there's Apples iPhone, which supports neither Java or Flash, but it DOES have a full boat Safari implementation. So, GMail yay, Flex/FX/Silverlight nay.<br /><br />Finally, you simply have the fragmentation effect. With Flash, Java and Silverlight cutting up the developer pie, while JS/HTML remains a cohesive and reasonably standard cross platform solution.<br /><br />The number of applications that the browser runtime can support is expanding with every release of the various browsers. The momentum is for browser providers to provide a robust application environment while at the same time improving their unique UI elements for those standard browser tasks. You can not have a successful browser today that doesn't handle the large JS RIA applications.<br /><br />The browser. It's not just for surfing any more.Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0tag:blogger.com,1999:blog-718182728807834244.post-42384652352314672062008-06-27T18:45:00.000-07:002008-06-27T18:53:30.958-07:00Party like it's 1992Back when I started this whole software thing, the primary interface for users was what was known as the "smart terminal". Glass screen, keyboard, serial port with a DB 25 connector stuck in the back. They had sophisticated elements like bold, blink, and underline text as well as line graphics. Rainbow of colors: white, green, and amber. VT100's and Wyse 50's were most popular and representative of the lot, but anyone who has ever looked at a modern termcap file can see that there were hundreds of these things floating around from every manufacturer.<br /><br />While the different terminals and their capabilities were novel (I had one that had TWO, count 'em, serial ports making it easy to flip back and forth between sessions), what's more relevant at this point is the idiom of computing they represented.<br /><br />At the time, it was called time share. Monolithic computers sharing time across several different applications and users. Many were billed by the CPU time they consumed, and computer utilization was a big deal because of the cost of the main computer. Batch processing was more popular because it gave operators better control over that utilization, and ensured that the computer was used to capacity. Idle computer time is wasted computer time, and wasted computer time is unbilled computer time.<br /><br />As computers became cheaper, they became more interactive, since now it's more affordable to let a computer sit idle waiting for a user to do something next.<br /><br />The primary power, though, was that you had this large central computer that could be shared. Sally on one terminal can enter data that Bob can then see on his terminal, because all of the data was contained on the single, central computer.<br /><br />The users interacted with the system, it would think, crunch and grind, and then spit out the results on the screen. Dumb Terminals would just scroll, but Smart Terminals had addressable cursors, function keys, some even had crude form languages. You could download a simple form spec showing static text along with fields that can be entered by the user. The computer sends the codes, the terminal paints the form, the user interacts, locally, with the form, then ships back the whole kit with a single SEND key. This differs from how many folks today are used to interacting with terminals, especially if they're only used to something like vi on the Linux command line. Send a key and the computer responds directly.<br /><br />Now, this was all late 80's and early 90's. During that time, the world shifted a bit with the introduction of the PC on a wide spread basis. Now folks were using PCs for personal work, and maybe running "Green Screen" apps through a terminal emulator.<br /><br />It didn't take long for people to want to leverage those PCs for shared work, and with the aid of networking and database servers, the era of Client Server Applications was born. Large applications, locally installed and running on individual computers while the central computer was delegated to serving up data from its database. Visual Basic, Power Builder, and a plethora of other Client Server "4GLs" took the market by storm, and every back office application coder was pointing and clicking their way to GUI glory.<br /><br />Of course C/S programming is still with us today, "fat apps" we call them now. The 4GLs have kind of lost their luster. Make no mistake, there are a zillion lines of VB and Java being written today for back office applications, but the more specialized tools are no longer as popular as they once were. The general purpose tools seem to be doing the job nicely.<br /><br />However, the Buzz of application development hasn't been with the Fat C/S app. Fat apps have all sorts of deployment, compatibility, resource, and portability issues. Having to roll an update of a C/S application out to 1000 users is a headache for everyone involved.<br /><br />No, today it's the web. Everything on the web. Universal access, pretty GUIs, fast deployments, centralized control. We all know how the web works, right?<br /><br />Sure. The computer sends the codes, the browser paints the form, the user interacts, locally, with the form, then ships back the whole kit with a single SUBMIT key.<br /><br />Where have we heard that before? Central computer, bunch of "smart clients". Of course we use TCP/IP today instead of RS-232, and the clients are much more interesting. The browser is vastly more capable and offers higher bandwidth interfaces than a Green Screen ever could. But, the principle is pretty much the same. Everything on the central computer, even if the "central computer" is now several computer and a bunch of networking gear.<br /><br />If you've been paying attention, you may have noticed over the past couple of years the the browser is getting much, much smarter.<br /><br />It's not that this is new, it's been happening for quite some time. More and more Web Applications are pushing more and more logic down in to the browser. AJAX is the buzzword, and GMail is the poster child.<br /><br />The JavaScript engines within the browsers, along with other resources, are going to change how you as an application developer are going to develop your back office applications. Not today, not this second, but it's always good to look ahead and down the road.<br /><br />First, we have good old Microsoft. Who'd have thought the thing that threatens Microsoft the most comes from with Microsoft Labs itself. Yes, this is all their fault.<br /><br />Microsoft, in their brilliance and genius gave the world the ubiquitous "XHR", the XmlHttpRequest. XmlHttpRequest is the little nugget of logic that enables browsers to easily talk back to the server through some mechanism other than the user click a link or a submit button. There were other "hacks" that offered similar abilities, but they were, well, hacks. Ungainly and difficult to use. But XmlHttpRequest, that's easy.<br /><br />From the introduction of XHR, we get the rise of the AJAX libraries. Things like prototype, and jQuery. JavaScript libraries that, mostly, give ready access to the HTML DOM within the browser, but also provide ready access to servers via XHR. There's a lot you can do with JavaScript and doing DOM tricks, and pretty animations, and what not. But it gets a lot more interesting when you can talk to a server as a dynamic data source. So, while DOM wrangling was fun and flashy for menus and what not, XHR is why more folks are interested in it today than before.<br /><br />These first generation JS libraries provide a foundation that folks can start to build upon. They basically open up the primitives and elements used to construct browser pages. And once you open that up, folks, being programmers, are going to want to make that easier to use.<br /><br />Enter the next generation. JavaScript Component Libraries. Dojo, YUI, ExtJS. From primitive DOM and node shuffling to high level widgets. Widgets that start to work across the different browsers (cross browser compatibility always bringing tears of joy to any coder who has had to deal with it...well, tears at least).<br /><br />With a Widget Library, you start getting in to the world that Windows and Mac OS coders started with. You end up with a clean slate of a page, an event model of some kind to handle the keyboard and mouse, and high level widgets that you can place at will upon that clean slate, to do a lot of the heavy lifting. On top of that, you have simple network connectivity.<br /><br />This is where we were as an industry in the late 80's and early 90's. This kind of technology was becoming cheap, available, and commonplace.<br /><br />And what did we get when this happened in the 90s? The 4GLs. VB, Power Builder, etc. Higher level language systems that made combining widgets and data together easier for more mundane users.<br /><br />That's the 3rd generation for the browser. That's where we are today. On the one hand, you have the server centric component frameworks, like JSF, .NET, Wicket, etc. Really, these aren't yet quite as rich as what the modern browser can provide. They have "AJAX Components", but in truth the developers are still coding up forms with dynamic bits that use JavaScript rather than JavaScript Applications that run essentially purely in the browser.<br /><br />There's GWT, a clever system that lets you write your client code in Java and download it in to a browser to run, after the toolkit compiles the Java in to JavaScript. Here, you can create "fat" JavaScript applications.<br /><br />But, also, we have the recent announcements of Apples work with SproutCore, as well as the 280 North folks with their "Objective-J". These are not simply widget frameworks. They're entire programming systems where the premise is that the browser is the runtime environment, while the server is simply there for data services. Classic Client/Server computing ca 1992.<br /><br />Of course today, the server protocol is different. Back then we were shoving SQL up and getting data back. Today, nobody in their right mind is pushing back SQL (well, somebody is, but there's that "right mind" qualifier). Rather they're talking some kind of higher level web service API (REST, SOAP, POX, JSON, not really important what). Today we have App servers that are more powerful, complicated, and robust than DBMSs and Stored Procedures.<br /><br />Take note of the work of Apple and Mozilla with their efforts to speed up and improve JavaScript. Because like it or not, JavaScript is becoming the lingua franca of the modern "Fat App". The language is getting better, meeting the desires of the dynamic language wonks, as well as the "programming in the large" folks with better modularization, giving us more flexibility and expressibility. JavaScript is also getting faster, and the modern browsers are gearing up to be able to handle downloading 1MB of JS source code, compile it, and execute it efficiently, and for a long period of time (which means fast code, good garbage collectors, etc.).<br /><br />You'll note that this work isn't in the area of Flash or Silverlight. Programming Flash or Silverlight is no different than programming Java Applets. You create some compiled application that's downloaded to an installed runtime on the clients computer. By promoting JavaScript, and the HTML DOM, even though more effort is being made to hide that from the day to day coder, Apple and Mozilla are promoting more open standards. IE, FireFox, Opera, Safari, four different JS and HTML "runtimes", not to mention the bazillion phones and other implementations.<br /><br />Of course, once you start doing all of your client logic in JavaScript, it won't take long for folks to want to do the same thing on the server side. Why learn two languages when one is powerful and expressive enough for most everything you would want to do?<br /><br />With the rise of client side JavaScript, I think we'll see a rise of server side JavaScript as well. It will be slower. Hard to fight the tide of PHP and Java, but, at least in Java's case, JavaScript runs fine on Java. So, it's not difficult start using JS for server side logic. Heck, the old Netscape web server offered server side JS 10 years ago, I don't know if the Sun Web server maintains it any more or not (SWS is the NS heir). Running JS via CGI with Spidermonkey is trivial right now as well, but I doubt you'll find many $5/month hosts with a handy Spidermonkey install.<br /><br />So, no, not quite prime time yet..but soon. Soon.<br /><br />Of course, maybe not. Perhaps will end up being delegated as a runtime language for the GWTs and Objective-J's of the world.<br /><br />The biggest impact will be to the web designers. Static web pages won't be going away any time soon, but more and more web designers are going to have to become programmers. They won't like it. Web Design != Programming, different mindsets, different skill sets.<br /><br />Anyway, get your party hat on and get ready to welcome back the "Fat App". Oh, and perhaps polish up on your JavaScript if you think you'd like to play in this arena. Yes, you too you server side folks.Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0tag:blogger.com,1999:blog-718182728807834244.post-67261434738880018852008-06-05T08:34:00.000-07:002008-06-05T10:24:13.452-07:00Jave the next GAE language? That's probably half right.Chris Herron pointed me to the article where <a href="http://blog.symbiont.net/2008/05/java-next-app-engine-language.html">Michael Podrazik</a> suggests that Java will be the next language for the Google App Engine runtime.<br /><br />I think he's half right.<br /><br />By that I think if there's any Java in the next GAE language, it will be JavaScript.<br /><br />Why is that?<br /><br />It's pretty clear that Google has a lot of experience in house with JavaScript. The GWT runtime is entirely in JavaScript. They have their own XSLT processor in JavaScript (for browsers that don't support XSLT natively). Also, they have their <a href="http://www.infoq.com/news/2007/06/yegge-rhino-on-rails">Rhino on Rails</a> project, which is a Ruby on Rails port to JavaScript.<br /><br />Next, JavaScript fits nicely in to the existing GAE infrastructure. It can be run just like Python is now. Also, there are several OSS JavaScript interpreters available to be used, of varying quality. The new runtime for FireFox 3 based on Adobes ActionScript is one, also the recently announced SquirrelFish runtime from WebKit could be used.<br /><br />The GAE API would fit well in to a JavaScript world, with less "square peg round hole" work that using Java would entail.<br /><br />JavaScript, with its push to JavaScript 2.0 is rapidly growing up. It's always been an elegant language with its prototype inheritance scheme (some would argue it's a blight on the planet, but that's more a paradigm complaint I think). The 2.0 changes will make it a bit more mainstream, make it faster, and even more powerful. So JavaScript is powerful today, but getting even moreso. The tooling surrounding it is getting better as well.<br /><br />Finally, there are a bazillion web developers who are becoming, whether they like it or not, conversational in JavaScript. Before there was a clean separation between the client side and server side developers. Client side did HTML and CSS, while server side did scripting and logic.<br /><br />But with the modern browsers having powerful JavaScript engines, and UI demands requiring fancier client side scripting for effects etc., not to mention Ajax, the client side developer has had the world of scripting and programming logic thrust upon them.<br /><br />Some take to it well and become adept at leveraging JavaScript and its powers. Others simply cut and paste their way to success using the multitude of examples on the web. Either way, whether novice or expert, the client side developer is learning the fundamentals of programming and the nuances of the runtime through JavaScript.<br /><br />If the client side developer were able to leverage that JavaScript knowledge on the server side, that empowers them even more.<br /><br />JavaScript has had a mixed history on the server side. Netscapes server has supported server side JavaScript since forever, but obviously when someone thinks about the server, JavaScript is far from their mind. It has almost no mindshare.<br /><br />Yet, we have, for example, the <a href="https://phobos.dev.java.net/">Phobos</a> project which is a JavaScript back end, as well as the previously mentioned Rhino on Rails internal Google project. These are recent, though, without a lot of public history.<br /><br />Now, to be fair, these are both Java systems operating as the host for a JavaScript based system. But there's no reason they have to be Java. The major browsers certainly don't use a Java runtime for their JavaScript systems, they use a C/C++ implementation.<br /><br />With a C/C++ implementation, Google could readily launch a JavaScript runtime for their GAE that would fit quite well with their current infrastructure. Also, since there's very little momentum on the JavaScript server side, there's no real competition. No "why can't it operate like Project X". This gives Google even more freedom in terms of shaping the runtime the way they think it should be done.<br /><br />So, I think that if there is any Java in GAE future, the near term will be in name only, with JavaScript.<br /><br />You heard it here first.Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0tag:blogger.com,1999:blog-718182728807834244.post-45569299672586852342008-04-14T07:33:00.000-07:002008-04-14T08:54:12.454-07:00EC2 Persistent Storage -- It's a crutch.You must understand, I live locked in a small box, and I'm aloud only this keyboard, a 9" B&W monitor, and a mailbox that only a single person knows about. Thankfully, that person is Chris Herron, and he keeps sending me intersting things.<br /><br />Specifically, a recent blog post about Amazons new <a href="http://aws.typepad.com/aws/2008/04/block-to-the-fu.html">Persistent Storage</a> service for EC2.<br /><br />What it does is make high bandwidth, high granularity, permanent storage available to EC2 nodes.<br /><br />One of the characteristics of EC2 is that your instance lives on a normal, everyday Intel machine with CPU, memory, and hard drive. (Actually this is most likely a VM running someplace, not a physical machine instance, but you never know.) But the model of the service is that while all of those capabilities are available to you, and the hard drive is indeed simply a hard drive, the machine that all is contained in can up and vanish at any time.<br /><br />One minute everything is running along hunky dory, and the next your machine is dead.<br /><br />Now most folks who do most simple things, rarely lose an entire machine. They might lose access to the machine, like the network going down. They might lose power to the machine. Or, an actual component on the machine may up and fail. But in all of these cases, for most scenarios, when the problem is resolved, the machine comes back to life effectively in the state it was in before the event. A long reboot perhaps. Barring loss of the actual hard drive, these failures, while clearly affecting the availability of the machine (can't use it when you're having these problems), don't really affect the integrity of the maching. A hard drive failure is typically the worst simple failure a machine can have, and simply adding a duplicate drive and mirroring it (which every modern OS can do today) can help protect from that.<br /><br />The difference with EC2 is that should anything occur to your "machine" in EC2, you lose the hard drive. "Anything" means literally that, anything. And there are a lot more "anythings" within EC2 than a classic hosting environment. Specifically since they don't promise your machine will be up for any particular length of time, you can pretty much be assured that it won't be. And truth is, it doesn't matter what that length of time is, whether it's one day, one week, one month or one year. Whenever the machine goes down, you effectively "lose all your work".<br /><br />Anyone who has worked in a word processor for several hours only to have the machine restart on you can share in the joy of what it's like to lose "unsaved work". And that is what any data written to the hard drive of an EC2 instance is -- unsaved work. Work that has the lifespan of the machine. Please raise your and if you'd like a years worth of sales, order history, and customer posted reviews to vanish in a heart beat. Anyone? No, of course not.<br /><br />Amazons original solution was <a href="http://aws.amazon.com/s3">S3</a>, their Simple Storage Service. This is a very coarse service, basically working at the level of not just a single file, but even to the point that you can only replace the entire file rather than update a section of it. You only have simple, streaming read and write functons.<br /><br />Next, came <a href="http://www.amazon.com/SimpleDB-AWS-Service-Pricing/b/ref=sc_fe_l_2?ie=UTF8&node=342335011&no=3440661&me=A36L942TSJ2AJA">SimpleDB</a>, which Amazon offers as the next level of granularity. This allows small collections of attributes to be accessed individually. You can query, add, and delete the collections. Much better than S3, but it has it's own issues. Specifically it's "eventual consistency" model. I bet most folks don't enjoy this characteristic of SimpleDB.<br /><br />The new Peristent Storage service is what everyone has been looking for. Now they can go back to their old model of how computer systems are supposed to work, and they can host a RDBMS just like before. There was nothing stopping folks from running an RDBMS on any of the EC2 instances before, save that nagging "unsaved work" detail. Lose the instance, lose the RDBMS.<br /><br />I can see why folks have been clamoring for this service, but frankly, I see it as a step backward from the basic tenet that Amazon allows folks to readily build scalable applications.<br /><br />As noted in earlier, today the most common bottleneck in most scalable systems IS the RDBMS. RDBMS do not easily scale like most other parts of an application. It's the reality of the distributed application problem. And Amazons approach to addressing the problem with SimpleDB is I think admirable.<br /><br />It's not the solution people want, however. They WANT a scalable RDBMS, and SimpleDB simply is not that beast. But scalable RDBMS's are very, very difficult. All of theses kinds of systems have shortcomings that folks need to work around, and an RDBMS is no different. Amazingly, the shortcomings of distributed RDBMS are much like what SimpleDB offers in terms of "eventual consistency", but the RDBMS will struggle to hide that synchronizing process, like Google's Datastore does.<br /><br />In the end, SimpleDB is designed the way it is, and is NOT an RDBMS, for a reason, and that's in order to remain performant, and scalable while working on a massive parallel infrastructure. I am fully confident that you can not "Slashdot" SimpleDB. This is going to be one difficult beast to take down. However, the price of that resiliency is it's simplicity and it's "eventual consistency" model.<br /><br />There's a purity of thought when your tools limit you. One of the greatest strengths, and greatest curses in the Java world are the apparently unlimited number of web frameworks and such available to developers. As a developer when you run in to some shortcoming or issue with one framework, it's easy and tempting, especially early on, to let the eye wander and try some other framework to find that magic bullet that will solve your problem and work the way you work.<br /><br />But it can also be very distracting. If you're not careful, you find you spend all your time evaluating frameworks rather than actually getting Real Work done.<br /><br />Now, if you were, say, an ASP.NET programmer, you wouldn't be wandering the streets looking for another solution. You'd simply make ASP.NET work. For various reasons, there are NOT a lot of web frameworks in common use on the .NET world. There, ASP.NET is the hammer of choice so as a developer you use it to solve your problems.<br /><br />Similarly, if SimpleDB were your only persistence choice, with all of its issues, then you as a developer would figure out clever ways to overcome its limitations and develop your applications, simply because you really had no alternative.<br /><br />With the new attached Persistent Storage, folks will take a new look at SimpleDB. Some will still embrace it. Some will realize that, truly, it is the only data solution they should be using if they want a scalable solution. But others will go "you know, maybe I don't need that much scalability". SimpleDB is such a pain to work with compared to the warm, snuggly comfort of familiarity that an RDBMS is, folks will up and abandon SimpleDB.<br /><br />With that assertion, they'll be back to running their standard applicaton designs for their limited domains. To be fair, the big benefit of the new storage is that generic, everyday applications can be ported to the EC2 infrastructure with mostly no changes.<br /><br />The downside is that these applications won't scale, as they won't embrace the architecture elements that Amazon offers to enable their applications to scale.<br /><br />I think the RDBMS option that folks are going to be giddy about is a false hope.<br /><br />As I mentioned before, RDBMS's are typically, and most easily, scaled in a vertical fashion. In most any data center, the DB machine is the largest, and most powerful. If there's a machine in the datacenter with multiple, redundant networks, power supplies, hard drives, cpus, etc. If there is any single machine that's designed to survive a common component failure, and continue running, it's the DB machine.<br /><br />For example, ten web machines talking to a single DB machine. Any one of those web machines can fail and the system "works". Kill the DB machine, and the rest become room heaters.<br /><br />The crux here, tho, is all of those machines in the EC2 cloud are basically like those web machines. Cheap, plentiful, and unreliable. The beauty of having easy access to lots of machines is the ability to lose them and still run. However, if you plan on running a DB on one of these, just be aware that it's just as fragile and unreliable as the rest. This machine WON'T have all the redundant features and such. It can come and go as quickly as the rest.<br /><br />But, being THE DB machine, means that's not what you want. Lose a web server, eh, big deal. Lose the DB, BIG DEAL, the site is down and the phones are ringing.<br /><br />Also, you're limited to the vertical scaling ability of their instances. Amazon offers larger nodes for hosting, more cpus, etc. You can vertically scale to a point with Amazon. But once you hit that boundary, you're stuck.<br /><br />In Amazon land, if you want a long term, reliable, and performant granular data storage, then you should be looking at SimpleDB, not the Persistent Storage. I think that if you want to build a scalable system on Amazon, you should work around the SimpleDB offering. The best use for the Persistent Storage and an RDBMS would be for things like a decision support database, something that is more powerful when it works with off the shelf tools (like ODBC) and that doesn't have the scaling needs of the normal application.<br /><br />So, don't let the Peristent Storage offering fool you and distract you from the the real problems if you want a scalable system.Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com2tag:blogger.com,1999:blog-718182728807834244.post-13018547329444010582008-04-11T11:01:00.000-07:002008-04-11T15:28:03.421-07:00GAE - Java?At TheServerSide, there is an <a href="http://www.theserverside.com/news/thread.tss?thread_id=49016">article</a> about "Java is losing the battle for the modern web." It's chock full of bits and particles, at least indirectly, about issues with hosting web applications.<br /><br />That's what GAE does. It hosts web applications. Currently, it hosts Python applications, but it can most likely host most anything, once they get a solid API for talking to the Datastore written for the environment.<br /><br />Well, I should qualify that.<br /><br />It can host most anything that works well with the idiom of "start process, handled request, stop process". As I mentioned before, GAE is running the CGI model of web application. This is counter to how Java applications run, however.<br /><br />Java promotes executing virtual, deployable modules within a long running server process, typically a Java Servlet container. Most containers have mechanisms to support the loading, unloading, and reloading of these deployable modules. You can readily support several different web applications within a single Java Servlet container. As a platform, it's actually quite nice.<br /><br />Java itself also promotes this kind of system. Java relies on long running processes to improve performance. Specifically, Java relies on "Just In Time" (JIT) compilers to translate JVM bytecode in to native code. The magic of the JIT compiler is that it can observe the behavior of some Java code, and dynamically compile only the parts the JIT compiler feels are worthy of being compiled.<br /><br />For example, say you have a class that has some non trivial initialization code that runs when an instance is constructed, but it also has some compute intensive methods. If you only create one instance of that class, and execute the compute intensive methods, the JIT will convert those methods in to native code, but will most likely not convert the logic in the constructor. It only runs once and isn't worth the expense of converting in order to make it run faster.<br /><br />So, Java is a kind of system that gets faster the longer it's run. As the JIT observes things, and gets some idle time, it will over time, and incrementally make the system faster via its compiler. Over time, more and more of the system is converted in to native code. And, it so happens, very good native code.<br /><br />The issue, however, is that in the case of something like GAE, a system such as Java is almost at complete odds with the environment that GAE promotes. GAE wants short processes, and lots of them, rather than large, single, long running processes.<br /><br />So is Java completely out of the picture for something like GAE?<br /><br />Actually, no I don't think so.<br /><br />Just because Java LIKES long running processes, doesn't mean it's unusable without them. For example, the bulk of the Java community uses the Ant tool to build their projects. That's a perfect example of a commonly used, short term process in Java. Even javac is a Java program.<br /><br />Java is perfectly usable in a short term scenario. Java could readily be used for CGI programs. What CAN'T (at least now) be used for CGI programs are typical Java web applications. They're just not written for the CGI environment. They rely on long running processes: in memory sessions, cached configuration information, Singleton variables. You most certainly wouldn't do something silly like launch Tomcat to process a single server request. That's just plain insane.<br /><br />As a rule, Java tends to be "more expensive" to start than something like Perl or PHP. The primary reason is that most of Java is written in Java. Specifically the class library. So, in order to Do Anything, you need to load the JVM, and then start loading classes. Java loads over 280 classes just to print "Hello World" (mind these 280 classes come for only 3 files). All of that loading has some measure of overhead. I well imagine that the code path between process start, and "Hello World" is longer in Java than in, say, Perl. That code path is startup time.<br /><br />Of course, in modern web applications, startup time is almost irrelevant. Why? Because almost everyone embeds the scripting language in to the web server. That's what mod_perl and mod_php do. They make the actual language interpreter and runtime 1st class citizens of the web server process. This is in distinction to starting a new process, loading the interpreter, loading and executing your code, and then quitting. Apache will pay the interpreter startup cost just once, when Apache starts. There may be some connection oriented initialization when Apache forks a new process to handle a connection, but those connection processes are long lived as well.<br /><br />So, it turns out, when you're running your language interpreter within the web server, startup time is pretty much factored out of the equation. Unless it's unrealistically long, startup time is a non-issue with embedded runtimes.<br /><br />Which brings the question "Where is mod_java?" Why not embed Java? And that's a good question. I know it's been discussed in the past, but I don't know if there's reasonable implementation of embedding the JVM within an Apache process.<br /><br />What does mod_java need to do? The best case scenario would be for an embedded JVM to start up with the host Apache process. The JVM would then load in client classes on request, execute them, and return the result. The last thing the JVM would do is toss aside all of the code it just loaded. It would do that via a special ClassLoader responsible for loading everything outside of the core JVM configuration. This helps the JVM stay reasonably tidy from run to run.<br /><br />The cool thing about this, is that the code that this JVM runs could readily use the Servlet API as its interface. The Servlet API has the concept of initializing Servlets, executing requests, and unloading Servlets. It also has the concept of persistent sessions that last from request to request. Obviously, most containers are long running, so those lifecycle methods are rarely invoked. Also, most folks consider sessions to be "in memory". Applications would need to adapt their behavior to assume that these lifecycle methods are called all the time, and that your sessions are going to be written to and read from persistent storage every single request. So, you'd want web applications that have fast servlet initialization times and that store little session data.<br /><br />But those applications can still live under the purview of the standard Java Servlet API.<br /><br />That means that you could have mod_java, and CGI style web apps, with JSPs and everything.<br /><br />Most of the standard web frameworks would be out the window, most have long startup and configuration times. But if the idiom becomes popular, no doubt some CGI friendly frameworks would pop up, changing the dynamic of that one time configuration, perhaps being more lazy loading about it.<br /><br />But would this kind of system perform?<br /><br />Sure it would. In fact, it would likely perform better (in terms of pure application or script execution) than things like Perl or PHP. Why? Because Perl and PHP have to load and parse the script text every single request. Java just has to load bytecodes. Python has a similar pre-parsed form that can speed loading as well.<br /><br />In this way, it turns out you can run Java safely, within a process model, you can run it quickly (though most likely not as quick as a long running process), you get to use all of the bazillion lines of off the shelf library code, and even still use the fundamental Servlet API as well.<br /><br />Things like Hibernate, EJB, and most of the web frameworks would not apply however, so it will be a different model of Java development. But it IS Java, and all of the advantages therein.<br /><br />And if you want to instead run JRuby, Jython, Javascript, Groovy, or any other Java based scripting langauge, knock yourself out. In that case, it would be best to have the mod_java perform some preload of those systems when Apache starts up, so they can be better ready to support scripting requests at request time with little spin up.<br /><br />You would also have to limit the CGI Java processes from running things like threads, I would think. The goal is for the JVM to remain pristine after each request.<br /><br />Google could readily incorporate such a "mod_java" into the GAE and make Java available to users. They can do this without having to reengineer the JVM.<br /><br />There is one JVM change that would make this mod_java that much better, and that's the capability for the JVM to both grow dynamically in memory, and also free memory up back to the OS. I know JRockit can dynamically grow, I do not know if it can dynamically shrink.<br /><br />If the JVM could do that, then there's no reason for the "cheap hosts" to not provide this style of Java capability on their servers, as hosting Java becomes little different than hosting PHP.<br /><br />And wouldn't that be exciting?Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0tag:blogger.com,1999:blog-718182728807834244.post-10661888765649916012008-04-10T07:41:00.000-07:002008-04-11T08:58:22.992-07:00Contrasting SimpleDB and GAE DatastorePart and parcel to the infrastructures that Amazon and Google are promoting are their internal persistence systems.<br /><br />Let's talk scaling for just a sec here. There are two basic ways that applications can be scaled. Horizontal scaling, and Vertical scaling.<br /><br />Horizontal scaling is spreading the application across several machines and using various load balancing techniques to spread application traffic across the different machines. If horizontal scaling is appropriate for your application, then if you want to support twice as much load, you can add twice as many machines.<br /><br />Vertical scaling is using a bigger box to process the load. Here, you have only one instance of the application running, but it's running on a box with more CPUs, more memory, more whatever was limiting you before. Today, a simple example would be moving from a single CPU machine to a dual CPU machine. Ideally the dual CPU machine will double your performance. (It won't for a lot reasons, but it can be close.)<br /><br />Websites, especially static websites, are particularly well suited to horizontal deployments. If you've ever downloaded anything off the web where they either asked you to select a "mirror", or even automatically select one for you, you can see this process in action. You don't care WHICH machine you hit as long as it has what you're looking for. Mirroring of information isn't "transparent" to the user, but it's still a useful technique. There are other techniques that can make such mirroring or load balancing transparent to the user (for example, we all know that there is not a single machine servicing "www.google.com", but it all looks the same to us as consumers).<br /><br />Vertical scaling tends to work well with conventional databases. In fact, vertical scaling works well for any application that relies upon locally stored information. Of course, in essence, that's all that a database is. But databases offer a capability that most applications rely upon, and that's a consistency of the view of data that the database contains. Most applications enjoy the fact that if you change the value of a piece of data, when you read that data back it will have the changed value. And, as important, other applications that view that data will see the changed data as well. It's a handy feature to have. And with a single machine hosting the database, it's easy to acheive. But that consistency can really hamper scaling of the database, as they're limited by machine size.<br /><br />Lets look at a contrived example. Say you have a single database instance, and two applications talking to it. It seems pretty straightforward that when App A makes a change in to the DB, App B would see it as well. Same data, same machine, etc. Simple. But you can also imagine that as you start adding more and more applications talking to that database instance, that eventually it's simply going to run out of capacity to service them all. There will simply not be enough CPU cycles to meet the request.<br /><br />You can see that if the applications are web applications, as you horizontally scale the web instance, you add pressure to your database instance.<br /><br />That's not really a bad thing, there are a lot of large machines that run large databases. But those large machines are expensive. You can buy a 1U machine with a CPU in it for less than a $1000. You can buy 25 such machines for less that $25000. But you can't buy a single machine with 25 CPUs for $25000. They're a lot more. If you want to run on cheap hardware, then you need go horizontal.<br /><br />So, why not add more database instances?<br /><br />Aye, there's the rub. Lets add another database instance. App A talks to DB A, and App B talks to DB B. A user hits App A, and changes their name, and App A sends the update to DB A. But, now that users data doesn't match on DB B, it has the old data (stale data as it were). How does DB B get synchronized with DB A? And, as important, WHEN does it get synchronized? And what if you have instead of just two instances, you have 25 instances?<br /><br />THAT is the $64 question. It turns out it's a Hard Problem. Big brainy types have been noodling this problem for a long time.<br /><br />So, for many applications, the database tends to be the focal point of the scalability problem. Designers and engineers have worked out all sorts of mechanisms to get around the problem of keeping disparate sets of information synchronized.<br /><br />Now, Amazon and Google are renting out their infrastructure with the goal of providing "instant" scalability. They've solved the horizontal scaling problem, they have a bazillion machines, Amazon will let you deploy to as many as you want, while Google hides that problem from you completely.<br /><br />But how do they handle the data problem? How do they "fix" that bottleneck? Just because someone can quickly give you a hundred machines doesn't necessarily make solving the scalability issue easier. There's a bunch of hosts out there that will deploy a hundred servers for you.<br /><br />Google and Amazon, however, offer their own data services to help take on this problem, and they're both unconventional for those who have been working with the ubiquitous Relational Database Systems of the past 30 years.<br /><br />Both are similar in that they're flexible in their structure, and have custom query languages (i.e. not SQL).<br /><br />Googles datastore is exposed to the Python programmer by tightly integrating the persistence layer with the Python object model. It's also feature rich in terms of offering different data types, allowing rows to have relationships to each other, etc. Google limits how you can query the data with predefined indexes. You as the developer can define your indexes however your want, but you will be limited to query your data via those indexes. There's no real "ad hoc" query capability supported by the datastore. Also, the Google datastore in transactional in that you can send several changes to the datastore at once, and they wil either all occur "at once", or none of them will occur.<br /><br />Amazon's SimpleDB is more crude. Each database entry is a bag of multivalued attributes, all of which need to be string data. You as a developer are burdened with converting, say, numbers from string data in to internal forms for processing, then converting them back in to string values for storing. Also, Amazon doesn't allow any relationships among its data. Any relationships you want to make must be done in the application. Finally, SimpleDB is not a transactional system. There seems to be a promise that once the system accepts your change, it will commit the change, but you can't make several changes over time and consider them as a whole.<br /><br />Finally. there's one other crucial advertised difference between Amazon's and Google's systems. SimpleDB is designed to scale, and exposes that design to the developer. Google's is also, but it offers a different promise to the user.<br /><br />See, Google appears to be promising consistency across the database. That's all well and good, but as you load down the database, that maintenance has costs. SimpleDB, on the other hand, and interestingly enough, does NOT guarantee consistency. Well, at least not immediately.<br /><br />For example, read data from the database, say that user record with the user name in it. You can update the data with the new name, and write it back to the database. If you then immediately read it back, you may well get the OLD record with the OLD name. In the example above, you just updated DB A, and read back the data from DB B.<br /><br />Amazon guarantees that "eventually", your data will be consistent. Most likely in a few seconds.<br /><br />Now, Google doesn't stipulate that limitation. The API says "update your data and the transaction commits or it doesn't". That implies when you write the data, it's going to be there when you read it back, that your new data will immediately be available.<br /><br />Now, Amazon, by punting on the integrity and consistency guarantee, they are pushing some of the complexity of managing a distributed application back on to the developer.<br /><br />In truth this is not such a bad thing. By exposing this capabaility, this limitation, you are forced as a developer to understand the ramifications of having "data in flight" so to speak, knowing that when you look at the datastore, it may be just a wee bit out of date. This capability will definately turn your application design sideways.<br /><br />In return though, you will have a scalable system, and know how it scales. Building applications around unreliable data on unreliable machines is what distributed computing is all about. That's why it's SO HARD. Two of the great fallacies of network computing is that the network is cheap and reliable, when in fact it's neither. Yet many application developers consider the network as safe, because many idioms make the pain of the network transparent to them, giving the illusion of safety.<br /><br />Amazons SimpleDB doesn't. They basically guarantee "If you give us some data, we'll keep it safe and eventually you can get it back". That's it. If that "eventually" number is lower than the times between queries, then all looks good. But being aware that there IS a window of potential inconsistency is a key factor in application design.<br /><br />Now, Google hides this side affect of the database implementation from you. But it does impose another limitation which is basically that your transaction must take less than 5 seconds or it will be rolled back. To be fair, both systems have time limits on database actions, but what is key to the Google promise is that they can use that time window in order to synchronize the distributed data store. The dark side of the 5 second guarantee is not that your request will fail after 5 seconds, but EVERY request can take UP TO 5 seconds to complete.<br /><br />SimpleDB could have made a similar promise, each commit must take 5 seconds, and use that 5 second window to synchronize your data store, but at the price of an expensive DB request. Instead, the return "immediately", with assurance that at some point, the data will be consistent, meanwhile you can mosey on to other things. What's nice about this is that if it takes more than 5 seconds for the data to become consistent, you as a developer are not punished for it. With Google, your request is rejected if it takes too long. With Amazon, it, well, just takes too long. Whether it take .1 seconds to get consistent or 1 minute, you as a developer have to deal with the potential discrepancy during application design.<br /><br />Have you ever posted to Slashdot? At the end, after your post, it says "your post will not appear immediately". That's effectively the same promise that Amazon is making.<br /><br />What it all boils down to is that the SimpleDB request is an asynchronous request (fire and forget, like sending an email), while the Google request is synchronous (click and wait, like loading a web page). They both do the same thing, but by exposing the call details, Amazon gives the developer a bit more flexibility along with more responsability.<br /><br />But here's the golden egg thats under this goose. Both solutions give you better options as a developer for persisting data than an off the shelf Relational Database, at least in terms of getting the application to scale. Recall that the database tends to be the bottleneck, that lone teller in the crowded bank who everyone in line is cursing.<br /><br />For large, scaled systems, both of these systems handle a very hard problem and wrap it up in a nice, teeny API that will fit on an index card, and they give it to you on the cheap.Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0tag:blogger.com,1999:blog-718182728807834244.post-48951734387787682242008-04-09T10:01:00.000-07:002008-04-09T10:53:31.011-07:00Application Deployment -- the new ModelsAs many have heard, Google has announced a new hosting service. The call it the <a href="http://code.google.com/appengine/">Google App Engine</a>.<br /><br />Over on the <a href="http://www.theserverside.com/news/thread.tss?thread_id=48994">TheServerSide</a>, they're comparing GAE and Amazons <a href="http://aws.amazon.com/ec2">EC2</a>.<br /><br />Meanwhile, recently on JavaLo^H^H^H^H^H^H<a href="http://java.dzone.com/news/hosting-java-web-applications-">DZone</a>, there was lamenting about cheap Java hosting.<br /><br />EC2 is very interesting. They managed to effectively out grid <a href="http://www.sun.com/service/sungrid/index.jsp">Suns Grid</a>, at least for most people. EC2 makes commodity computing even more commodity. It rapidly eliminates more of the scaling barriers folks have. Suns system is more geared to higher performance, short term, High CPU jobs, whereas EC2 is being used for actual hosting.<br /><br />For $72/month, you end up with a pretty reliable, persistent system with EC2. You need to structure your application to leverage the Amazon infrastructure, but the pay off is high.<br /><br />Beyond the infrastructure details, Amazon offers a pretty standard development model. The infrastructure does force some design constraints (specifically the machine you're running on can be yanked out from underneath you at a moments notice, so don't store anything Important on it), but once you tweak your dynamic persistence model, EC2 offers up a straight forward deployment environment.<br /><br />But GAE is different. GAE has turned the model upside down and has, in fact, rewound the clock back to web development circa 1996.<br /><br />Essentially, GAE promotes the Old School CGI model for web development. Specifically, it's embracing the classic old Unix Process model for web development. This is contrary to much of the work today on threaded server architectures, notably all of the work done in Apache 2, as well as the stock Java model of application development and deployment as well as the new "Comet" application architecture.<br /><br />See, threads live in a shared environment and are lighter weight in terms of CPU processing for switching between tasks. Simply put, a server can support more independent running threads than it can support independent running processes, and the time to switch between them is less. That means a threaded system can support more processes, and will have a faster response time.<br /><br />But, the cost of threads is you lose some safety. The threads all share a parent process. If one thread manages to somehow corrupt the parent process, then not only is the individual thread impacted, but so are all of the shared threads.<br /><br />You can see this in a Java server by having a single thread allocate too much memory, or consume too much CPU where the only resolution is to restart the Java process. If that server were supporting several hundred other connections, all of those are reset and interrupted.<br /><br />With a process model, each process can be readily limited by the host operating system. They can have their resources easily curtailed (amount of memory, how much disk they use, total CPU time, etc.). When a process violates it's contract with the OS, the OS kills it without a second thought. The benefit there is that your overall server is more stable, since the death of a process rarely affects other running processes.<br /><br />But if threading is more efficient, why would Google go back to the process model? Can't threads be made safe?<br /><br />Sure, threads can be made safe. If processes can be made safe, threads can be made safe. It's just a lot more work.<br /><br />However, here is the crux of the matter. Threads make more efficient use of the host CPU. That's a given. But what if CPU scarcity is not a problem? What if conserving CPU resources is no longer a driver? What if overall response time, system stability and scalability are more important than CPU efficiency?<br /><br />For Google, CPUs are "free". Granted, I imagine that Google spends more on powering and hosting CPUs than it does on payroll (I don't know, that's just a guess), but wrangling thousands of individual CPUs is a routine task at Google, and they have power to spare.<br /><br />Using that model, here's how the GAE system turns the application hosting space on its head.<br /><br />First, unlike Amazon, they're offering you an environment with a bit of disk space and some bandwidth. Your application can't serve up anything other than its own files, or anything else available over HTTP. Your application can not change it's space that it's deployed in (they have the Datastore for that). Your application has hard run time parameters place upon it.<br /><br />Also, and most importantly, your application has no promise as to WHERE it is being run. You have NO IDEA what machine any individual request will be executed upon. Every other hosting model out there is selling A Machine. GAE is selling you some CPU, somewhere, anywhere, and some bandwidth.<br /><br />All of your actual applications are running within hard processes on some server somewhere, yet all of your data is served up from dedicated, and different, static data servers. This lets Google leverage the threading model for things like static resources (where it's very good), but use the process model for your applications (which is very safe).<br /><br />What can Google do with this infrastructure? Simply put, it can scale indefinitely. Imagine a huge array of CPUs, all sharing a SAN hosting your application. Any of those CPUs can run your application. If you get one web hit, no problem. If you get Slashdotted, again, no problem. Since you're not on a single machine, your application WILL scale with demand. One machine, or a hundred machines, makes no difference.<br /><br />As always, the hardest hit part will be the data store. But I have to imagine that Google has "solved" this problem as well, to a point. Their Datastore has to be as distributed as it can be. We'll have to wait and see more about how this works out.<br /><br />Where does Java fit in this? Well, it doesn't. Unless you want to run CGI apps. Java web apps are basically long running processes, and those simply don't exist on the Google infrastructure.<br /><br />Exciting times. I fully expect to see startups, OSS Frameworks, and other papers written up on this infrastructure so it can be duplicated. There's no reason folks can not clone the GAE (or even Amazon) network apis and host this kind of infrastructure in house. Long term, there will be no "vendor lock in" I don't think.Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0tag:blogger.com,1999:blog-718182728807834244.post-52447328219301259382008-04-09T09:58:00.000-07:002008-04-09T10:01:11.571-07:00Welcome to my BlogSome folks have said "Hey Will, you should have a blog." For some reason, I seem to have listened to them and this is the result.<br /><br />No presumptions, no promises, we'll see where this thing goes.<br /><br />Follow along and join in if you're so inclined.Will Hartunghttp://www.blogger.com/profile/11789114586996514445noreply@blogger.com0