The IT Reality today and the future

The reality in IT today is that most data is read-write and most is backed up. In a large company, there can be thousands of (exact same) copies of software (data) - occupying hundreds of (energy burning) spinning hard drives (with much of it backed up on more spinning hard drives ...). There are still great opportunities to save money by gaining efficiency in this space (not to mention increased security).

So the "trick" here is to move as much data into the read-only space as possible. In order to do that, one must understand how data is used today and where there are opportunities.

The Operating System (uOS) - great for Cloud!

 Applying the Separation of Truths and Lies principle, the ultimate Operating System setup would use the maximum amount of read-only data - separated from the rest of the read-write data. On a UNIX/Linux system this would look like all subdirectories under / (root) would be read-only - with the exception of /var. The swapfile would also be read-write.

This would allow for "generic" (virtual) servers. Only one (gold master) copy of a VM or physical_iso would be needed. Sounds too good to be true? Keep reading!

The Ultimate Operating System (uOS) is the base load for the Autonomic platform. Autonomics would be too hard to accomplish with anything less. An example of something less? -Within a Windows system, there is a read-write file that is called the Registry. It controls many parts of the Window Operating System. Without being able to separate this read-write part of the OS, means that Windows can never be made truly autonomic (without millions of lines of new code - well tested?).

But what about the apps? Don't they need to make read-write changes in the OS directories? How could you make this uOS work with apps?

Application Access and Packaging

From the Ultimate Operating System, we come crashing to the ground when Apps are brought up. Truth is, Application developers have had free rein to put whatever files, wherever they wanted. The files don't HAVE to be there, but precedent is hard to move.

Applications actually start close to the separation of Truth and Lies. Most of the files in an application can be made read-only (Truths). But there is a small fraction of so-called configuration files (lies), that need to be read-write. If a lie is placed in an operating system directory, that directory becomes read-write and must now be backed up (a single lie ruining an entire area of Truth). A lie could just stay where it is in the Application directory - doing the same thing, making the directory read-write thus requiring backing up.

So the major problem we face here is where to put the configuration files (lies) so that we maximize Truth (read-only data). What are applications? Applications are tools that a particular project uses to get their work done. These applications are customized to work with this project. Therefore, the config files should be ASSOCIATED with PROJECTS and NOT the OS (or the App itself). This should also apply to any other read-write data from the application (i.e. datafiles, logfiles, etc.). The projects are the biggest liars? I always knew it . . .

So what does the "application stack"look like (from "lowest" level to top) now?

1. Base OS (read-only) with /var and swap (read-write but not backed up) = uOS
2. Corporate-specific configurations (read-only) = Golden Disk
3. Application directories (read-only) = The Universal Application Architecture (uAA)
4. Project directories (read-write and requires backup)

As you can see, by applying the separation of Truth and Lies paradigm you end up with the most efficient data architecture.

But that's not all! You only need a single (reference) copy of read-only (Truth) data. There is also no restriction for where this data is stored (i.e doesn't have to physically reside on the server that it's running on). That means you can "serve" the OS from another server (PXEboot, Boot from SAN) and you can serve Applications from an app server (NAS). So in essence, you don't need a disk drive/partition for the server you are running on (diskless servers - although the read-write directories on a server would be better served via a local hardrive).

This is where you save on disk space, enhance reliability, etc. Your applications can now reside on one (replicated) server - instead of locally installing hundreds of copies (= NISA Never Install Software Again). Developers can install an application, customize it to fit the corporation, extensively test it, and release it by "flipping a switch" (NFS map change). Not only is there a single copy of the application, it is the EXACT SAME DATA that the developers (experts) used (for months).

Once this process is complete, you can now step into the world of Autonomics.