There was some discussion about this in slack last week. @mlaventure suggested it would be good to update this thread with a summary of that discussion.
First, this proposal assumed that the primary goal was to split up the monolith. That is a goal, but it sounds like it's not necessarily the primary focus. The primary focus could be to bring in new components along side the monolith, where the monolith acts as a single large component until it can be split up.
With this alternative focus, the option of porting the entire V1 Engine API to gRPC would make the monolith look like just another component.
This raised question about "what is a moby component". The current working definition is that it's a binary that exposes a gRPC interface. Some components will be "init" components which are run outside of a container (ex: containerd), and others are "service" components which are run as containerd containers.
So how does this proposal change given the new focus?
We need to investigate:
- How long it would take to port the entire engine API to gRPC (considering we can not freeze it until it is completely ported). My estimate is that it's still a multi-month project.
- Once we have a gRPC APi definition are we able to generate a golang HTTP proxy that perfectly mirrors the existing V1 REST API? Many things like hijacking for log streams, build output, and attach are difficult to represent.
If we're able to represent the V1 REST API using a gRPC definition, then we could replace the current API with this generate code, but that still leaves open the question of how users will migrate. The immediate monolith gRPC interface would not be the final interface, it would eventually get replaced by the individual smaller component interfaces.
So the actual migration options would be:
- The original proposal (but delayed until after we migrate the engine API to gRPC)
- Migrate first from REST V1 -> monolith gRPC, then from monolith gRPC -> component gRPC
I doubt anyone will be interested in migrating twice.
Given the discussion and change of focus, I don't think this proposal needs to change. The only question is if the priority should be to make the monolith appear like other components first, or to split it up first. Either way, users options for transiting to a new API remain about the same.