Eden is a decentralized, autonomous, portable, secure, virtual infrastructure for managing clustered workloads over Depo’s (decentralized pods) and services facilitating declarative configuration and automation. Basically, Eden is a private online Edge Cluster developed around a sustainable computing core.
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 the information of one service cannot be freely accessed by another service. Virtualization allows better utilization of resources in a physical server and allows 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 they 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; they are portable across clouds and OS distributions.
When we looked at this 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 that are inherently centralized. For the Internet of Things, it does not make that much 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 IoT service becomes increasingly larger with each device added, as cloud providers charge you for data transport, processing, and storage.
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 make it possible for any device to contribute computing resources over an intelligent mesh network so that computing can happen where it is 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 services 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.
· Agile service creation and deployment: only addition to a standard container deployment is the Service Manifest generation.
· Continuous development, integration, and deployment: Provides for 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).
· Dev and Ops separation of concerns: create service depo’s at build/release time rather than deployment time, thereby decoupling services from infrastructure.
· Observability Not only clusters information and metrics but also applications health and other signals.
· Environmental consistency across development, testing, and production: Runs the same on a laptop as in the wild.
· Cloud and OS distribution portability: Runs on Linux, BSD, on-premises, public clouds, and anywhere else.
· Service-centric management: Raises the level of abstraction from running an OS on virtual hardware to running a service on a Decentralized network.
· Loosely coupled, distributed, elastic, Service-oriented Architecture: not a monolithic stack running on one big single-purpose machine.
· Resource isolation: predictable service performance.
· Resource utilization: High efficiency and density.
· NIST and FIPS compliant through the use of validated cryptographic modules.
· Zero-Trust communications 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 that there is no downtime. For example, another container needs to start if a container goes down. Wouldn't it be easier if the system handled this behavior?
That's how Eden works! Eden provides a system and a framework to run distributed services decentralized and resilient. The Eden orchestrator takes care of scaling and failover for your services, provides deployment patterns, etc.
Eden provides you and your users with:
· Defense against denial of service attacks, Eden is fully decentralized, DDOS attacks are mitigated, and there are no centralized points to attack.
· FIPS and NIST compliant and certified.
· Detection of Malware, as malware tries to replicate itself to other nodes, the malware 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.
· Bad data and player detection using verification and sanity checks on data amounts entering and transported over Eden.
· Service discovery and dynamic load balancing, 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 security benefits of the data validation are then 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.
· Automated rollouts and rollbacks, 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.
· Automatic scaling, 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.
· Self-healing, 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.
· Secret and configuration management, 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.
What Eden is not:
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 service but preserves user choice and flexibility where it is essential.
· Does not limit the types of services supported. Eden aims to support various workloads, including stateless, stateful, and data-processing. If a service can run from a container image, it should run great on a depo.
· Eden does not deploy source code and does not build your application. Continuous Integration, Delivery, and Deployment (CI/CD) workflows are determined by organizational cultures, preferences, and technical requirements.
· Does not dictate logging, monitoring, or alerting solutions except for security concerns. It provides integrations as help and mechanisms to collect and export metrics.
· Does not provide nor mandate a configuration language/system. It provides a declarative Service Manifest system.
· Does not provide nor adopt any comprehensive machine configuration, maintenance, or management. It uses AI so that you do not need to worry about the mechanics.
· Eden is though not a mere orchestration system. In fact, in one way, it eliminates the need for classic orchestration. The technical definition of orchestration is the execution of a defined workflow: first, do A, then B, then C. 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. Centralized control is also not required; this results in a system that is easier to use and more powerful, robust, resilient, and extensible.