Jamie's Blog

DRY Programming – But What About Application Provisioning???

It’s too damn hard to provision enterprise applications… but let me digress for a minute. 

Don’t Repeat Yourself is a term you hear a lot around new web development environments and platforms like Ruby on Rails and Grails. Coding by convention is another term of its ilk – if you keep doing a certain class of activity that results in the same old repeated stuff afterwards, why can’t you get a system to do it for you so you don’t have to repeat yourself all the time.   

While development tools and agile platforms embrace this concept, core runtime systems like Java and .NET are doing so as well – and that’s actually novel. Groovy (Java’s younger sibling) takes it to a whole other level. For example, why create access methods for private variables when that’s what you intend to do 9 times out of 10? Make it easy – build it into the runtime platform, not into the IDE to generate code for you.   

Even if you’re not a coder, you probably get the point.  Why repeat the same thing over and over when the “system” should make it easier to not repeat yourself. And we know there are agile runtime and development platforms being created to make building applications much simpler by adhering to the basic DRY principle. 

But guess what....Installing and provisioning traditional application platforms like WebSphere or IIS is still a really hard, error prone, and full of repeated procedures. “For every node in the cell, open up this XML file and modify such and such… rinse and repeat… start application, test it to find the problem that you just created, because you screwed up the previous steps.” 

So what about a runtime platform - can’t we make them easier to install and configure (provision)?   

The answer is “yes” and here’s how: You build a distributed runtime system that can take an application and externalized runtime settings (like all those configuration files that change in your application server) and dynamically configure plain vanilla distributions of the application servers/platforms, deploy the application, and activate the system. The key here is that a person is not allowed to actually configure an actual running instance. It’s all done through configuration and policy files stored centrally and used by the runtime system.

This is what FabricServer does, in case you were wondering…  Anyway, stay DRY!! 

Google, Salesorce.com and the Application Cloud

So Google and Saleforce.com have teamed up by integrating Google Apps with the Saleforce platform. Company spokespeople are talking about “Cloud computing for the enterprise”… I’m not sure what Enterprise they speak of… Have you ever tried using Google Apps – the calendar, spreadsheet, and presentation designer stuff? This stuff is not enterprise ready. Sure, it’s cool - and the ability to grab domain names and host simple apps is powerful for small businesses.

Now Google has their Google App Engine – with the Python API to enable you to write apps to their proprietary interface. This offering has been mentioned with the Salesforce collaboration. I have no doubt that this will be used for people to create new apps for social networking or mabye small business/productivity apps. But again, you don’t write enterprise apps with a scripting language like Python.

I do find it encouraging that people are beginning to understand and push the concept of an application cloud – an IT architecture that makes it easy to role out new apps to an efficiently managed platform – with capacity on-demand. Whether you call it utility, cloud, or grid, the idea is to simplify deploying and managing applications, while removing the requirement that applications must be dedicated to pre-configured servers.

DataSynapse is teaming up with some of the managed service providers to create true enterprise applications in the cloud…like Seibel, Informatica, WebSphere, Oracle, and Microsoft apps… not Python-based Websites. SalesForce has a motto that you might have heard before: “Software is dead”… Someone from IBM or Oracle might have something to say about that.

Putting the E in EC2

Amazon has been heavily promoting its elastic cloud computing (EC2) offering as of late.  EC2 allows you to upload an image (operating system and pre-installed applications) into the “cloud” and specify memory and CPU requirements. While the solution has some “elasticity” around memory and CPU requirements, it’s not elastic in the sense that application stacks need to have commensurate elasticity (automated horizontal scale) in order to fully leverage this offering. Just because you can have more images (think more machines), doesn’t mean your application can scale.

DataSynapse has been working with a number of customers that want us to help them create a “grid in the cloud”, where they can utilize outsourced computing on demand.  We would provide the application-aware, policy-based infrastructure layer to enable seamless horizontal scaling (or application elasticity) so that the entire stack – from OS to the business workload can scale on demand.

Here’s an example…

Let’s say company X has a new initiative to create a set of products that require a fair amount of computing in the design phase (modeling and simulation). They don’t want to buy dedicated hardware and are eager to use an outsourced compute vendor.  So they have analytics, they want to use EC2 or the equivalent… now what? You can’t take analytics libraries and put them on EC2 and expect magic to happen. You need a software infrastructure layer to provide queuing, load balancing, resilience, app provisioning, etc. into those images.

That’s where GridServer comes in. It’s scalable (elastic) on the workload/software middleware layer to enable you to change the number of images on EC2 and see commensurate improvements in performance. This way, Company X can scale its application horizontally on-demand natively on the EC2 cloud.

In a future post, I’ll discuss how application stacks like IIS, Sharepoint, BEA (WebLogic and Aqualogic), IBM WebSphere, Informatica, Oracle Apps, etc. can leverage something like EC2 using FabricServer as the elastic infrastructure component.

The $100,000,000 x86 Quad Core Server

No, this is not some tricked-out supercomputer. This is a regular commodity server... A lot of companies are buying them - and they really shouldn't be.

This 100MM server is the one that pushes you over the edge of your data center capacity limits - thus forcing you to either build a new data center or stop providing new application services. Most companies that provision data center hardware to host applications find themselves buying 100MM servers more frequently than companies that are moving to a real-time/utility operating environment.

Utility computing environments with real-time capabilities can drive efficiency and utilization to much higher levels (as much as 40%) - allowing you to do a lot more with what you have in your data center today. And these architectures aren’t just for niche Websites or HPC farms…

DataSynapse products allow you to host any server-based application or application server within a utility computing model. Using shared/pooled resources, you can quickly allocate and de-allocate existing servers to enterprise applications - on demand or based on schedule.

Why build a new data center when you can do a lot more with what you already have?

Numbers and Scale

My birthday was last week — 41 years old.   It also happens that eight years ago this month, Peter and I started DataSynapse.  So eight years later, and with about 100 large, global customers, DataSynapse software is running across more than 300,000 CPUs in production.   Some customers are running connected grids/clouds of more than 20,000 CPUs.

With those types of numbers, the concept and definition of scale is obviously important. As far as age goes, hopefully you get wiser with every year — perhaps super-linearly.  As a company, you hope that you can get more efficient as you increase in size—both in revenues and number of employees.  Scale is obviously important in the product creation, and the selling processes.

More to the point — what about scaling in the computing sense?  While there are many areas to consider, I’d say there are two technical components: scaling in performance and scaling in management/operations.  The former implies that for every additional computing resource added to the grid/cloud, you see commensurate improvement in computing throughput.  If you go from N computers to N+1, you should get essentially (N+1)/N multiple on the computing capacity of your environment.  This is just linear scaling…

Scalability of management implies that the complexity and additional work imposed by adding an additional machine to the grid (cloud, pool, etc) is negligible…order zero, nothing.  From an operational standpoint, the amount of work involved in managing a computing pool consisting of ten machines, or 1,000 machines, should be approximately the same.  From a DataSynapse perspective, that means provisioning, configuration, activating, and monitoring applications across a grid involves operational procedures that have no dependency on the amount of machines in the pool.  Obviously other aspects of running and operating the datacenter do scale linearly with the amount of machines… Hardware problems for example, will linearly increase with the amount of machines in your environment.  But the identification and problem rectification should increase in workload/complexity in a sub-linear fashion.

So do people get wiser/smarter with age in a super-linear or sub-linear fashion (we hope it does in fact increase)?  That’s hard to quantify, for sure.  I know, I was totally wrong when I thought the work involved in having two kids (close in age) would be less than double the work of having one… You know, they eat together, play together, etc…  Boy was I wrong.  Of course, now I know that it is absolutely more than double the amount of work — especially at first.   I’m wiser, but it really doesn’t matter in that case — I still would have had two kids, no matter what the scalability was.  In computing and IT in general, concepts of scale are certainly worth pondering and defining.  Driving efficiency in the data center is all about scale.

Tropical Computing

If someone says the words “’island” and “cloud” in single sentence, you might picture being on an island and looking up at clouds… maybe somewhere nice.  Add “organic” to that group of words, as in "organic growth", and perhaps a tropical rain forest comes to mind — one teaming with all kinds of plants and animals.

But we’re not talking about tropical islands here… we’re talking about computing …at least according to Forrester and the authors of a recent note written by Frank Gillett called There Are Three IT Architectures, Not One.  In 2002, Forrester promulgated the term Organic IT — a term used to describe a future state IT… and the vision of a highly virtualized and dynamic IT using shared computing resources. Now they’ve added Cloud IT and Island IT to describe IT architectures that are nearer term alternatives to the idealized Organic IT vision. 

Island computing is sort of like it sounds… A separate group of IT components that are not part of a larger shared infrastructure or utility.  You could think of this as more of the legacy or one-off environments that for whatever reason don’t merit migration to a utility or real-time computing environment.  This description makes sense – it’s basically how most applications are provisioned to fixed IT resources in the data center today.  So it makes sense that if you build a roadmap to migrate applications to a newer, more efficient IT architecture, some islands will be left behind.  Perhaps they are not worth moving over, or they require special kit or software that will no longer be strategic to that enterprise.

Cloud IT is used to describe IT architectures like large Web-farms or grid environments that use shared resources and drive massive efficiencies in management and operation.  While we’re not rushing to change the name of GridServer to CloudServer, it’s clear that our 80+ customers running GridServer (over an estimated group of 200,000 nodes) are indeed doing cloud computing.

In this architecture, Frank and company say that server virtualization is NOT a necessity for creating the most effective, agile, and cost efficient business computing architecture.  Can’t argue with that one — although server virtualization is clearly going to be a default standard.  They site examples of ranging from the typical GridServer use case (he calls it HPC or grid) as well as large Web apps like eBay and Yahoo!, where they are not actually using server virtualization.

Anyway, it’s not a bad, although fairly course, taxonomy.  Naming stuff — like products, and especially generalized IT architecture taxonomies — is very hard.

If someone says the words “’island” and “cloud” in single sentence, you might picture being on an island and looking up at clouds… maybe somewhere nice.  Add “organic” to that group of words, as in "organic growth", and perhaps a tropical rain forest comes to mind — one teaming with all kinds of plants and animals.

But we’re not talking about tropical islands here… we’re talking about computing …at least according to Forrester and the authors of a recent note written by Frank Gillett called There Are Three IT Architectures, Not One.  In 2002, Forrester promulgated the term Organic IT — a term used to describe a future state IT… and the vision of a highly virtualized and dynamic IT using shared computing resources. Now they’ve added Cloud IT and Island IT to describe IT architectures that are nearer term alternatives to the idealized Organic IT vision. 

Island computing is sort of like it sounds… A separate group of IT components that are not part of a larger shared infrastructure or utility.  You could think of this as more of the legacy or one-off environments that for whatever reason don’t merit migration to a utility or real-time computing environment.  This description makes sense – it’s basically how most applications are provisioned to fixed IT resources in the data center today.  So it makes sense that if you build a roadmap to migrate applications to a newer, more efficient IT architecture, some islands will be left behind.  Perhaps they are not worth moving over, or they require special kit or software that will no longer be strategic to that enterprise.

Cloud IT is used to describe IT architectures like large Web-farms or grid environments that use shared resources and drive massive efficiencies in management and operation.  While we’re not rushing to change the name of GridServer to CloudServer, it’s clear that our 80+ customers running GridServer (over an estimated group of 200,000 nodes) are indeed doing cloud computing.

In this architecture, Frank and company say that server virtualization is NOT a necessity for creating the most effective, agile, and cost efficient business computing architecture.  Can’t argue with that one — although server virtualization is clearly going to be a default standard.  They site examples of ranging from the typical GridServer use case (he calls it HPC or grid) as well as large Web apps like eBay and Yahoo!, where they are not actually using server virtualization.

Anyway, it’s not a bad, although fairly course, taxonomy.  Naming stuff — like products, and especially generalized IT architecture taxonomies — is very hard.