Working with Independent Objects

The traditional way of writing and changing software has led to Continuous Deployment, a principle of automating the pipeline between writing source code and deploying the production artifact in a live environment, with a goal of reducing the time taken for changes to flow through the pipeline while maintaining a high level of quality.

Environments such as Pharo—https://pharo.org/, SqueakJS (https://squeak.js.org/run/#url=https://freudenbergs.de/bert/squeakjs&zip=[Squeak5.0-15113.zip,SqueakV50.sources.zip], or even in their limited ways Swift Playgrounds—https://www.apple.com/swift/playgrounds/ and Project Jupyter—https://jupyter.org/ show that this pipeline can be zero length, and that software can be written directly in the environment it is intended for. The result of a test failure does not need to be a log file served by Jenkins that must be pored over so a fix can be hypothesized in “l(fā)ocal dev”, it can be an opportunity to correct the program running in the live environment and continue (or, at worst, restart) the operation that failed.

This liveness property is not restricted to Smalltalk-like environments or REPLs. Consider the Mach microkernel operating system; any server that is registered to the name server (or, in the case of the HURD, as a translator on the filesystem) is a “l(fā)ive object” that can receive messages from the rest of the system and participate in its behavior. They are also tasks that can be inspected, debugged, changed, restarted, or replaced.

A server application composed of microservices presents similar properties. The “objects” (the running instances of the services) find each other by URL: whatever service is configured to receive HTTP requests at a given route “responds” to the “messages”. Each of these services can be independently inspected, debugged, edited, or replaced.