Blurring the functional line–Zoho CloudSQL merges on-site and on-cloud

Next Story

The Extraordinary Rise And Fall Of Denmark's IT Factory

Zoho CloudSQL overview

Zoho's CloudSQL Concept map

This morning, Zoho announced the release of their CloudSQL middleware technology–a powerful pipeline between on-site applications and the cloud.

While consumers found the switch to cloud computing relatively simple, enterprises continue to struggle with the lack of powerful data-portability structures.

SAAS systems seldom provide an easy and reliable way to transfer information to and from traditional on-site applications. By creating an SQL-based pipeline between the cloud and on-premise systems, Zoho hopes to solve this problem.

It’s an interesting play–combine a well-known database language with a new cloud-based back-end. As Zoho’s blog explains:

The problem is that there’s a fundamental mistake people make when they think of SQL: they think of the access language and the retrieval/storage mechanism as one and the same. But they can in fact be separated. SQL can be used to describe the data and relationships being accessed. The backend (the engine that actually handles the data) can be anything.

This is another step in Zoho’s steady march toward increased data portability. Except now they’re opening everyone’s walled gardens–their blog post states, “[CloudSQL] allows customers to interact with their data on the cloud, from another cloud application…” With this SQL pipeline, a company can seamlessly connect legacy systems and cloud-based systems. (Example: Microsoft Office connected to Google Apps connected to Zoho Office.)

While Zoho’s CloudSQL technology is the first marriage of SQL and cloud-computing, expect further innovation as the functional differences between traditional on-site systems and cloud-computing continue to evaporate. Paradoxically, better pipelines simultaneously simplify and de-incentivize migration from one system to another. Instead of picking between two applications (each with only half the desired features), you can now use both–the pain of connecting them is minimal.

For now, the CloudSQL technology is only available for Zoho Reports, but expect more Zoho services to follow suit. The diagram below illustrates the potential of the CloudSQL model:

Their blog post explains more – The Future of SQL in a SaaS World: Announcing Zoho CloudSQL.

  • http://www.microshaft.com Steve Bomber

    SQL over HTTP–home of the 30 second select statement. I kid, I kid :)

    Seems like a cool idea in theory, but from a software architecture standpoint, this seems completely wrong. I would never give direct access to my database to third party apps. Heck, not even to my own external apps. A lot of stuff typically happens as data makes its way to a database for longer term storage. That stuff (business logic) is subject to change. Guess what? The database schema is likely to change with it.

    This is why we have a layer of abstraction called an API. The API can be versioned to maintain stability while the underlying systems are modified with more agility.

    Aside from all of that, imagine how easily your entire system could be corrupted if one application is making unchecked modifications to the underlying data. This seems to be putting way too much faith in fellow developers.

    • Larry

      I think the 30 second select statement is not as crazy as you indicate. That said, all of us have used caching to pre-fetch the most frequently accessed data, and it’s likely that DaaS (database as a…) is here to stay (or evolve anyway).

      A friend of mine forwarded me this post. I think we all need to recognize that we are on the cusp of the next generation of computing. As such, assuming that we get all the same stuff as we do today in existing, physically co-located environments is unrealistic. It will evolve and evolve rapidly. And with server sales falling (IDC), an elastic DaaS model would seem like an attractive offer.

      My same friend looked at this as the death of traditional middleware. I don’t think so. I see it as the birth of true extra-prise interoperability. MQ will be around until Christ returns as a carpenter. No one should kid themselves on that (are you listening IBM?!)

  • Bob

    Wrapping things into HTTP is nothing new…Besides, XML-RPC seems a much better approach (and the bloated form, SOAP, has been tried and not been too successful except for certain batch-type applications).
    Protocol mapping is a good direction, but too many layers = too many moving parts = risk+speed issues.
    Like XML Parser hardware, has the time come for SQL interpreter hardware?

  • http://koolapp.blogspot.com Alex Popescu

    As far as I know, Amazon SimpleDB will add support for SQL too. I don’t remember the details for now though.

  • Bob

    I still think that something like Google’s Big Table or the once-popular ReiserFS (before his legal issues) is a better approach to SaaS-type indexing.

  • pwb

    Zoho does quite a few interesting things but none of them particularly well. Maybe Zoho is a bit over-extended?

  • http://www.radsense.com Peter T

    Microsoft will have their own on-premises cloud soon (http://www.azurejournal.com/2008/11/on-premises-cloud-computing/) and I’m sure they’re going to “standardize” the “middleware technology”:) I’m glad to see more and more “cloud” players … let’s see in two years from now who survived! (maybe TCIT should create a “cloud dead-pool”:D:D)

  • http://www.allurefx.com Sekhar Ravinutala

    Anytime you distribute stuff, the most obvious first step is to make access to it transparant, to make it look local. Take NFS that we’ve all been using forever. And WRT databases, that’s what the whole class of “distributed databases” attempt. So, I don’t really see what the novel idea here is. Impressive implementation? That may be, because it’s very hard to actually implement the transparency.

    @Steve – you make a fair point on the danger of exposing database willy-nilly. But this one is supposed to be for apps, not end users. I.e., the apps are already accessing local databases through SQL; and we’re replacing the database with a distributed one, but with the same interface. In theory, the apps wouldn’t have to change any code other than to switch the data source name.

  • http://www.techcrunchit.com/2008/12/04/the-price-of-success-cloud-social-network-advancements-spawn-innovative-spammers/ The Price Of Success: Cloud & Social Network Advancements Spawn Innovative Spammers

    […] Previous Post The Price Of Success: Cloud & Social Network Advancements Spawn Innovative Spammers Leave […]

blog comments powered by Disqus