Google Apps Premier Edition

Feb 22, 2007 by

This is just a mini-post to aggregate the plethora of commentary surrounding the announcement of Google Apps Premier Edition.  Phrases like “in direct competition with Microsoft Office” abound, but overall it’s apparent that there are still a tremendous amount of questions surrounding the maturity level of the application suite.

Here’s a bit of what’s being said:

The question of competitive landscape comes up quite a bit in these discussions.  Is Google Apps Premier Edition as a whole product actually in direct competition with MS Office? Don Dodge offers some very good examples of why it is not. It seems that Google Apps’ aggregate features fall in between the intentional sparcity of the 37signals collaboration suite, and the common robustness and sheer power of MS Office.  As Google starts to elbow its way into the market MS is in a position to adapt and continue to innovate, it’s companies like Zoho and 37signals that should really be concerned (not to mention the price comparisons – $50 per user/per year for Google Apps Premier vs. $149 per user/ per month for 37signals’ BaseCamp).

What are your thoughts?  Where does Google’s play sit in the landscape of enterprise communication and collaboration?

read more

Why Do We Overcomplicate Technology Messages?

Feb 6, 2007 by

Generally, most of my posts introduce a topic, question, or label (we’ll call it x), and then I provide a y to describe and foundationally support x. Well, for this post I’m going the opposite direction. For this particular x, I find that the sheer mention of it causes people to cringe and howl. Instead, I’ll give you y first, and then x (kind of like Jeopardy, but not really, but kind of). Here goes y

Imagine a technology that lets you reuse other technologies you’ve already bought and built regardless of how these other technologies were made. This same technology will also make sure that any technology choices you make in the future can be easily integrated into your existing system.

What x am I talking about in the above y? Service Oriented Architecture, or vernacularly known as SOA. Ok, go ahead and cringe now. Why am I bringing up the continually beaten dead horse? Because to this date, I want to vomit while reading the various descriptions of SOA on the web (particularly those provided by SOA vendors). Is it really that hard to relay a simple message? I’m basically jumping in on Thomas Otter’s side, as highlighted in his recent post on SOA. It seems like there is a trend in overcomplicating messages within the technology. When you have an established technology or product, there is no reason to obscure or overcomplicate your message when marketing the said product. Apparently, SOA is a magnet for obscure definitions. Some examples:

“Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application’s business logic or individual functions are modularized and presented as services for consumer/client applications. What’s key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation.” 

-http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html

“SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.”
-http://www.xml.com/pub/a/ws/2003/09/30/soa.html (To be fair, this one attempts to set-up a simple analogy before hand)

“Service orientation is an approach to organizing distributed IT resources into an integrated solution that breaks down information silos and maximizes business agility. Service orientation modularizes IT resources, creating loosely coupled business processes that integrate information across business systems. Critical to a well-designed service-oriented architecture is producing business process solutions that are relatively free from the constraints of the underlying IT infrastructure, because this enables the greater agility that businesses are seeking.” 
-http://www.microsoft.com/biztalk/solutions/soa/overview.mspx

One thing companies may want to consider is to follow Otter’s advice: “The way to talk about SOA is not to talk about it” or don’t define SOA with the word SOA, and don’t get all architectural on us. After all, what is more understandable: Peanut butter is a healthy, tasty food that goes well with grape jelly or Peanut butter, a processed form of Arachis hypogaea that maintains a creamed consistency, is a flavorfull food that is often used in a pairing with processed grape food and provides its consumers with antioxidants, monunsaturated fats, and Resveratrol, all of which are generally associated with fortifying the human body against cardiovascular and coronary-artery diseases. Personally, I like chewing on peanut butter and jelly, and not on mouthfuls of words.

read more

Urban Planning in the Datacenter?

Jan 31, 2007 by

It was written only a month ago, but Robert Mitchell’s article ‘Virtual machines: the new ghetto in the data center’ is a classic in my book. Mitchell’s article draws up the similarities between data center engineering and urban planning. Like city planners, service providers must be careful that the efficiencies they introduce to their load-bearing technologies don’t harm the quality of service to their end users. It seems like a no-brainer… but immediately driving down that cost-to-service pain is so very tempting nonetheless.

When you scale an infrastructure to handle the load of more tenants, you can scale out – add more machines (a la Google) and harness the power of clustered computing, or scale up – add more power to existing hardware, or replace it with more powerful hardware to shoulder the load. Similar urban planning scenarios dictate that to accommodate more tenants you either build more houses (scale out) which results in urban sprawl, or you build high rise apartment structures (scale up) and end up with super-expensive maintenance costs. Either tactic has a beneficial short term outcome, but problems arise because with success come more tenants moving in. You could scale up or out forever, the problem is that both lose efficiency over time.

 

urban sprawl

 

But then there’s virtualization. Mitchell’s metaphor is that virtualization is the ghetto of datacenters – that is, virtualization is the high density housing of more tenants in the same physical structure. Don’t scale up, don’t scale out – instead, build partitioning elements and use the same space for more tenants. The metaphor is dead on. Mitchell ‘s case, though, is that improper use of virtualization leads to terrible inefficiencies when it comes to per tenant load. One of the more interesting comparisons that Mitchell makes is the way that virtualization causes tenant processes to ‘fight’ for computing time.

“Unfortunately, some organizations may be stepping back into a world more familiar to mainframe users in the ’60s and ’70s. In that era of timesharing, applications got a slice of the mainframe.”

The use of virtualization technologies may lead to increased overall efficiencies for the provider, but slow response times and lowered service levels for the end user due to sharing the same computing resources with other tenants. Mitchell’s metaphor calls virtualization a compromise – a way to cram more tenants into the same space.

As SaaS becomes more prevalent and the number of SaaS providers grows, more companies will be exploring the various techniques for balancing cost-to-service efficiency with load-bearing capability. Scaling becomes a major concern, and any of the above mentioned approaches to scaling costs a good deal of money – hence the added costs of starting a SaaS company and imminent concern of provider buckle risk.

To complete the metaphor… new SaaS providers will need to build cities, when traditional software packages are dealt with more like prefab homes.

I’m curious to hear some stories about scaling in data centers.  I think we all know of Google’s approach, but what has your experience been?  Have you had better luck taking up more real estate with commodity boxes, or paying for high-end raw processing power?  If you are using virtualization technologies, what have the net effects been on the end user experience?   

(Note: I purposely left ‘computing in the cloud’, like Amazon’s EC2, out of this conversation because I want to discuss the burdens of scaling as they pertain to providers who build, instead of buy, their hosting solutions)

read more