For the past 5 years we have become used to saying “There’s An App For That”, referring to the hundreds of thousands of available smart-device programs that could easily be downloaded for little or no cost and run in seconds.
The word “App” was born with the smart phone and has conjured up images of “tiny” bits of code that ran on these phones or tablets and did a few interesting things, perhaps even a bit of business, but mainly these Apps were creative, social or entertainment. We have become quite comfortable with finding and installing Apps at the drop of a hat, and if we don’t like any particular one, we delete it and try one of the hundred other versions of doing the same thing. The “App” is a pedestrian friendly version of a program. An app is very hard to stub your toe on and requires little if any support or documentation.
But before the “App” appeared, the world of IT had “Applications”, which referred to something perceived as bigger and more expensive which ran on ‘real computers’. Many of these applications ran on servers running in the data center while others ran on desktop and laptop PCs. A business application could be hundreds of dollars per user, and required IT-class support to install and maintain the software and underlying hardware. Oracle was an application. Microsoft Office and Adobe Photoshop are applications too. Thousands of other titles sit in that category as well.
Enterprises run on “Applications”. Today this is still where the lion’s share of work gets done. Whereas Intel’s roadmap for years was consumed with building faster and faster CPU cores required to run these ‘real’ applications (quickly progressing from 133Mhz to 3Ghz or so), the realistic price/performance limits per core have now been reached (i.e. about 4Ghz) so elaborate schemes were devised using things like fabricating many cores per chip and load balancing technologies to create the perception of an application that could have unlimited scale based upon commercial box-level CPU technology. The application really didn’t change, it still ran on a single server, but we just deployed thousands of copies of the same server running the same application, and pulling and pushing against a shared resource pool. In a few cases, the most aggressive applications actually realized that multi-threading could be used to take advantage of these in-box multi-cores as well. It all worked quite well and this is still the most common scenario for scaled business applications today.
Now clear your mind and step back a bit. Processing in IT is all about managing resources to do computing tasks. Put enough of these tasks together and in the right sequence and desired results pop out. For nearly 50 years operating system designers have been working miracles in the efficient use of physical resources. Just look at the body of intellectual property that has created IBM’s big iron operating systems, DEC’s VMS, AT&T and BSD UNIX, Microsoft’s Servers, and Linus’ Linux. Operating system design is a highly refined set of principles that are extremely well understood today. They are truly state of the art inventions.
Now this may sound crazy, but why not employ the same extremely mature resource management principles across the entire data center? A single server is basically a box with high-speed pipes between functions like CPU cores, I/O and storage. A Data Center on the other hand is a BIGGER box, with high-speed pipes between CPU, I/O and Storage. Sound familiar?
So we know how to manage computing resources that are connected with fast pipes, and we know how to build really large structures that house computing resources connected with fast pipes. In theory, those big data center structures can have all the scale ever needed, since additional computing components can simply be pooled within the ‘box’. So why not just build APPLICATIONS that actually run on the Data Center?
Turns out you can! A bunch of people have been working on an open source project called Apache Mesos which allows applications to be written for the Data Center itself. These applications run ON the data center, not just IN it! These applications do not have to understand anything about hardware or scale or redundancy. They simply use services that are provided by any number of physical devices in the data center. The best part is that due to this extreme abstraction, additional services can be wheeled in as needed. Need more I/O? Bring more I/O and start those services which essentially pool themselves with the rest of the I/O. Need more storage or CPU? The same thing applies.
Is this magic just theory or reality? Reality! In fact you probably used a Data Center App before your second cup of coffee this morning. A growing list of applications are already using Apache Mesos to create applications architectured to run on a Data Center operating system at any scale! Most importantly, this concept becomes intuitively obvious once you are shown it. It just makes sense. Technology finally caught up to allow this, so NOW is the time to think about delivering IT services armed with solid unit-of-work level pricing which is essentially linear, and stop letting the peculiarities of complex IT structures and overhead get in the way.
To quote a famous lyric from 1986, “The Future’s is so bright, I gotta wear shades!”. (Extra credit: Can you name the band without looking it up?)