How you deploy applications can make you lose the reliability and trust of users. This makes you lose the users of your applications. Why am I saying this?
Consider a fintech application that people use in making transactions in their day-to-day activities, and it suddenly just stopped working one day. Your activities will be disrupted that day. You may not be able to buy things or make payments. Now, what about Social media apps like Facebook, WhatsApp, Twitter, and the like?
If these platforms were to cease functioning unexpectedly, users would face disruptions in their ability to connect with others, share information, and stay updated on social interactions. The reliance on these social media platforms for communication and information exchange makes their uninterrupted functionality crucial to the seamless flow of daily life for many people.
Before deploying an application into production, it has to be tested.
Why must it be tested?
Because you are taking into account the end users using the application.
Fix bugs on the app.
You check if they love the new feature you are adding to the application.
Put out a new version to users.
Various strategies are used to help us in deploying applications.
I will be talking about FOUR strategies.
BASIC/BIG BANG DEPLOYMENT
This type of deployment is when the old version of the application is changed to a new version. What is going on here? It's simply saying that the old version of the application is replaced with a new version of the application just once.
Before this type of deployment process takes place, the users of the application must be well-informed about the process that is to take place. This deployment process must take place, at a time when most of the users are not using the application for example, at night.
This way of deployment is for applications that are used internally in an organization. But as we all know everything in life has risk. so what are the risks of this deployment style?
RISKS OF BIG BANG DEPLOYMENT/BASIC DEPLOYMENT
Users are the ones who will find bugs in the application.
There will be downtime in the application.
But I am so sure business owners/software developers/software engineers never want their applications to be down for once.
BLUE/GREEN DEPLOYMENTS
Here, two production environments are maintained.
But why is it called the Blue/Green deployment? The blue one is an application that is currently live i.e. Being used by users. The green one is not live, it's still in production. The green one is tested thoroughly.
For example, you can try to simulate real-life traffic to it and you can see the response, this will help you discover bugs in the application.
After you are done with the testing. You can then switch the traffic from the green environment to the blue environment. Note, that the green environment becomes the blue environment, and the blue environment becomes the green environment. This deployment strategy has minimal downtime and it can be good for fintech, Healthcare, sass, and gaming applications. What are the risks involved?
RISKS OF BLUE/GREEN DEPLOYMENT
You have to maintain double infrastructure
This means if you have five databases on the blue side it must also be five databases on the green side. If you have 2 balancers on the blue side you must also have 2 balancers on the green side.
It can be expensive because you will need to maintain two infrastructures.
You have to keep them in sync.
It means whatever changes you do on the green side must be done on the blue side. (But thanks to Terraform this can be easily solved).
CANARY DEPLOYMENTS
This type of development is used when you have an application already in production and you want to deploy a new version of the app without any downtime of the application.
You simply deploy a new version of the app to a subset or region of people using that application, while the remaining set of people keep on using the old version.
This will help you in knowing if they like it. You would simply know if the new version of the app is accepted. If it is accepted you can change it and if it's not you pull it off from production and continue using the live one used.
This type of deployment process is used in large-scale web applications like YouTube, Twitter, TikTok e.t.c What are the risks involved?
RISKS OF CANARY DEPLOYMENT
This deployment can include complexities like splitting of traffic and splitting of load balancers.
There will be a risk of losing that subset of users if not liked.
Additional infrastructure and tooling are needed to manage the user segments.
A/B DEPLOYMENT
This is when two versions of the application are both live in production. But are different in some type of ways maybe in the user interface.
But are different in some type of ways maybe in the user interface. You can deploy 50% of an application with a different UI or different features and another 50% of the application with another UI or other features.
This is done to collect metrics or to check how each version performs against a specific goal. Then the one that performs well and aligns with the goal remains in production and the other one is brought down.
RISKS
- This deployment can include complexities in the splitting of traffic, splitting of load balancers, and many others.
IN CONCLUSION
All types of deployment have their own risk there are no good or bad ones. But always go for the one that applies to your present needs.