Summary
Microservices are often dependent on other microservices. If A -> B -> C
and someone uses Forge to start A
then B
and C
should be started as well.
Proposal
Add metadata to service.yaml
that allows encoding of service dependencies:
requires:
- service1
- service2
Then make forge deploy smart enough to expand the set of services being operated on to include dependencies. Because this is a network of services, this should be smart enough to handle dependency cycles. (These are organically grown runtime dependencies, not build time dependencies, so cycles are expected/ok.)
Add a concept of a workspace to forge. This can start out as whatever directory the forge.yaml is in. When forge is searching for services, it will first check the workspace, and then check git in order to deploy any dependent services.
The combination of these features allows forge to function as a "workspace manager" (kinda like an IDE in some ways) for microservices development.
Rationale
Based on at least one reddit post, people wonder about how to do this, so it is useful functionality and plausibly contributes to conversion. This is relatively cheap to implement and makes for a good blog aritcle and so contributes towards attention. This could be the basis of a combined example project that features ambassador + a network of services with a CI/CD pipeline that leverages both forge and ambassador, and so it contributes towards "Better Together".
Historical Context from Private Repository Comments
plombardi
How do you plan to actually handle dependency cycles? I'm not sure it's realistically doable or if you do attempt to solve that problem I think we might want to consider having a dumb option that ignores cycle detection and lets the services and Kubernetes use it's default strategy of start and fail until dependencies come up.
rhs
Mostly I just mean make sure forge doesn't stack overflow if there are dependency cycles. This would be necessary regardless of whether they are legal or not.
My thinking about cycles is this. Let's say there are two classes of dependencies: startup (service A needs service B to be operational in order to start) and runtime (service A doesn't need service B to start, but it does need service B to serve requests in some situations).
Obviously for startup dependencies, cycles are not possible to handle and should be illegal. For runtime dependencies, cycles aren't an issue since you just start everything up in any order and make sure it's all running before you hit any given service.
My comments were assuming that what we would start with was runtime dependencies and add in startup dependencies later.