Click here to Skip to main content
15,867,594 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I want a solution, suppose I have 3 module In MVC application running on production, which are accessible by common menu. There were update on 1st module. I want to publish only 1st module, so that the remaining 2 modules users are not impacted. Basically I don’t want to down my application for the users which are not using 1st module.
Is it possible to minimise the downtime by this way?
Once the updated module is plugged, then it get open for all users
Back end is oracle19c

Or any other way we can minimise the downtime for an application?

Is there really something called as zero downtime? If yes, then how can it be managed?

What I have tried:

Currently didn’t try anything. Know about CI/CD, but never tried
Posted
Updated 14-Sep-20 17:49pm

1 solution

Quote:
There were update on 1st module. I want to publish only 1st module, so that the remaining 2 modules users are not impacted.
You are looking at the microservices architecture requirement here. Each service is a separate project, a separate process, and is hosted separately; an update in one service does not require redeployment for other services.
Quote:
Is it possible to minimise the downtime by this way?
Depends, if each service is independent, then at least you have localized the downtime to each service itself. How each service manages the downtime, that is a different story at all. There is likely a downtime to happen if you update the service; the process needs to stop, update and restart.
Quote:
Or any other way we can minimise the downtime for an application?
You can try using blue-green deployments; where you start rolling out the updates to users gradually. This way, all the users are not impacted by the update. Some users continue to connect to and access the older version of your service. The updated instances are deployed and then traffic gradually starts to reach these pods; Kubernetes reference[^].
Quote:
Is there really something called as zero downtime?
Yes, there is a "logical" explanation of a zero downtime.
Quote:
If yes, then how can it be managed?
It works by using an orchestrator, so logically your service is always up but pods (processes) are created, update and destroyed in the background without your users knowing. I think this is a result of "networking" done right!

Then again, this depends on your infrastructure or platform and where you are hosting your service. If the platform supports this, then good, otherwise you might need to introduce other orchestrators (such as Kubernetes) to provide a zero-downtime.

Remember, for a good zero downtime, you need to use:

1. Stateless services
2. Out-proc database/session information (so users are not lost when the service updates)
3. Good orchestration service (Kubernetes?)

Good luck!
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900