This is the start of a series of posts around a new Principle I came up with some months ago, and which I have been refining up to the preliminary form I present here for the first time in public. Hopefully comments and suggestions help either to throw it away for useless, or to make it a valid alternative to produce new software.
Inspiration
The Holographic Principle in software is inspired by the Holographic Principle in Physics, more specifically in Cosmology and Quantum Gravity. In essence, it states that all the information we may get about certain Spacetime volumes (the so-called hidden regions, which are completely forbidden to probe by all external observers) is the information encoded in the surface which encloses the volume. The most common case of these volumes are black holes, whose Event Horizons enclose all the information we might ever gather from them.
Here you have a short video explaining all this, from Quanta Magazine:
The Holographic Principle in software
In short, what this Principle says is that everything we may know about a given Service must come from the contact surfaces it holds to any other Service.
The Contact surface between two Services is the collection of all contracts between them on behalf of which their relationship takes place. No further restrictions on the kind of these relationships, or their actual implementation, are imposed by the Principle.
In other words, what the Holographic Principle states is that any Service’s internals, meaning any information about it which is not needed to fulfil the conditions of any of its contracts with its Related Services (any Service with which a contact surface exists), must be kept hidden.
The meaning of the Holographic Principle
The Holographic Principle is not new technology, just a different way of organising the moving pieces which we are already dealing with when handling software.
In summary, the Holographic Principle proposes a shift in our common view of decoupled applications, focused on semantics and operations with entities, to a new relation-centric view. In other words, Holographic software deals more with relationships among services, that with the data actually transferred.
An example: a Cat Picture service
Let’s start with a Cat Picture service which allows Users to send, store, and collect pictures of cats. In its persistence layer, our Cat Picture service would assign a uuid to every picture, as well as other attributes it may consider of interest for those aforementioned Users.
So Cat Picture service exposes two main endpoints:
- POST https://cat-picture.service/cat-picture/ + {data + metadata}, which will store new Cat pictures, assign them a new uuid, and response with these to the User which sent them in the Request.
- GET https://cat-picture.service/cat-picture/{uuid}, which will response with the nice Cat picture assigned with the given uuid in a previous request to the POST endpoint above.
This Cat Picture service would likely expose other convenient endpoints, for instance:
- GET https://cat-picture.service/health, to provide a health check of itself.
- DELETE https://cat-picture.service/{uuid}, to delete the resource assigned with a given uuid.
- Etc.
We may also secure this Cat Service so that only authorised Users may make use of it to store their pictures, which means that an authentication phase must be completed successfully somehow, before any of the former endpoints may be requested.
In addition, we may gather stats information about those Users, as well as of the whole usage of the Cat Picture service (date and time during the day, geolocation of Users, etc).
Now let’s talk about the same Cat Picture service under the Holographic Principle.
First of all, Cat Picture service publisher should advertise the Service so that it is available for discovery in the market. Don’t freak out with those terms, just translate them to deploy into production, and the application, if you need to stay in a more recognisable scenario.
Once available for discovery, Cat Picture service might be contacted by other Services around in seek of a potential provider for cat pictures storage. An interested Service BB would then open a contract negotiation with Cat Picture service and, eventually, a contract may be signed between both. This contract should stipulate under which conditions BB may make use of the features provided by Cat Picture service, as well as which kind of retribution (call it gas, if you like Ethereum terminology, or simply a fee), the period of time Cat Picture service would accept requests from BB, the maximum number of requests per hour accepted before a denial of service signal would be sent, etc.
All these steps fulfilled, BB may start sending requests to the Cat Picture service. Since no other than its own pictures might be collected from the Cat Picture service, the first request must be one of this:
- POST https://cat-picture.service/cat-picture/ + {data + metadata}, which will store new Cat pictures, assign them a new uuid, and response with these to the User which sent them in the Request.
But now the uuid produced by the Cat Picture service, and sent to BB afterwards in its Response, is not the uuid of the Picture in its persistence layer, but a uuid identifying uniquely the request with BB. These transaction ids are not unique per Picture, because in that case they would expose Cat Picture internals to BB (at least), exposition which is forbidden by the Holographic Principle.
From the point of view of BB, these transaction ids might be seen as common uuids. But they might be not, because BB may be storing the same pictures in another Cat Picture service. Also, it may likely have an internal uuid assigned to them, which are supposed to be permanent while the transaction id which relates them to the Cat Picture Service are temporary.
Once stored in the Cat Picture service, this other endpoint is also available to BB:
- GET https://cat-picture.service/cat-picture/{trans-uuid}, which will response with the nice picture which POST transaction got the trans-uuid unique identifier.
Further details of this examples, as well as other examples, are coming in the second instalment in this series.
Benefits of the Holographic Principle
The most immediate benefit of applications following the Holographic Principle is that the focus is kept on the relationships among services instead of on the data they share. This allows service providers to set security access levels, as well as service usage quotas, to individual services instead of per roles.
Also, since every url brings information about the requester service as well as about the resource being handled, it provides service providers with additional instruments to secure its services.
Afterword
This is the first of a series if posts I am writing about some specifics of the Holographic Principle. But please do not hesitate to send me your comments, our collected minds are surely far more smart than mine alone.
Photograph credit: https://pixabay.com/users/deselect-521336/
how possible 