Eden is a decentralized, autonomous, portable, secure virtual infrastructure for managing clustered workloads over Depos (decentralized pods) and services facilitating declarative configuration and automation.
Basically, Eden is a private online Edge Cluster developed around a sustainable computing core.
It is important to understand how the Internet has evolved and why it is necessary to adjust for embedded systems to reach its full potential.
Historically, organizations ran applications on physical servers at the beginning of the Internet era. There was no way to define resource boundaries for services in a physical server, and this caused resource allocation issues.
For example, if multiple services run on a physical server, there could be instances where one service would take up most of the resources, and as a result, the other services would underperform.
A solution would be to run each service on a different physical server. But this did not scale, as resources were underutilized, and it was expensive for organizations to maintain many physical servers.
So then we all went in for virtualization. It allowed us to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization will enable services to be isolated between VMs and provide security, as another service cannot freely access the information of one service.
Virtualization allows better utilization of resources in a physical server and better scalability because a service can be added or updated easily, reduces hardware costs, and much more. With virtualization, you can present a set of physical resources as a cluster of disposable virtual machines. Each VM is a full machine running all the components, including its operating system, on top of the virtualized hardware.
Then came the container deployment era; containers are similar to VMs but have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight in overhead processing.
Similar to a VM, a container has its filesystem, the share of CPU, memory, process space, and more. They are decoupled from the underlying infrastructure and portable across clouds and OS distributions.
When we looked at the Internet's development, we noticed one destructive factor for future deployments; you always move the data to a centralized point; this works great for web and cloud services inherently centralized.
For the Internet of Things, it makes little sense to move all data in-processed from the IoT devices to a central point for processing and then move the data back out to devices again for actuation.
This is bad for real-time responses, but achieving sustainable computing is nearly impossible. The cost of running an embedded service becomes increasingly larger with each device added.
So the more data your service produces, the more transport, processing, and storage you will need and the more you will pay, making a cloud approach far from sustainable from a cost perspective.
So, we based the Eden design on a decentralized model based on scalable device clustering. Where data is processed to information locally in the Eden Edge Cluster so that raw data is never needed to be pushed to the public cloud, a compute-efficient, and cost-effective model by saving on bandwidth and external resources.
It is easy to add new devices as nodes and makes it possible for any device to contribute computing resources over an intelligent mesh network so that computing can happen where needed and close to where the results will be used.
We then developed quantum-safe tunnels using polymorphic encryption keys and a consensus blockchain to verify the data moved between the nodes over the tunnels, thus creating trusted data private gardens and achieving data trust in Zero-Trust environments.
The orchestration of computing and storage is done via service manifests that describe service rules, policies, and logic. An autonomous knowledge-based AI manages the underlying orchestration mechanics using network consensus over the blockchain as a deciding mechanism.
The orchestration dynamically updates the cluster topography to fit the current workload. Eden Depo services are generated and deployed similarly to container images; the exception lies in that Eden is Messaging Passing Interface (MPI), and the AI cluster is enabled as a default.
The Service Manifest generation is the only addition to standard container deployment.
Provide reliable and frequent Depo build and deployment with quick and efficient rollbacks (due to the Depo's deployment being registered on a system-wide blockchain).
Create service depo's at build/release time rather than deployment time, thereby decoupling services from infrastructure.
Not only clusters information and metrics but also applications' health and other signals.
Runs the same on a laptop as in the wild.
It runs on Linux, BSD, on-premises, public clouds, and anywhere else.
Raises the level of abstraction from running an OS on virtual hardware to running a service on a Decentralized network.
It is not a monolithic stack running on one big single-purpose machine.
Predictable service performance.
High efficiency and density.
Through validated cryptographic modules.
Using blockchain validation.
Decentralized Private Online Garden systems running Depo services are a secure and flexible way to bundle and run your services. In a typical production environment, you need to manage the containers that run your applications and ensure no downtime. For example, another container needs to start if a container goes down.
Is it easier if the system handled this behavior?
That's how Eden works!
Eden provides a system and a framework to run distributed services that are decentralized and resilient. The Eden orchestrator takes care of scaling and failover for your services, provides deployment patterns, etc.
Eden is fully decentralized; DDoS attacks are mitigated, as there are no centralized points to attack.
As malware tries to replicate itself to other nodes, it can be detected and the infected node identified via data transfer checksum consensus on a blockchain, as the checksums of transmitted data will not match the received data amounts over the nodes.
Using verification and sanity checks on data amounts entering and transported over Eden.
Eden lets you store and manage sensitive information, such as passwords, OAuth tokens, and encryption keys. You can deploy and update secrets and application configuration without rebuilding your Depos and exposing secrets in your service.
Eden can expose a service using the Service name from the service manifest or using their Eden service or over their IP address. Even though using the IP directly is not recommended, the data validation's security benefits are muted. If traffic to the service is high, the orchestrator will load balance and distribute the network traffic so that the service performance is consistent.
You provide Eden with the size of the starting cluster of nodes that it can or should use to run service tasks. Then Eden will optimize how much CPU and memory (RAM) each task needs.
You can describe the desired state (rules, policies, and logic) for your deployed services using Service Manifests. It can change the actual state to the desired state at a controlled rate. For example, you can automate Eden to create new services for your deployment, remove existing Depos and adopt all their resources to the new service.
The Eden Orchestrator restarts Depos that fail; it can replace Depos on the fly. It kills Depos that don't respond to the service manifest-defined health check and advertise them to users when the service is ready to serve.
Eden is not a traditional, all-inclusive PaaS (Platform as a Service) or IaaS (Infrastructure as a Service) system. Instead, Eden is a secure private online garden solution that operates at the service level rather than the hardware level.
It provides features common to PaaS and IaaS offerings, such as deployment, scaling, and load balancing
However, Eden is not monolithic, and these default solutions are optional and pluggable. Eden provides the building blocks for building and deploying services but preserves user choice and flexibility where it is essential.
Eden aims to support various workloads, including stateless, stateful, and data processing. A service that runs from a container image should run great on a depo.
Continuous Integration, Delivery, and Deployment (CI/CD) workflows are determined by organizational cultures, preferences, and technical requirements.
It provides integrations as help and mechanisms to collect and export metrics.
Eden provides a declarative Service Manifest system.
Eden uses AI, so you do not need to worry about the mechanics.
Eden is though not a mere orchestration system. In one way, it eliminates the need for classic orchestration:
In contrast, Eden comprises a set of independent, composable control AI-controlled processes that continuously drive the current state towards the Service Manifest provided desired state.
It shouldn't matter how you get from A to C.
With Eden, centralized control is not required; this results in an easier, more powerful, robust, resilient, and extensible system.
