Using etcd as primary store/database?

etcd

• etcd is a highly available key-value store which Kubernetes uses for persistent storage of all of its objects like deployment, pod, service information.
• etcd has high access control, that it can be accessed only using API in master node. Nodes in the cluster other than master do not have access to etcd store.

nosql database

• There are currently more than than 255 nosql databases, which can be broadly classified into Key-Value based, Column based, Document based and Graph based. Considering etcd as an key-value store, lets see the available nosql key-value data stores.

• Redis, memcached and memcacheDB are popular key-value stores. These are general-purpose distributed memory caching system often used to speed up dynamic database-driven websites by caching data and objects in memory.

Why etcd not an alternative

• etcd cannot be stored in memory(ram) they can only be persisted in disk storage, whereas redis can be cached in ram and can also be persisted in disk.

• etcd does not have various data types. It is made to store only kubernetes objects. But redis and other key-value stores have data-type flexibility.

• etcd guarantees only high availabilty, but does not give you the fast querying and indexing. All the nosql key-value stores are built with the goal of fast querying and searching.

Eventhough it is obvious that etcd cannot be used as an alternative nosql database, I think the above explanation will prove it cannot be an suitable alternative.

The only answer I've come to see are those between our ears. Guess we need to show first that it can be done, and what the benefits are.

My colleagues seem to shy off it because "it's for storing secrets, and common truth". The etcd v3 revise made etcd capable of much more, but the news hasn't simply rippled down, yet.

Let's make some show cases, success stories. Personally, I like etcd because of the reasons you mentioned, and because of its focus on dependable performance.

First, no. Etcd is not the next nosql replacement. But there are some sort of scenarios, where it can come in handy.

Let's imagine you have (configuration) data, that is mostly static but may change on runtime. Maybe your frontend needs to know the backend endpoints based on the customers country to comply with legal and you know the world wide rollout is done in phases.

So you could just use a k8s configMap to store the array of data (country -> endpoint) and let your backend watch this configMap for changes. On change, the application just reads in the list and provides a repository to allow access to the data from your service layer. All operations need to be implemented in the repository (search, get, update, ...) but your data will be in memory (probably a linked hash map). So it will be very quick to retrieve (like a local cache).

If data get changed by the application just serialize the list and patch the configMap. Any other application watching the configMap will update their internal state. However there is no locking. So quick changes may result in race conditions.

etcd allows for 1Mb to be stored. That's enough for almost static data.

Another application might be feature toggles. They do not changed that much but when they do, every application needs to know quickly and polling sucks.