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

What to Look For in an On Demand Platform (aka SaaS Platform)

Nov 27, 2006 by

The clamor and buzz surrounding on-demand platforms for SaaS has been growing steadily. I recently wrote an article on Marc Benioff’s latest platform position. In the video interview I reference, Mr. Benioff highlights some key, defining aspects of platforms. Although in the article I discuss a prevailing ambiguity in Benioff’s vision, I must say that I agree with most of his statements regarding platforms. I was recently reading an excellent post by Phil Wainewright that summarized panel discussions at the SIIA OnDemand Summit. In the summary, Mr. Wainewright discusses how most of the panelists congregated around the SaaS platform & ecosystem campfire. I realize that the discussions were high level, but the topic coupled with Mr. Benioff’s observations prompted me to think about the next step: what are some of the traits that *might* (notice the * for ‘proceeding with caution’) define a successful platform in the future. I came up with the following, in no particular order:

  1. Multi-tenancy – A platform like Apex (and most likely WebEx Connect) strive to define multi-tenancy, and generally single instance, for their constituent applications. The importance resides in the notion that multi-tenancy is one of the defining aspects of efficient SaaS in general.

  2. Security – Any platform worth its salt will make sure that the applications it contains are secure from internal/external attacks as well as purposeful/non-purposeful malicious code.
  3. Application Portability – The concept that one can build an application, of which some portion of it is portable, will be important. The idea that a lock-in platform will succeed is a stretch.

  4. “Mash-Up”
    & Connectivity Capability – Although I hate the word “mash up”, I love the concept and practice. A platform will be responsible for certain levels of connectivity with the outside world, or for that matter, with other platforms. This is where “Web 2.0″ comes into the picture, and where successful platforms will thrive.

  5. EcoSystem Offering – The applications and ecosystem offered under a platform’s umbrella will provide a reason for end users to come back. The platform’s ecosystem will be important to its long term survival.

  6. Reliability – A platform is a foundational construct. What happens to structures on a shaky foundation? This.

  7. Design Stability – Any dependency between a platform and its applications must be stable. Platforms with frequent design changes requiring application modifications will most likely fail. Engineers won’t put up with this sort of stuff and will look for alternatives (assuming that property 3 is available to some degree).

I don’t consider this list exhaustive by any means, but I wanted to start the topic off. Any ideas on what else should be there? If so, leave a comment and I’ll reply/incorporate it into a later post.

read more

Related Posts

Tags

Share This

Web 2.0 vs. SOA…huh?!?

Oct 26, 2006 by

Although the posts are old and the topic potentially stale, I recently read a few posts creating a Celebrity Death Match style arena for SOA and Web 2.0. Richard Monson-Haefel of the I, Analyst blog posted a comparison highlighting the similarities but describing SOA as missing the “social aspect”, Don Hinchcliffe has a good thorough treatise on trying to make sense of it all here, and Jason Kolb fired up most of this conversation here. John Hagel recognizes SOA and Web 2.0 as two complementary technologies separated by a cultural gap in an article he posted a few months ago.

Whew! After all of that, I have to throw my two cents in (as usual). While I agree with some of these, I’m going to venture off on a slight tangent and make a different suggestion. first, let me say I agree with the notion that establishing a “vs.” between the two seems quite trite. In my opinion, they are far from competitive. I also will not classify them as being analogous to each other.

So what’s the deal? First, let’s define Web 2.0 as an ideology and set of associated tools, data, and concepts whose goal is to incorporate end users into the “architecture” such that the architecture becomes a user-centric model. The primary goal in this model is to allow users to collaborate with each in ways that were previously not possible by allowing them to connect systems and data over the Internet in ad-hoc but powerful fashions. Holy mouthful! I DO NOT see Web 2.0 as RSS, or as REST, or as some other singular, self containing technology. Web 2.0 is much bigger.

Now SOA. SOA is a description of a beautiful systems architecture of loosely coupled components that focus’ on process while reducing dependency. (A much more thorough description can be found here). With this in mind, I’m not sure how the notion of one being “vs.” the other fits. Also, while describing them as complimentary seems much more accurate, I think it may over do it. I think SOA facilitates the implementation of the Web 2.0 ideology, and does so very well.  SOA defines an architectural abstraction that provides one of the many potential underlying implementations of a Web 2.0 participant. An application residing on a server could allow for web-based mashups, but be itself defined in an SOA manner. Remember, when I say SOA, I mean SOA the architecture, not SOAP or anything silly detail like that. The notion of SOA is simply loosely coupled services, which is one of the tenets of Web 2.0 that allow for the user-centrically (new word) motivated infrastructure that is the connectivity of data and systems we call Web 2.0. Software as a a service is something that is part of Web 2.0, whose constituent applications can be built using SOA. SOA seems to be a participant in the Web 2.0 ideology. Make sense? Hope so!

read more

Related Posts

Tags

Share This

The Convergence & Popularity of Programming Languages

Aug 21, 2006 by

Matt Ammerman recently forwarded me this diagram, which describes the evolution of programming languages in a timeline fashion. Although in the back of my mind I was aware of how many languages exist(ed), to see it laid out is remarkable. Computer Science as a field has gone through massive change, with programming languages defining a “fossil record” of sorts.

Looking at the diagram, the most interesting thing is the seemingly strong correlation on how popular (where popularity should be taken literally, meaning number of people or percentage of industry using it)a language is/was and whether it existed in its own evolutionary tract or was a convergence of multiple, older languages and paradigms. Obviously, there are some exceptions to this correlation, such as a COBOL and Fortran, but looking at which languages are popular in the modern day, it seems quite apparant that those languages which merged various constructs from multiple languages tend to be more popular (such as Java, Ruby, and C#). Assuming convergence continues to happen, will we reach the level of one super-language, abstract enough to cover all needs yet powerful enough to be useful? From this diagram, things seem to trend towards yes.  The beginning of the timeline introduces a small number of distant languages. The middle seems like a Manhattan traffic accident, with splinters fragments of languages as well as the introduction of new language tracks, making for a heavily saturated section of time. As time progresses to current day, we see some heavy convergence and “thinning out.” Although I doubt this will lead to one “super language”, it does seem reasonable to think that we’re going to continue refining the best languages, and weeding out those that are considered unproductive quite quickly.

read more

Related Posts

Tags

Share This