Is Database-as-a-Service a Bad Idea?
One of the most important parts of that shift is the advent of cloud platforms...this kind of platform lets developers write applications that run in the cloud, or use services provided from the cloud, or both.
Even though these platforms look familiar, Dave provides a word of caution:
While it’s useful to look at on-premises platforms and cloud platforms through the same lens, the two aren’t identical. When platform functions move into the cloud, they sometimes change in significant ways.
Dave divides an application architecture into three categories:
- infrastructure services
- application services
and argues that:
a cloud application can be built on a cloud foundation, just as an on-premises application is built on an on-premises foundation. Both kinds of applications can access infrastructure and application services provided on-premises and in the cloud. Just as on-premises platforms support today’s applications, cloud platforms provide services for the applications we’re likely to build tomorrow.
Out of all possible infrastructure services, "Data Services" are arguably the most important as information systems cannot be built without them. Data represents also a major strategic asset as the Cloud Platform that provides the most popular Data Services will likely command the largest market share.
Dave sees different types of Data Services:
remote storage in the cloud comes in different styles. For example, Amazon’s Simple Storage Service (S3) provides basic unstructured remote storage. The model it exposes to developers is straightforward: objects, which are just bunches of bytes, are stored in buckets ...
Another approach to cloud storage is to support more structured data. In Microsoft’s SQL Server Data Services (SSDS), for example, a container includes one or more entities, each of which holds some number of properties
Arnon Rotem-gal-Oz wonders though whether the "Database as a Service" is a good idea. This is a general trend in the industry with Microsoft, IBM, Amazon, LongJump or EnterpriseDB trying to provide essentially the same type of functionality. He explains:
So why is exposing the database through a web-service (RESTful or otherwise) is wrong? let me count the ways
- It circumvents the whole idea about "Services" - there's no business logic It makes for CRUD resources/services
- It is exposing internal database structure or data rather than a thought-out contract
- It encourages bypassing real services and going straight to their data
- It creates a blob service (the data source)
- ItIt encourages minuscule [half]-services (the multiple "interfaces" of said blob) that disregard few of the fallacies of distributed computing
- It is just client-server in sheep's clothing
For a business, the electricity that flows from an outlet seems endless. And water will stream out of the tap without worry -- businesses pay only for what they use. But computing power hasn't been so seamless.
We are certainly barely scratching the surface of Cloud Platforms which will not emerge without some form of structured data management. It seems still too early to tell which Data Services and Cloud programming model will win. Would you trust your enterprise data to Data-as-a-Service? Would you prefer to access data through application services or simply CRUD your system of record?
Why Data Services are useful
Firstly, many companies are now past the point of trying to do large "get-everything-perfect-first-time" SOA engagements, and have moved to a more pragmatic, continuous improvement, iterative model of SOA. And in this model, quickly unlocking data to the rest of the enterprise is vital.
Secondly, just because you have the ability to make a Data Service from a database doesn't mean you have to expose the internal structure. You can use an ESB or Mashup server to transform, aggregate, and massage your data service into something that truly fits the business. This is a common pattern and one I see users asking for a lot.
I see Data Services as one of the killer applications for SOA - by allowing secure, reliable, managed access to data across a distributed domain you unlock huge capabilities and enable a new set of SOA applications incredibly rapidly.
This podcast offers some further discussion of the area.
Paul Fremantle, CTO, WSO2
Disclosure: WSO2 has an open source Data Services solution: wso2.org/projects/solutions/data-services/java which is currently available in our WSAS server and Mashup Server and in beta as a standalone system.
Re: Why Data Services are useful
thanks for your comment, I think the question is "Can all enterprise data be exposed that way?" Clearly MDM or CDI makes total sense. Is it true for transactions (in the OLTP sense) as well?
Now if you think that Data-as-a-Service is a killer app for SOA or if you if you are architecting a Cloud Platform, what is the programming model for developing solutions on a DaaS foundation?
Aren't we one more time trading the opportunity to become process-centric for the convenience of being data-centric? Don't you think that DaaS will lead to IaaS (Integration as a Service). You speak about: "transform, aggregate, and massage", but is that enough to go beyond MDM and CDI?
I really like this statement from Dave:"When platform functions move into the cloud, they sometimes change in significant ways." I would add, if the architecture of a Cloud Platform is about taking a "traditional solution architectures" and distributing the capabilities and aspects atomically, what are we gaining compared to EC2 for instance? Cloud computing should be more than a question of topology, this is a unique opportunity to reinvent the programming model.
Re: Why Data Services are useful
Data virtualization promises to provide a single access point to manage and view all enterprise data regardless of data source or physical location. By providing information as a service, data virtualization software has the potential to greatly impact the deployment of SOA.