We have recently published a whitepaper on commonly used Continuous Delivery Patterns. Within the whitepaper, we discuss each pattern and their core concepts. We wanted to follow up with a blog on the pros and cons of 5 of the more popular continuous delivery patterns mentioned in the whitepaper.
Pros and Cons of Blue/Green Deployment and Canary Release
Pros
ALLOWS FOR TESTING IN A LIVE PRODUCTION ENVIRONMENT.
Often times, the new version of the application will work swimmingly on a local machine or even a single AWS server. However, when deploying to a larger more sophisticated infrastructure, there can be unforeseen complications. A Blue/Green Deployment or Canary Release strategy allows for teams to perform “in the field” testing and ensure that the application is functioning as expected on live production servers before it reaches users.
ALLOWS FOR ZERO OR MINIMAL DOWNTIME DEPLOYMENT.
Traditionally, cutting over to a new application causes users to experience a period of downtime. When utilizing Blue/Green Deployment or Canary Release methods, the cutover can happen quickly and minimize the amount of downtime that the user experiences. Development teams no longer need to schedule “maintenance” during non-peak hours such as midnight or later.
Cons
INCREASINGLY MORE DIFFICULT AT SCALE.
Like most continuous delivery patterns, Blue/Green Deployment becomes increasingly more difficult at scale. The infrastructure can become increasingly more complex when implementing message buses, long workers, auto-scaling instances, etc. With Blue/Green deployment, you are essentially doubling the effort.
NOT EASILY IMPLEMENTED IF NEW DEPLOYMENT IS DATABASE DEPENDENT.
Probably the most difficult undertaking when implementing Blue/Green Deployment or Canary Release is managing the database during the process. If the application interacts with the database in a new way or if database schema is being changed in any way then the deployment process become more complex. In order to support the new database schemas for the newest version you have to first change the database schema to support both the old and new version simultaneously. Once completed, the newest version can be deployed and switched over. Once completely switched over, the old schema support can be removed leaving only support for the newest version.
Pros and Cons of Microservices
Pros
ISOLATION OF SERVICES ALLOWS FOR CHANGES TO BE IMPLEMENTED WITHOUT AFFECTING THE REST OF THE SYSTEM
One of the core reasons a Microservices might be a good solution for an organization is the ability to develop and update segments of an application without it affecting the rest of the system. This can be beneficial for two reasons. If the individual service is fragile and crashes after deploying it will not take down the application in its entirety due to its isolation. Also, if the priority for a new feature within one of the services is high, the new feature can be deployed on demand without having to wait for other features to be included in a release.
FAULT TOLERANT SYSTEM WITH FASTER RECOVERY
The individual services not only allows for isolated instances of failure but also allows for faster recovery. Microservices makes it easier to find the core problem, and then deploy fixes quickly. Also, if using phoenix servers or containers, the recovery of the services is obtained more easily.
Cons
INCREASED COMPLEXITY IN ORCHESTRATING THE ARCHITECTURE
The isolated components within a Microservices architecture make development quicker and more stable, the management of the architecture requires more attention. This is especially true if automated build and deploy scripts are implemented for each of the services. Additionally, the orchestration of various repos and also multiple virtual machines, containers, message busses, load balancers, etc. requires coordination which can offset the benefits.
COMPLEXITY IN COMMUNICATION BETWEEN SERVICES
In most Microservices architectures, the individual services require communication between one another. Wiring together the various components can be difficult and slow down the application because of additional data being transferred across services. Communication has to be developed via APIs and in some cases a communication layer via a message queue.
Pros and Cons of Dark Launching
Pros
PROACTIVELY LOAD TEST NEW FEATURES WITHOUT DISRUPTING USER
The core concept of dark launching is to load test a new feature before turning on the UI elements to the user. This allows developers to understand if their current infrastructure can handle the new feature and make changes accordingly. This can save the developers a lot of time and headache by proactively testing their infrastructure before disrupting the experience for the user.
ABILITY TO TEST AND THEN UPDATE OR COMPLETELY CHANGE TECHNOLOGIES
Dark Launching allows for developers to make significant changes to their underlying technologies without the user experiencing any side effects. In particular, dark launching can help when transferring to a new database system or database schema. The database change can be tested via dark launching before the actual change is made which can make the transition smooth for both the developers and the users.
Cons
DARK LAUNCHING IS NOT A TRUE USER TEST AND CAN BE MISLEADING
A new feature can sometimes be used in an unexpected way by the user. As a result, the load test that was performed during the dark launch may not be an accurate representation of the load that it will undergo when utilized by the user. So no matter how proactive the development team may be, sometimes the users can cause issues by putting strain on a system in an unexpected manner.
DARK LAUNCHING DOESN’T ACCOUNT FOR SUBJECTIVE FEEDBACK
A lot of time can go into load testing a new feature through dark launching, and then once deployed to the user the user could simply not like the feature for various reasons. This could be said for the release of most new features, and is why a gradual roll out of new features via Canary Release can be more beneficial than spending time load testing something that may not be wanted or needed by the user.
Pros and Cons of Feature Flags
Pros
ALLOWS FOR ORGANIZATIONS TO EASILY “TURN ON/OFF” NEW FEATURES WITH LITTLE CHANGE TO INFRASTRUCTURE
Developers can develop new features and then use a Boolean tag in order to turn on or off features. This can be done in the code itself and requires little to no changes to the underlying infrastructure. This requires less planning and communication between developers and operations keeping implementation simple.
ALLOWS FOR DEVELOPERS TO WORK ON FEATURES WITH A LONG DEVELOPMENT TIME WHILE NOT AFFECTING USERS
With the use of feature flags, developers can work on features with long development times and still push to production other changes within the code. The feature that is still under development would simply be turned “off” and can still be pushed with other smaller changes. This allows for long development projects to gain progress, and then once complete the new feature can be turned “on.”
Cons
IF NOT MANAGED WELL, FEATURE FLAGS CAN TURN INTO UNNECESSARY TECHNICAL DEBT
Increased technical debt is the most commonly cited reason to avoid using feature flags. If left unmanaged, the additional code involved in a feature flag can add to the technical debt of an application after the new feature has been implemented. This additional code can leave the application more fragile in the long run.
COORDINATION OF FEATURE FLAGS CAN BE DIFFICULT
If several feature flags are utilized throughout the code, it can be difficult to manage what features are turned on or off. This can lead to discrepancies in the code that end up causing issues. This is why it is important to properly document how each feature and its corresponding feature flag is functioning in order to keep the application working as expected.
Final Thoughts
There are, of course, many other pros and cons that are realized when diving into these popular continuous delivery patterns. This, however, provides a list of some other more commonly discussed advantages and disadvantages. If you know of a pro or con that you feel should have been included in this list, then feel free to comment below.
Deploy an app using Cycligent, and we will send you a free t-shirt!
