This content originally appeared on Bits and Pieces - Medium and was authored by Natarajan Venkataraman
Implications of Microservices Deployment Patterns
In an earlier post, I talked about when it makes sense to use which deployment strategy — Blue-Green, Canary and AB-Testing. In that post, I also added a caution about the development challenges these strategies may entail. In this post let’s explore those challenges.
Deployment from feature branch?
If you plan to use AB-Testing to get customer feedback, from which branch of the relevant component’s repository are you going to deploy? From the master or main branch? Likely not. Instead you would deploy the flavors A and B (etc.) from the respective feature branches. Whichever is ultimately chosen would get merged into master.
What does this entail? How can you deploy to production from a feature branch? What level of testing is required? Who does this testing?
Having a separate QA team validate all feature branches, is going to be prohibitive. In reality, the concerned development team has to meet the required quality for production deployment. In fact, this fits in with true DevOps principle where Dev team and Ops are in fact one and the same and there are no separate teams for development, QA and operations. But the big question is whether the organization that adopts microservices architecture is ready for that or not. This transition requires both mindset and culture changes within the organization.
Implications for CI/CD
Let’s look at the CI/CD pipeline impacts. Most organizations have an automated ‘deploy to production’ CI/CD pipeline that starts when a commit is merged into master branch. The commit to master is also subject to more checks —eg, code quality, SAST checks, etc.
When CI/CD has to be done via feature branch, the tooling itself needs to cater to specifying the feature branch name and triggering the pipeline to deployment. But what about the code quality and SAST checks? It is very hard to provide a generalized answer or suggestion. So I will leave this as food for thought.
Say, production deployment is performed from feature-branch. When the code needs to merge into master then what? If there are indeed code quality or security issues that prevent merge to master, then the code needs to get modified before being merged into master.
As I mentioned in my previous post, if the AB-Testing is primarily used for UI elements, then it would be ok to modify the code to address any items flagged by quality checks, since the UI won’t change.
Repeated deployments?
Would Canary deployment encourage development teams to release early with less that production quality testing? After all, if something goes wrong, we could just revert back to older version, then fix the issues and re-release it back via the Canary deployment, right?
This is tempting and may also make sense in certain situations, especially for B2C applications. In many B2B SaaS applications, such an approach can lead to overall poor customer perception. After all, you are treating your customer as a guinea pig. And no one wants to be a guinea pig.
Measurements and Deployment Automation
All microservice deployment strategies depend on measurement. In case of Blue-Green and Canary, there needs to be measurement of performance and errors, so that the SRE can know how well the new version is performing, whether there is any degradation in latency or success rates etc.
It also requires thresholds to be set so that auto-revert can be performed promptly when the thresholds are exceed for a given duration.
In addition, removal of the older versions also need to be automatic so that there are no crumbs lying around once the observation period is past and new version is deemed good.
Now, if some components are not that heavily used in production, say, the feature is an obscure one and not very often used, then the SRE may even have to use “test accounts” in the production deployment to invoke the relevant features to stress the component and trigger the metrics collection during the observation window.
Multiple production clusters
When experimental deployments are made in a single production cluster, then life is a bit simpler. But many companies need to support multiple production clusters. This could be due to geo-localization legal requirements or to providing low-latency access to customers etc.
In such cases, would the deployment strategies be employed only in one production cluster? That may be what happens in most places, since there is a main production cluster where microservices are updated first via CI/CD tools and then copied (ie. sync-ed via automation) to other clusters.
This copying itself can be problematic, since one would not want experimental deployments like in Blue-Green or Canary to be sync-ed.
Doing AB-testing in just one production cluster also means feedback is sought from customers in a select geo. But what if the feature was requested by a customer in another geo? That would require automation to deploy feature in a specific geo for AB-testing.
Tracking and cleaning up microservice versions in one production cluster would be complex enough. With multiple clusters, conscious thought is required to determine the trade-offs before adopting microservice deployment strategies.
In a nutshell, what all these mean is that the deployment automation aspects become a lot more complex.
In Conclusion
When we talk about B2C applications, then the microservices deployment strategies could play a key role in responding to customers, feature velocity and innovation and thus give a benefit.
In the case of B2B applications, the microservice deployment strategies could complicate the development process. It is more common to see such companies just upgrade the whole cluster or a part of the cluster in the traditional manner — ie. full upgrade. But doing so also means losing a lot of microservice architecture advantages.
From monolithic to composable software with Bit
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more:
- How We Build Micro Frontends
- How we Build a Component Design System
- How to reuse React components across your projects
- 5 Ways to Build a React Monorepo
- How to Create a Composable React App with Bit
Implications of Microservices Deployment patterns was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Natarajan Venkataraman
Natarajan Venkataraman | Sciencx (2023-03-06T09:12:19+00:00) Implications of Microservices Deployment patterns. Retrieved from https://www.scien.cx/2023/03/06/implications-of-microservices-deployment-patterns/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.