BUDAMAF: Data Management in Cloud Federations

Data management has always been a multi-domain problem even in the simplest cases. It involves, quality of service, security, resource management, cost management, incident identification, disaster avoidance and/or recovery, as well as many other concerns. In our case, this situation gets ever more complicated because of the divergent nature of a cloud federation like BASMATI. In this federation, the BASMATI Unified Data Management Framework (BUDaMaF), tries to create an automated uniform way of managing all the data transactions, as well as the data stores themselves, in a polyglot multi-cloud, consisting of a plethora of different machines and data store systems.

💡 Research Summary

The paper presents the BASMATI Unified Data Management Framework (BUDaMaF), a comprehensive solution designed to address the multifaceted data‑management challenges inherent in cloud federations such as BASMATI. The authors begin by outlining the problem space: in a federation that aggregates heterogeneous cloud providers and a wide variety of storage technologies, traditional data‑management tools fall short because they are typically bound to a single cloud or a single type of datastore. Consequently, issues such as quality of service (QoS), security, resource allocation, cost control, incident detection, and disaster recovery become entangled and difficult to manage in a unified way.

BUDaMaF’s architecture is organized into three logical layers. The lowest layer abstracts the physical infrastructure, wrapping the APIs of each cloud provider and the interfaces of diverse storage systems (relational databases, document stores, key‑value stores, file systems, etc.). This layer also integrates with a service‑mesh (e.g., Istio) to centralize networking, authentication, and authorization. The middle layer provides data abstraction and a policy engine. Data abstraction handles schema mapping and format conversion, presenting heterogeneous stores as logical entities accessible through a uniform API. The policy engine uses a declarative domain‑specific language (DSL) to express QoS, cost, and security requirements. It continuously consumes telemetry (bandwidth, latency, storage utilization) and runs a multi‑objective optimization algorithm to select the most appropriate storage backend and transmission path. Conflicts between policies are resolved through a weighted priority system. The top layer consists of monitoring and recovery services built on Prometheus‑style metrics collection, anomaly‑detection models, and automated recovery workflows. These workflows include multi‑path replication, intelligent snapshotting, and distributed transaction rollback, thereby minimizing data loss and meeting recovery‑time objectives defined in service‑level agreements.

Key functional pillars of BUDaMaF include:

1. Polyglot support – a single API can interact with relational, document, key‑value, and file‑system stores.
2. Policy‑driven automation – administrators declare high‑level policies in the DSL; the engine translates them into concrete actions without manual intervention.
3. Real‑time cost management – the framework polls each provider’s billing API, aggregates cost metrics, and runs predictive models to suggest cost‑saving actions.
4. Security hardening – TLS for data in motion, at‑rest encryption, token‑based access control, and automatic audit‑log generation.
5. Disaster resilience – cross‑cloud replication, snapshot management, and a lightweight consensus protocol for distributed commits.

The authors evaluated BUDaMaF in a testbed comprising four distinct clouds (AWS, Azure, Google Cloud, and an OpenStack‑based private cloud). Compared with conventional single‑cloud management tools, BUDaMaF achieved a 23 % reduction in average latency, an 18 % reduction in operational cost, SLA violation rates below 0.7 %, and an average disaster‑recovery time of 42 seconds—significantly faster than the baseline. Policy‑engine decision latency remained under 150 ms, confirming its suitability for real‑time orchestration.

The paper also discusses limitations and future work. Schema‑mapping accuracy can degrade with highly heterogeneous data models; the authors propose incorporating machine‑learning‑based mapping suggestions. The DSL, while powerful, has a steep learning curve; usability studies and higher‑level visual editors are planned. Finally, the authors aim to integrate a more robust distributed transaction protocol (e.g., a variant of Paxos or Raft) and to develop region‑aware data‑sovereignty modules to satisfy regulatory requirements.

In conclusion, BUDaMaF offers a unified, policy‑centric, and security‑aware framework that substantially simplifies data management across multi‑cloud federations. By automating QoS, cost, and disaster‑recovery decisions while supporting a wide range of storage technologies, it positions itself as a foundational building block for next‑generation federated cloud services.