Jamie's Blog

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.

"It's the Application, Stupid"...

As the presidential season gets going in full swing, I'm harkened back to the Bill Clinton 1992 campaign when "It's the Economy, stupid" became the driving mantra.  Seemed like such a pithy phrase that rallied the team to stay focused on (and defining) the differentiating ideology.

Whenever we're around an election season and I absorb (or ignore) the competing election campaign messages, my mind switches to my own business at hand it starts echoing "It's the application, stupid".  The approach, or central driving force for next generation IT should start with the application.  Business application owners don't care about system level details: operating system, hardware platform, application server, developer frameworks, etc. are of no importance to the end user experience - as long as it's a good one, and it's delivered at a minimal price per unit service level.

Yes there are other important aspects of IT for business that call for a system-first approach to discussing and building strategies for changing IT for the better.  There are communication and basic connectivity issues, data, storage, security, etc.  But when you talk about affecting business, both at the core and at the margin of competition, application agility is usually king. Changing or adding functionality or new services, dealing with changing performance demand, etc. are critical to competing in the marketplace.

Dialing up a specific application performance (end user experience) and delivering at the lowest cost (as long as it hits the SLA) should be the defining goal (utility function) of IT service delivery.  And the ability to change quickly, e.g. roll-out a new version of the application or service; upgrade versions of the application runtime or platform, enables businesses to focus on what they do... whatever it that may be.

Like it or not, the next eight months or so will be filled with all types of messages and mantras about change and the future of our country.  Perhaps "it's the economy, stupid" will make its way back into the race.  Regardless, my brain will hit the replay button and "It's the application, stupid" will start playing in my head once again.

It's not really a polite tagline, though...