Skip to content

Roadmap

Wangpan edited this page Jun 15, 2022 · 11 revisions

中文版

Update at: 2022-06

Our understanding of cloud native

Popular cloud native applications always have 12 factors, which are codebase, dependencies, configuration, backing services, build-release-run, processes, port binding, concurrency, disposability, dev/prod parity, log and admin processes. To storage infrastructure, they are used as storage resource pools by cloud native operating systems (open sources include OpenStack, Kubernetes, Spark, etc., and commercial ones include mainly public clouds). Together with storage infrastructure, cloud operating systems provide cloud native services, which enable the cloud applications (web services, APP backends, message middleware, database middleware, load balancing services, AI/ML/DL, bigdata, etc.) to have the twelve factors.

Our understanding of cloud native storage

As infrastructure resource, Cloud storage provides storage subsystems for cloud operating systems. Mainstream cloud operating systems develop storage interfaces to connect to various storage systems (HDFS, cloud hard drives, object storage, etc.), such as OpenStack Cinder, Kubernetes CSI plug-ins. Cloud operating system administrators can build and maintain cloud storage resources for cloud native applications by the cloud native storage interfaces.

Cloud native storage is different from cloud storage. Cloud storage is the infrastructure resources provided in cloud operating system. App developers or operators cannot customize resource types and resource pools. The size and quantity of the storage and that how to deploy and maintain resources are black boxes to users. Cloud native storage is based on cloud storage which is defined by the developers/operators of cloud native applications. Everything of storage resources are white boxes, and all cloud native applications can use seamlessly without modification.

Cloud native storage can be built, destroyed, and migrated across various cloud operating systems by uniform interfaces. User can easily deploy / revoke / migrate and maintain cloud native storage without care about the implementation details of underlying cloud operating systems.

Cloud-native storage can be deeply integrated with cloud-native applications to improve application’s performance, reliability, availability, and user experience. For example, they can provide advanced features (local storage, local caching, backup, tiered storage, remote recovery, etc.) which cannot be supported by traditional cloud storage.

Cloud native storage have five levels. Level 1: Basic Install (automated application, provisioning, and configuration management); Level 2: Seamless upgrades (patch and minor version upgrades supported); Leve 3: Full Lifecycle (app lifecycle, storage lifecycle backup, failure, recovery); Level 4: Deep Insights (metrics, alerts, log processing and workload analysis); Level 5: Auto Pilot (horizontal/vertical scaling, auto config tuning, abnormal detection, scheduling tuning). Curve is a cloud native storage system. We will try our best to achieve Level 5 with Curve in the future.

Roadmap (2021~2022):

  • CurveFS based on CurveBS
  • POSIX-compatible and mountable by FUSE
  • CurveFS based on Object Storage System by S3-like interface
  • Cache support on CurveFS
  • Shared File access by multi-clients
  • CurveFS cloud native support
  • RAFT optimization
    • ParallelRaft for write
    • Reduce write magnification for the new write
  • Performance optimization
    • File meta data pre-allocate
    • RDMA, io_uring, SPDK support
    • CurveFS kernel client support
  • Cloud tiering and data lifecycle support
  • Cloud-native database support base on PolarFS and CurveBS