Picos are persistent compute objects. Persistence is a core feature of how picos workthat distinguishes picos from other programming models. Picos exhibit persistence in three ways. Picos have:
Persistent identity—Picos exist, with a single identity, continuously from the moment of their creation until they are destroyed.
Persistent state—Picos have persistent state that programs running in the pico can see and alter. Pico The state is unavailable outside the pico.
Persistent availability—Once a pico is created, it is always on and ready to process queries and events.
Picos support an actor model of distributed computation. Picos have three important, core behaviors. In Persistent identity, state, and availability make picos ideal for modeling entities. Applications are formed by cooperating networks of picos, creating systems that better match programmer’s mental models. Picos employ the actor model abstraction for distributed computation. Specifically, in response to a received message,
Picos send messages to other picos—Picos respond picos—Picos respond to events and queries by queries by running rules. Depending on the rules installed, a pico may raise events for itself or other picos.
Picos create other picos—Picos can create and delete other picos, resulting in a parent-child hierarchy of picos.
Picos change their internal state (which can affect their behavior when the next message is received)—Each pico has a set of persistent variables that can only be affected by rules that run in response to events.
Despite In addition to the parent-child hierarchy, picos can be arranged in a heterachical network for peer-to-peer communication and computation. As mentioned, picos support direct asynchronous messaging, sending requests and events to other picosA cooperating network of picos reacts to messages, changes state, and sends messages. Picos have an internal event bus for distributing those messages to rules installed in the pico. Rules in the pico are selected to run based on declarative event expressions. The pico matches events on the bus with event scenarios declared in the each rule’s event expressions. Event expressions can specify simple, single-event matches, or complicated event relationships with temporal ordering. Rules whose event expressions match are Any rule whose event expression matchs is scheduled for execution. Executing rules may raise additional events. More detail about the event loop and pico execution model are are available elsewhere.
Here are ten reasons picos are a great development environment for building decentralized applications:
Picos can be a computational node that represents or models anything: person, place, organization, smart thing, dumb thing, concept, even even a pothole. Because picos encapsulate identity and state, they can be used to easily model entities of all types.Picos naturally support a Reactive programming model. Reactive programming with picos directly addresses the challenges of building decentralized applications through abstractions, programming models, data handling, protocols, interaction schemes, and error handling1. In a pico application, distribution is first class and decentralization is natural.
Picos use a substitutable hosting model. Picos are hosted on the open-source pico engine. Picos can be moved from pico engine to pico engine without loss of functionality 2or a change in their identifying features1. More importantly, an application built on using picos can employ picos running on multiple engines without programmer effort.
Pico-based applications are scalable. Picos support a decentralized programming model which ensures that an application can use any whatever number of picos . This provides a better, more scalable model for IoT that the current CompuServe of Things. it needs without locks or multi-threading. Pico-based applications are fully sharded, meaning there is a computational node with isolated state for every entity of interest. Because these nodes can run on different engines without loss of functionality or programmer effort, pico-based applications scale fluidly. Picos provide an architectural model that supports for trillion-node networks where literally everything is online. This provides a better, more scalable model for IoT than the current CompuServe of Things.
Picos support high availability in spite of potentially unreliable hosting. Multiple picos, stored in many places can be used to represent a specific entity. Picos modeling a popular web page, for example, could be replicated countless times to ensure the web page is available when needed with low latency. Copies would be eventually consistent with one another and no backups would be needed.
Picos are naturally concurrent without the need for locks. Each pico is an island of determinism that can be used as a building block for non-determinant decentralized systemsystems. Each pico is isolated from any other pico, asynchronous processing is the default, and facts about the pico are published through protocols. State changes are determined by rules and respond to incoming messages seen as events. This minimizes contention and supports the efficient use of resources.
Picos provide a cloud-native (internet-first) architecture that matches the application architecture to cloud model. The pico programming model lets developers focus on business logic, not infrastructure. Applications built with picos don’t merely reside in the cloud. They are architected to be performant while decentralized. Picos support reactive support reactive programming patterns that patternsthat ensure applications are decoupled in both space and time to the extent possible.
Picos support stateful, databaseless programming. They model domain objects in code, not in database tables. Developers spend no time setting up or configuring a database. Each ruleset forms a closure over the set of persistent variables used in it. Programmers simply use a variable and it is automatically persisted and available whenever a rule or function in the ruleset is executed.
Picos use an extensible service model where new functionality can be layered on.Functionality within a pico is provided by rules that respond to events. An event-based programming model ensures services inside a pico are loosley coupled. And isolation of state changes—not just between picos—but between services (implemented as rulesets) inside the pico ensure a new service can be added without interfering with existing services. New rules can co-select on events with existing rules without the programmer changing the control flow3.
Picos naturally support a Reactive programming model. Reactive programming with picos directly addresses the challenges of building decentralized applications through abstractions, programming models, data handling, protocols, interaction schemes, and error handling2. In a pico application, distribution is first class and decentralization is natural. You can read more about this in Building Decentralized Applications with Pico Networks.
Picos provide better control over terms, apps, and data. This is a natural result of pico model where each thing has a closure over services and data. Picos cleanly separate the data for different entities. Picos, representing a specific entity, and microservices, representing a specific business capability within the pico, provide fine grained control over data and its processing. For example, if you you sell you your car, you can transfer the vehicle pico to the new owner, after deleting the trip service, and its associated data, while leaving untouched the maintenance records, which are stored as part of the maintenance service in the pico.
Picos use an extensible service model where new functionality can be layered on. Functionality within a pico is provided by rules that respond to events. This programming model allows services inside a pico to be loosley coupled. And isolation of state changes—not just between picos—but between services (implemented as rulesets) inside the pico ensure a new service can be added without interfering with existing services. New rules can co-select on events with existing rules without the programmer changing the control flow.Picos provide a better mode model for building the Internet of Things. By representing an entity and allowing multiple copies to be created for like entities, picos provide persistently available data and services for things even when they’re not online. Picos are a natural building block for the selfthe self-sovereign internet of things (SSIoT) because they support autonomic support autonomic architectures. Picos create an IoT architecture that allows interoperable interactions between devices from different manufacturers.
...
If you’re intrigued and want to get started with picos, there’s a Quickstart along with a series of lessons. If you need help, contact me and contact me and we’ll get you added to the Picolabs Slack. We’d love to help you use picos for your next distributed application.
If you’re intrigued by the pico engine, the pico engine is an open source project licensed under a liberal MIT license. You can see current issues for the pico engine here. Details about contributing to the engine are in the repository’s README.
Notes
I first heard this expressed by Jonas Bonér in his Reactive Summit 2020 Keynote.
The caveat on this statement is that pico engines currently use URLs to identify channels used for inter-pico communication. Moving to a different engine could change the URLs that identify channels because the domain name of the engine changes. These changes can be automated. Future developments on the roadmap will reduce the use of domain names in the pico engine to make moving picos from engine to engine even easier.
...
.
I first heard this expressed by Jonas Bonér in his Reactive Summit 2020 Keynote.
Note that while rules within a ruleset are guaranteed to execute in the order they appear, rules selected from different rulesets for the same event offer no ordering guarantee. When ordering is necessary, this can be done using rule chaining, guard rules, and idempotence.