XPost: comp.databases.ibm-db2   
   From: markbtownsend@comcast.net   
      
   Data Goob wrote:   
      In   
   >>> Larry's   
   >>> own words they indicate the direction of the company has less to do with   
   >>> being a database company and more to do with applications.   
   >>   
   >>   
   >>   
   >> Complete and utter bullshit. You have absolutely NO basis for your   
   >> characterization, yet you make it. Why ?   
   >>   
   >   
   > It was based on experience?   
      
   Who's ?   
      
      
   >>   
   >> You obviously have no idea how the grid applies to business. Note that   
   >> one of the foremost proponents of the grid architecture is indeed Ford.   
   >>   
   >   
   > Enlighten me on the grid.  I'm getting my SETI screen-saver fired up, and   
   > turning on the Lava Lamp.  LOL.   
   >   
   Presuming that this was not a rhetorical question, the argument goes   
   something like this.   
      
   Silo's of computing are bad. Seperately configured systems for   
   individual workloads are bad - high cost, each over worked individually   
   but under utilized in terms of resources across the company. Labour   
   intensive. Difficult to integrate, make secure, make highly available.   
      
   So as an alternative, consider a grid. As follows   
      
   Consider data management software that stores not only characters   
   numbers and dates, but all your email, all your documents, all your   
   multimedia, all your spatial, all your XML. Everything digital that you   
   may care about. Not only that, but can truely do cross domain queries -   
   for example, a single query that anwsers the question - "Find me all   
   customers who previously placed but cancelled an order over the web (in   
   XML), for a product whose shipping instructions mentioned special   
   handling requirements due to fagility, where those customers are now   
   with 5 miles of the new store we are just opening"   
      
   Place this data on a storage grid based on SAN or NAS storage shared   
   amongst multiple systems, complete with intelligent software that   
   automatically manages the data placement to give maximum performance and   
   availablity for all those systems. The same data management software   
   that then automatically backs up this data, automatically allows any   
   change made in error to the data to be undo, automatically mirrors the   
   data across two or more physical storage grids for redundancy and   
   disaster recovery. Then add the ability to horizontally manage the   
   physical storage across the organization simply by adding new disks to   
   the storage grid and have the storage grid then automatically (and   
   online) maintain the most optimal data/disk layout. Do this on with any   
   disk solution, anywhere, and even with emerging low cost ATA technology.   
      
   Consider then the database grid - the machines that access the data on   
   behalf of the applications. Consider a cluster of these machines, all   
   very low cost commodity hardware, each with 2-4 cpus, intellgently   
   sharing the workload and access to this data. Have workloads be able to   
   expand across the physical boundary of a single machine. Have each   
   workload definable as a level one object in the taxonomy, and be able to   
   dynamically add or remove machines to and from a workload. Have service   
   levels definable that determine how one defined workload should be   
   failed over to other machines in event of an outage. Have service levels   
   definable that determine the required performance characteristics for   
   each workload, with the ability to react to an outage in the service by   
   adding (or removing) more machines. Do this on any hardware, with any   
   operating system.   
      
   Do the same thing at the application server grid level, but now also   
   include all the web services, BPEL and SOA good geekness that is in that   
   environment (of which I know little). Have the same service level   
   definition of a workload that is defined at the storage and database   
   level apply here as well, for end-to-end monitoring up and down the   
   stack, and eventual dynamic sharing of the machine resources between the   
   database and application server layer. Have the same definition of a   
   user up and down through the entire stack as well. Manage ALL the users   
   access, security, roles etc in one central location, with ALL other   
   software using this information consistently - 	the same Mark Townsend -   
   from the application login, to the browser cookie, to the app server   
   connection, to the JDBC connection, to the proxied user identity in the   
   database telling the system what I can and cannot access.   
      
   Then provide built in application level monitoring software that can   
   start from the end user and trace a representative transaction up and   
   down the stack - all the way from the browser across the network to the   
   app server to the Java container to the executed SQL to the the storage   
   IO. Have defined service levels for these transactions as part of the   
   workload definition. Automatically alert an administrator if the service   
   level starts to fail and provide the ability to profile where the   
   problem is from one end to another, with the ability to step into any   
   layer in the stack and diagnose the problem using wizards and advisors.   
   Do this end to end tracing from any endpoint in the network. Then have   
   the software just do this automatically for you, and simply tell you   
   what needs to be fixed, by when, and how.   
      
   Then provide configuration management software that allows you to define   
   the standard configuration for any one of these component layers, as   
   well as your best practice security, HA, performance and deployment   
   procedures. Centrally manage these configurations, and as new   
   machines/disks arrives, just blow these configurations out to them and   
   remotely build the machines. Automatically check every day with the   
   vendor to see if any urgent patches/fixes are required to YOUR specific   
   configuration. If so, have them downloaded to the central repository,   
   and have these blown out to the targets as well. Have the same software   
   then automatically checks every 24 hours to see that your best practice   
   configurations have not been bypassed.   
      
      
   Then build a suite of business application on top of this.   
      
   The grid is a little more than lava lamps and SETI screen savers. SETI   
   was all about an organization without money finding ways to borrow   
   machine cycles from other people. Good for SETI, but not going to happen   
   for Ford, Boeing etc - Ford is not going to go to GM and say "run this   
   workload for me, I can't afford to". Instead, commercial grids are   
   built, not borrowed, and the future of the grid is all about the   
   practical application of well known consolidation, commodization,   
   standardization and automation techniques to the problem of deploying IT   
   solutions more efficiently. The Grid is to IT what the Ford Model T   
   assembly line was to Manufacturing. And most importantly, you can start   
   anywhere with this. Each of the advantages is achievable in it's own   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)