Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploy Service Dependencies #16

plombardi89 opened this issue Jul 6, 2017 · 0 comments

Deploy Service Dependencies #16

plombardi89 opened this issue Jul 6, 2017 · 0 comments


Copy link

@plombardi89 plombardi89 commented Jul 6, 2017


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.


Add metadata to service.yaml that allows encoding of service dependencies:

  - 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.


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


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.


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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants