Picos are persistent compute objects. Persistence is a core feature of how picos work. 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 state that programs running in the pico can see and alter. Pico 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 response to a received message,
Picos send messages to other picos—Picos respond to events and 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 received)—Each pico has a set of persistent variables that can only be affected by rules that run in response to events.
Despite 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 picos. 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 event expressions. Event expressions can specify simple, single-event matches, or complicated event relationships with temporal ordering. Rules whose event expressions match are scheduled for execution. Executing rules may raise additional events. More detail about the event loop and pico execution model 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 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 functionality2. More importantly, an application built on 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 number of picos. This provides a better, more scalable model for IoT that the current CompuServe of Things. Pico-based applications are fully sharded, meaning there is a computational node for every entity of interest. Picos provide an architectural model that supports trillion-node networks where literally everything is online.
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 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 system. 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 programming patterns that 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.
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 sell you 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 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 self-sovereign internet of things (SSIoT) because they support autonomic architectures. Picos create an IoT architecture that allows interoperable interactions between devices from different manufacturers.
Use Picos
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 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.
