Deploying at scale -- what does it mean and why does it matter? [Q&A]
One of the popular buzzwords in development circles in recent years has been 'deployment at scale'. Now, while it's nice to have a universally recognized term, opinions about what deployment at scale actually means tend to vary.
So what exactly does 'at scale' mean in the development community and how can companies define their own approach? We spoke to Adam Frank, VP, product and marketing at Armory.io, to find out.
BN: Let’s start by going back to basics, what constitutes a 'deployment'?
AF: A deployment in the context of Continuous Deployment and technology is when code or configuration changes are automatically committed or 'deployed' into production. Continuous Deployment ensures deployment without negatively impacting user experience by orchestrating the testing and environment promotion lifecycle while using progressive strategies like canary and blue/green with automated impact analysis and seamless rollbacks.
BN: How is deployment affected by the enterprise environment?
AF: The enterprise environment creates complexity with its size, inconsistencies and myriad moving parts. Deploying software at scale in the enterprise environment can be immensely challenging, cumbersome, slow and expensive. The other aspects of scale that we cannot forget are the people and process aspects too. Teams throughout the enterprise are going to have different processes, goals, priorities, and mandates. People, process and technology at enterprise scale often leads to the complexity.
BN: Where do you draw the line between deployment and maintenance? How does this fit with the concept of Continuous Deployment?
AF: There is no defined line between deployment and maintenance nor should there be. Some code may deliver new features while another may provide a bug fix or clean up existing code and tech debt. Either way, they should all go through the deployment process to ensure functionality and reduce change failure.
BN: So how can deployments be scaled up?
AF: Two words: Orchestration. Automation. Platform engineers and DevOps practioners spend extensive time building and maintaining deployment pipelines and processes, the complexity of which increases the time between releases and decreases the likelihood of a successful deployment. homegrown tools lack scalability on all three aspects: people, process, tech. You want your people focused on your competitive advantage; focused on your differentiating value. Not building and maintaining infrastructures. You want your process automated, end-to-end. To efficiently scale deployments, teams need to make the entire process straightforward, reliable and repeatable. Continuous Deployment orchestrates testing, security scanning, the promotion lifecycle across each cluster and environment, regardless of how many clusters and environments one might have, and most importantly reduces the risk to negatively affecting your customer experience. Whether you're going from 10 to 1000 developers or 1000 or 10,000 and beyond, a good Continuous Deployment workflow remains easy to maintain, efficient and effective.
BN: What part do technologies like containerization have to play?
AF: Containers virtualize software layers above the operating system level making them lightweight software packages that contain all the dependencies required to execute the contained software. Because they are lightweight they are very fast to modify and iterate on. This makes them perfect for Continuous Deployment. Once the Continuous Integration process has successfully completed and there's a new artifact; a new container image, the Continuous Deployment workflow takes over and orchestrates the deployment across environments. This ensures that the artifact makes its way to production safely and securely.
Image credit: Elnur_/depositphotos.com