Moving a database to the cloud? Wrap it in a services layer

Databases need to be logically and physically decoupled from applications in the cloud, despite what worked in the data center

Most applications have some sort of database attached, and cloud-based applications are no different. In the world of cloud, you have many choices for database architecture, type of database, and number of databases to use. However, when it comes to database coupling, cloud developers often don't understand what the new rules are or how they apply.

Typical cloud-based platforms provide services that are widely distributed. This includes database and middleware services, as well as core cloud-native interfaces such as those that provision and deprovision resources. The database should be considered as sets of services linking your application services to the data.

[ Review: Docker 1.0 is ready for prime time. | 6 Docker services making a splash. | From Amazon Web Services to Windows Azure, see how the elite 8 public clouds compare in the InfoWorld Test Center's review. | Stay up on the cloud with InfoWorld's Cloud Computing Report newsletter. ]

How should the database be coupled to the application? Most cloud developers and cloud application architects tend to tightly link the database to the application. Perhaps they'll even run the things in the same machine instances. Why not? It worked in the past. But that's a recipe for trouble.

You must consider a few details about the use of data, when building and hosting applications on cloud-based resources:

  • The database should exist as a set of services that is logically and physically decoupled from the core application. You do this for performance and reliability purposes, as well as for good application architecture by placing the data in its own domain.
  • The database services can use multiple databases and multiple models. You're not restricted to using transactional SQL services because you can abstract the databases behind data services. For example, you can use purpose-built databases, such as in-memory databases that provide higher performance for specific types of required data services. Or you can add Hadoop to your database mix.
  • Although logically and physically decoupled, the data should physically sit as close as possible to the core application and users of the data. This reduces communication latency that can be significant in the cloud.

As we all gain more cloud experience, best practices will lead us down more service-oriented paths, where the core application and data services are abstracted away from the physical machines and where they are loosely coupled.

This approach will take a bit of rethinking, so let's start now.

This article, "Moving a database to the cloud? Wrap it in a services layer," originally appeared at InfoWorld.com. Read more of David Linthicum's Cloud Computing blog and track the latest developments in cloud computing at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Join the discussion
Be the first to comment on this article. Our Commenting Policies