You are here

Architecting Cloud-Facing Database Applications Without the Overhead

architecting for cloud

The transition to the cloud is not going to be a smooth affair. As can be seen already, there will be numerous pitfalls and wrong turns, and ultimately it will be very difficult to determine if the money spent has led to the most optimal computing environment.

A key issue lies in the fact that not all data assets and activities will jump to the cloud at the same time. This forces the enterprise to produce workarounds for deployments that exist half in the cloud and half in the legacy data center. Such hybrid configurations are likely to be the norm as the cloud era unfolds, but until all aspects of the enterprise data stack gain cloud functionality, it can lead to wide discrepancies in performance and capability.

The emerging fields of cloud-native applications and microservices are two cases in point. Both need steady access to at least one database, but scaling up job processors to handle increased data loads works fine for the app, but it quickly overloads the database with transactions. There are numerous workarounds for this, such as sending fewer, larger messages and delaying updates, but they typically result in less-than-optimal performance than should be expected of an advanced cloud architecture.

Traditional RDBMS platforms also suffer when thrown into a distributed environment, particularly when it comes to data access and consistency. At the moment, many developers are relying on innovative but ultimately disappointing data management schemes that fail to address some of the fundamental issues inherent in scale-out distributed architectures. One of these is the shared-disk approach, in which all disks in an array are accessible from all clusters. The chief problem here is that failover can be slow as nodes negotiate ownership of the disk, requiring yet another layer of management such as Windows Server 2012’s Cluster Shared Volumes solution.

As well, there is the shared-nothing approach in which each node maintains its own memory and disk storage. This is great for eliminating contention across the environment, but it doesn’t lend itself to scale very well. If you need more compute power, you have to add storage and I/O as well. Again, you can fix this by layering management on top of the cluster, but any additional overhead consumes resources that would otherwise be used to process the workload.

Finally, there is synchronous commit, in which transactions are only completed when primary and secondary databases signal their acknowledgement. While this enhances data protection and automated failover, it comes at the expense of increased latency, which is anathema to many cloud-facing applications. And the alternative, asynchronous commit, results in unacceptable risk for most enterprises.

All of these approaches suffer from the same basic flaw: the inability of legacy DBMS platforms to scale properly in distributed, cloud-facing environments. It’s kind of like painting racing stripes on a Volvo and saying it is ready for the Daytona 500.

What’s needed is an entirely new database, one that is architected from the ground up to perform at peak efficiency in dynamic, distributed environments while maintaining logical consistency across all platforms and system configurations. Emerging platforms like NuoDB are fulfilling this need, but the question is how soon will enterprise executives recognize the fact that their legacy database systems cannot function effectively in the cloud without multiple layers of unnecessary management.

Add new comment