Dinemic

Initially Dinemic was considered as backend for IaaS cloud. Then it evolved into standalone framework, able to handle any kind of decentralized applications. It was ORM, a bit tricky to start with.

But this "tricky" was still a bit on too high level, even with Python bindings. End of 2019 came up with idea of creating something similar to K8s, in yaml, able to handle data models and Dinemic's P2P architecture without any central point.

That idea came up to the separate project, the starsheep.io. Now anybody, who knows only basics of YAML could start creating own models of data, define listeners and wrote scripts with favorite scripting language. After couple "campaigns" at Facebook and Reddit, project Starsheep was response for DevOps and people, who don't have opportunity to jump into sophisticated architecture of Dinemic.

Finally this Open Source project achieved shape, which could be adapted by as much persons as it is possible: developers, devops and sysadmins. It is easy, user friendly (if one could say it about YAML) and provides all desired Dinemic functionalities with complicated cryptography, under the hoods. And with all its complicated backend, it still allows to make decentralized, event driven applications in very simple way.

Finally, after main product has grown enough and was stable, it was time to port it to the Python. Additional motivation was attempt to create simple "Hello world" application with Dinemic. It was powerful tool, but entrance level to start coding with this framework was in my opinion insane. Especially, that the change for new developers was not in API, but in whole application architecture.

After couple weeks, first release of PyDinemic was available in PyPi repository. Behind the Python module, there was still C++ framework, but hidden by nice Python API. Entrance level was lower - Python is much simpler than C++. But still, it was quite different architecture.

During next months PyDinemic was gaining new functionalities, making it much closer with functionality to original C++ library. That was also the time when I realized that original idea of making IaaS cloud is no longer attractive. I've created stable tool which is good enough to be separate project and its maintenance was taking too much time to switch again for cloud development. Especially, that during this days there were other, much more powerful tools, line Kubernetes and public clouds.

Finally, framework has grown enough to make first tests, that will be able to confirm how it works. Also it was configured to automate a bit of my work, to automagically launch whole test suite, build library and publish it. Thank you Gitlab guys!

Since that moment Dinemic started publishing more or less regular releases. With all previous requirements and assumptions in mind, every couple months, it gained new functionalities, like mentioned encrypted data, additional fields handled as object fields in C++ or separate read and update authorized object lists for each object.

Working with configured CI/CD pipelines gives large burst... and sometimes hours of waiting for pipeline fails

So, if any node could update state of its own database, representing any object, especially during split brain, then what will happen after rejoin? What if logics (or somebody) make conflicting changes? What if ... Yep! All that nightmares, when usually admin gets frustrated after disaster and something in real world is different than in database. If anything happens in database, it triggers actions. Dinemic becomes Event Driven framework.

Besides, authorization and authentication had a final shape. Every object's ID is not a random integer or string. Now it is hash of its public key. Any updates have to be signed by authorized key. Access control for objects' fields? Let's just encrypt with multiple keys and don't care about that. If somebody have no access, then he won't decrypt it. Simple, scalable and without central points.

Also all changes in database are stored in form of chain (or rather tree, after split brains). This allows to keep track of any historical state changes in database, as well as simply handle rejoins with awareness of that at application level.

Choosing good tools is crucial for final shape of project, especially the quality of code, its security and stability. Finally, after some attempts, project had clear goals:

• be the ORM for C++ to allow synchronize object's state
• each object will be represented in Key-Value database
• each node will have own copy of database, to avoid outage
• each object will have its own keys to sign any changes within this object
  Et voila! No central points, everybody are able to validate any change and any split brain will result in outage of whole cluster. There always be two separated cluster, rejoined one day.

Initial architecture was fine, now it was time to get tools for that. Days spent on studying OpenSSL, NSS and GnuTLS APIs have convinced me that cryptography, besides its beauty, is hard.

After couple attempts with Python, I finally decided to use C++ due its performance and library set. Initially with HTTP API, Avahi for node autodiscovery and libsodium, I switched to faster and more elastic ZeroMQ, raw multicast autodiscovery and libsodium.

With all goals in mind I started looking for solutions how to manage things like virtual machines, software defined networks and storage space without any weak or single points. With recent job related to X509, sheepdog and couple other projects in my mind, I created some blueprints what exactly will be needed. First and most important requirement was to start creating separate library able to handle decentralized management of any cloud-related object.

Now main goal was to create tool able to keep copy of whole information on each single node, share it with others. Important thing was to implement within it decentralized authorization and authentication. I started looking for tools for that.

My original intent was to migrate CloudOver IaaS cloud to fully decentralized, P2P architecture. CloudOver was able to manage large infrastructures, but it had weak, central points. I wanted to remove that points and keep whole functionality as it was.

Then I've started looking for technologies and tools which could handle that. With all functional requirements and non-functional I had clear goals to achieve