<p>We had a similar situation wherein one of our applications had to be built, deployed and be up &amp; running before the second one was. This was because application A has some functionality that should be executed prior to it being referenced via application B.
The way we accomplished this was by building it into a single delivery pipeline. That way, all the dependencies were deployed either sequentially or parallely as needed. We also had our database scripts in sequence along with rollback capabilities, just in case.
Rewording to your case, you could deploy your api prior to your front-end service.
Hope this helps.</p>

CC BY-SA 4.0
2018-07-23T01:55:08.857Z
2018-07-23T01:55:08.857Z
Karthik Venkatesan
<p>The solution here is to deploy the micro services using the blue/green deployment pattern.</p>

CC BY-SA 4.0
2018-09-12T20:33:23.090Z
2018-09-12T20:33:23.090Z
Kaymaz
<p>Such question could be an indication of a poor architectural slicing into microservices. From <a href="https://www.martinfowler.com/microservices/#what" rel="noreferrer">What are Microservices?</a>:</p>

<blockquote>
  <p>These services are <strong>built around business capabilities</strong> and
  <strong>independently deployable</strong> by fully automated deployment machinery.</p>
</blockquote>

<p>The key point missed in such case would be their <strong>independently deployable</strong> aspect. </p>

<p>The point could also be simply misunderstood: it doesn't necessarily mean that each microservice should be capable to perform its entire functionality by itself, it just means that it's able to gracefully bail when some other microservice its functionality depends on isn't available, maybe keeping track of "todo" stuff for later execution, when that microservice becomes available. </p>

<p>Seen from a different perspective: handling unavailability of external service dependencies should actually be part of each microservice functionality - so one could consider the microservice fully functional even when its runtime dependencies aren't satisfied :)</p>

<p>It's worth noting, I think, that in the above comments I'm referring to microservices unavailability regardless of its reason, be it deployment dependency order or something else (outages, for example). </p>

<p>Another thing to consider would be the finer difference between deploying the microservices and bringing them into action by switching the traffic to them. Switching traffic is often faster than the deployment itself, so the availability at the entire system level can be increased by first deploying all microservices and only after that performing the traffic switch for all of them. </p>

CC BY-SA 4.0
2018-07-23T12:16:11.633Z
That's what I thought! Thank you very much for these explanations.
Kaymaz
CC BY-SA 4.0
2022-12-01T06:54:09.293Z
The OP's situation may or may not be due to "poor architectural slicing". It is a realistic situation. The 2nd edition of "Building Microservices" concedes as much: "Domain coupling describes a situation in which one microservice needs to interact with another microservice, because the first microservice needs to make use of the functionality that the other microservice provides...In a microservice architecture, this type of interaction is largely unavoidable."
ottodidakt
CC BY-SA 4.0
2023-05-11T12:39:58.717Z
It's true that microservices should be deployable independently, but when microservice X requires microservice Y, and microservice Y is down, microservice X will typically provide limited set of functionalities (e.g. return no data or some old data from cache).
Sometimes deploying multiple dependant microservices one after another makes sense, e.g. during creating a new environment (e.g. for new on-prem customer), or during creating temporary environment for end to end testing. And sadly I haven't seen a good solution to that.
iirekm
CC BY-SA 4.0
2018-07-22T15:14:58.400Z
2018-07-23T12:56:33.133Z
2018-07-23T12:56:33.133Z
Dan Cornilescu
<p>We want to deploy multiple microservices on AWS ECS.</p>

<p>The issue that we need to solve is how to deploy them in an atomic way: </p>

<p>Let says we have the front-end services which requires the user service version 2.0.</p>

<p>How to make sure the user service is available before the front-end one is deployed.</p>

<p>We have the idea to replicate the whole infra, deploy everything then make it available. But it seems to me complex. How do you make these spare instances, deploy the services, and make the switch?</p>

<p>We are using two ALB and target groups for each services (dynamic port mappings).</p>

CC BY-SA 4.0
2022-12-01T07:12:38.197Z
Related: https://www.architect.io/blog/2020-09-16/why-distributed-apps-need-dependency-management/
ottodidakt
<docker><deployment><microservices><amazon-ecs>
How to deploy multiple dependent micro services
Kaymaz
# How to deploy multiple dependent micro services

(Asked by: username_0 on 2018-07-22)

We want to deploy multiple microservices on AWS ECS.

The issue that we need to solve is how to deploy them in an atomic way:

Let says we have the front-end services which requires the user service version 2.0.

How to make sure the user service is available before the front-end one is deployed.

We have the idea to replicate the whole infra, deploy everything then make it available. But it seems to me complex. How do you make these spare instances, deploy the services, and make the switch?

We are using two ALB and target groups for each services (dynamic port mappings).

**Tags:** docker, deployment, microservices, amazon-ecs

> **Comments:**
> **username_1**: Related: https://www.architect.io/blog/2020-09-16/why-distributed-apps-need-dependency-management/  

---

## 3 answers

### Answer by username_3 on 2018-07-22. Score: 8 | Accepted answer

Such question could be an indication of a poor architectural slicing into microservices. From [What are Microservices?](https://www.martinfowler.com/microservices/#what):

> These services are **built around business capabilities** and
> **independently deployable** by fully automated deployment machinery.

The key point missed in such case would be their **independently deployable** aspect.

The point could also be simply misunderstood: it doesn't necessarily mean that each microservice should be capable to perform its entire functionality by itself, it just means that it's able to gracefully bail when some other microservice its functionality depends on isn't available, maybe keeping track of "todo" stuff for later execution, when that microservice becomes available.

Seen from a different perspective: handling unavailability of external service dependencies should actually be part of each microservice functionality - so one could consider the microservice fully functional even when its runtime dependencies aren't satisfied :)

It's worth noting, I think, that in the above comments I'm referring to microservices unavailability regardless of its reason, be it deployment dependency order or something else (outages, for example).

Another thing to consider would be the finer difference between deploying the microservices and bringing them into action by switching the traffic to them. Switching traffic is often faster than the deployment itself, so the availability at the entire system level can be increased by first deploying all microservices and only after that performing the traffic switch for all of them.

> **Comments:**
> **username_0**: That's what I thought! Thank you very much for these explanations.  
> **username_1**: The OP's situation may or may not be due to "poor architectural slicing". It is a realistic situation. The 2nd edition of "Building Microservices" concedes as much: "Domain coupling describes a situation in which one microservice needs to interact with another microservice, because the first microservice needs to make use of the functionality that the other microservice provides...In a microservice architecture, this type of interaction is largely unavoidable."  
> **username_4**: It's true that microservices should be deployable independently, but when microservice X requires microservice Y, and microservice Y is down, microservice X will typically provide limited set of functionalities (e.g. return no data or some old data from cache). Sometimes deploying multiple dependant microservices one after another makes sense, e.g. during creating a new environment (e.g. for new on-prem customer), or during creating temporary environment for end to end testing. And sadly I haven't seen a good solution to that.  

---

### Answer by username_2 on 2018-07-23. Score: 1

We had a similar situation wherein one of our applications had to be built, deployed and be up & running before the second one was. This was because application A has some functionality that should be executed prior to it being referenced via application B.
The way we accomplished this was by building it into a single delivery pipeline. That way, all the dependencies were deployed either sequentially or parallely as needed. We also had our database scripts in sequence along with rollback capabilities, just in case.
Rewording to your case, you could deploy your api prior to your front-end service.
Hope this helps.


---

### Answer by username_0 on 2018-09-12. Score: 1

The solution here is to deploy the micro services using the blue/green deployment pattern.


---

