Source: several years dealing with vault and consul.
What demons did you encounter with vault/consul?
It’s a good idea in principle but it’s not got a good ROI
Most of the problems I've had with Vault have been around it's Terraform provider which they've improved enough that it's not an issue anymore.
I think the only thing about Raft that folks don't realize is how disk hungry it gets, if you want fast write performance you gotta make dang sure all those fsyncs can keep up. Our largest Consul cluster today runs on storage-heavy boxes as it does ~500Mb/s of writes pretty much 24/7.
I use Consul w/ Vault today instead of the internal storage for Vault just cause Consul has really nice monitoring around some stuff that Vault doesn't (path-based stuff for the most part), I think the internal storage is a really good option for 90% of use-cases.
We did this for 30 years fine before someone invented this stack on deployments much larger then the average consul or vault deployment these days.
I had something running 15,000 dynamic rps on Apache about 15 years ago.
People are blinded from simplicity by complexity. Eventually complexity owns you. You can only own simplicity.
At the end of the day this is one way to solve a problem that doesn’t need to be solved that someone has convinced you is a problem.
What does this mean? This doesn't mean anything?
Are you saying to push the DB to the client?
It's less than a few hundred lines of Go that just wraps two other databases (syndtr/goleveldb and ledisdb/ledisdb) with a third library (tidwall/uhaha) that provides a Raft API.
Here's the LSET code:
https://github.com/gitsrc/IceFireDB/blob/main/lists.go#L232
func cmdLSET(m uhaha.Machine, args []string) (interface{}, error) {
if len(args) != 4 {
return nil, rafthub.ErrWrongNumArgs
}
index, err := ledis.StrInt64([]byte(args[2]), nil)
if err != nil {
return nil, err
}
if err := ldb.LSet([]byte(args[1]), int32(index), []byte(args[3])); err != nil {
return nil, err
}
return redcon.SimpleString("OK"), nil
}
So what "IceFireDB" is:1. tidwall/uhaha - Raft server (m uhaha.Machine, rafthub)
2. tidwall/redcon - Read/write redis protocol (redcon.SimpleString)
3. ledisdb/ledisdb - Redis-compatible with disk persistence via leveldb (ldb.LSet)
4. syndtr/goleveldb/leveldb - Provides snapshots, other scattered references throughout code
It also includes this seemingly random file below, which seems to implement some string slice overloads using unsafe.Pointer:
https://github.com/siddontang/go/blob/master/hack/hack.go
// no copy to change slice to string
// use your own risk
func String(b []byte) (s string) {
pbytes := (*reflect.SliceHeader)(unsafe.Pointer(&b))
pstring := (*reflect.StringHeader)(unsafe.Pointer(&s))
pstring.Data = pbytes.Data
pstring.Len = pbytes.Len
return
}
// no copy to change string to slice
// use your own risk
func Slice(s string) (b []byte) {
pbytes := (*reflect.SliceHeader)(unsafe.Pointer(&b))
pstring := (*reflect.StringHeader)(unsafe.Pointer(&s))
pbytes.Data = pstring.Data
pbytes.Len = pstring.Len
pbytes.Cap = pstring.Len
return
}Aerospike and ScyllaDB both support a subset of the Redis API and run as a durable cluster. Both have been tested with Jepsen.
Only if you want to be a drop-in replacement and take advantage of existing compatible libraries. With the recent tea around the official Elasticsearch Python library, it becomes a more interesting question.