Microstorage for Microservices

One of the fundamental requirements of microservice is that application containers become stateless. However the states still need to be stored elsewhere, as in databases, object storage, session files, cookies, cache, etc.

Microstorage is emerging as a new architecture to address the storage scalability for microservices. Microstorage inherits the idea from microservices that “only small things scale”.

Scale-up is not Microstorage

Scale-up architecture is often appropriately categorized as monolith with scalability limited to what a single server can deliver. Scale-up storage servers are designed to store enterprise data and they are managed by certified IT professionals. They are best suited for Microsoft Exchange, Microsoft SQL Server, Oracle RDBMS etc. They offer storage consolidation, seamless manageability, high performance and reliability. NetApp, EMC , HDS are leaders in scale-up storage.

Scale-up systems are often sold as hardware appliances and are ideal for low latency, transactional data.

Scale up architecture is 180 degree apart from Microservice architecture. Its single node limit and hardware appliance model makes it unsuitable for microservices.

Scale-out is not Microstorage

Scale-out architecture is also categorized as distributed storage. It is designed to address the scalability limitations of the scale-up architecture.

Scale-out systems are also monolith from the applications point of view. While storage is distributed across many servers, they still appear as one big system. This works against the principle of microservice architecture.

Red Hat Gluster, Red Hat Ceph, Apache Hadoop HDFS, Apache Cassandra are examples of the distributed storage architecture.

Scale-out is designed for fewer number of large volumes (Petabytes) and throughput intensive operations. The complexity of operating a large scale distributed systems limits the scalability of distributed storage architecture for microservices environment.

What is Microstorage?

Microstorage is a storage architecture purpose-built for microservices. Fundamental goal of microservices is simplicity and scalability. Simplicity of microstorage allows storage to scale like Facebook and Google. They can start small and grow to several 100 Petabytes and billions+ users.

Requirements of Microstorage

Scalability: Maximum performance and capacity limits are determined by needs of a single application instance. Usually these limits are small and easier to meet. Linear scalability is achieved through automated provisioning of one microstorage per application instance. Aggregated performance of the entire system may reach to TB/s throughput and 100+ Petabytes.

Tenancy: Since each application instance is provisioned a dedicated storage server, there is no need for complex muti-tenancy and multi-user requirements.

Persistence: Operational data is stored on data volumes backed by local disk and memory. High availability is achieved through replicating data across servers. Critical components like MariaDB and MongoDB offer builtin replication capabilities. Long term persistent data is moved to object storage backend such as Amazon S3 and Minio.

If your application really demands highly available persistent local disk, take a look at DRBD project. I also wish someone integrates NBD and OpenZFS with a nifty docker like management tool.

Even the disk manufactures are working on new initiatives like Open Kineticand Ethernet Disk to address the microstorage space.

Conclusion

To summarize, Application containers which includes application binaries remains stateless. The application state data is comprised of two types - semi persistent operational data and persistent long term data. Operational data uses memory and local disk. Long term data is stored on object storage. Each application instance is a self contained eco-system of computing and storage. Micro storage makes storage become part of the application stack. Infrastructure is reduced to containers running on commodity servers with local disks.