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.
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.
Sign up for MIS Asia eNewsletters.