While I was in Belgrade for WordCamp Europe, I took part in a meeting of a smaller group of core contributors to discuss the status and future of the Servehappy project. One topic we discussed was that the ideal end goal, from the end user’s perspective, would be to have an automatic updating mechanism that keeps the entire server automatically up-to-date and secure. While this might be a lofty goal, we wanted to nevertheless look into what would be necessary to make this a reality.
While we can already automatically update WordPress Core, as well as plugins and themes, we cannot do the same for the components of the WordPress stack that are installed at the server level. There’s currently no standardized protocol for server applications to request information about or changes to the underlying infrastructure. While we have APIs to provision such servers through code, we have no protocol or API to allow the applications that run on them to make changes after the provisioning.
I hereby suggest creating a communication protocol (tentatively called ASMP) between servers and applications that run on these servers that allows for bidirectional communication so that these two actors can coordinate.
Let’s look at a few examples
As an example, think about regular users managing a WordPress site. On the WordPress “Server setup” page in the admin backend, the end user would see the current PHP and MySQL versions used by WordPress, as well as potential notifications about available updates.
The available updates are calculated by querying ASMP about the
'mysql' components and then checking the returned ranges of supported versions against its own requirements.
When the user wants to run such an update, they click the corresponding button, which will have WordPress send an ASMP request to the server to
'set' the version of the
'php' component to the requested version.
Then WordPress can poll the ASMP state of that request to get updates. It could return states like
'rejected'` to let WordPress know how this is moving forward and adapt the user interface to give feedback to the user.
This would give more control to users, reduce support tickets for hosting providers and indirectly improve version distribution of the server components managed in this way.
As another example, think about developers that manage their project through a package manager like Composer or NPM. When you provision a server with a
composer install instruction, you could have Composer automatically make requests to the underlying server based on the
"require" statements that define the platform and extension requirements.
Composer could just as well throw an error when the server is not capable of providing the requested environment, and let the user know which components failed to resolve properly.
Planning the ASMP protocol and providing reference implementations should follow a few guiding principles:
- Applications can only make requests, not force any changes.
- There is no guaranteed support, servers are free to only provide partial implementations.
- Requests are asynchronous, they don’t return responses.
- State and capabilities can be queried, so that user interface and expectations can be adapted to the current server.
These guiding principles still allow for more exotic implementations, like a request to update a given component doing nothing more than creating a support ticket with required details. Hosting providers are free to choose the subset to implement and the specific way to implement it. The implementations can then grow from there and be further automated in time.
The transport to be used could be regular HTTPS, with a server environment variable providing the host to contact for queries and requests. This environment variable would point to
localhost when running on stand-alone servers, but could be deviated to centralized server for hosting providers that have more complex orchestration needs. The server environment should also contain an authentication mechanism, like a token, to make sure queries and requests can only be made from the correct server.
We should provide a reference implementation based on a common server distribution. This makes sure that it is easy for hosting providers to add support to their hosting and helps keep the experience consistent.
Also, focusing on building implementations into popular server control panels would accelerate adoption, as all servers managed through a given control panel would automatically inherit the implementation of the ASMP protocol.
I am in the process of introducing this as a proposal to the Cloudfest Hackathon which will be held on March 23-25, 2019 in Rust, Germany. If this gets accepted, it will probably be an immediate opportunity to collaborate with major hosting/control panel providers to build a working prototype. Anyone who is interested in participating in this endeavor and willing to travel to Germany for the occasion can still apply for the hackathon.