With all the time I\u2019ve spent of late assessing different deployment options, it seemed pertinent to stop for a moment and see where the deployment space is heading over the next couple of years.<\/p>\n
However, like any form of crystal ball-gazing, what we see happening in the future is only a prediction about what we think<\/em> may come \u2014 even if that prediction is based on real-world evidence. But I\u2019m not alone in doing this. People far more well-known than I, most notably Bill Gates, do this on a regular basis.<\/p>\n Despite that, I\u2019m still keen to share my thoughts on where I see the deployment space heading in the next few years. Have a read and tell me whether you agree or not. If you strongly disagree, please tell me why in the comments.<\/p>\n If you\u2019re not too familiar with the term, continuous delivery is<\/a>:<\/p>\n \u2026the ability to get changes of all types \u2014 including new features, configuration changes, bug fixes, and experiments \u2014 into production or into the hands of users safely and quickly in a sustainable way. Our goal is to make deployments \u2014 whether of a large-scale distributed system, a complex production environment, an embedded system, or an app \u2014 predictable, routine affairs that can be performed on demand.<\/p><\/blockquote>\n Why use it? Stop and consider for a moment how complex, how sophisticated, and how demanding it can be to deploy software. Consider the multitude of components that underpin it.<\/p>\n Speaking from personal experience, when I first started (back in 1999), all that it took to deploy a [web] application was to:<\/p>\n Not much could have been simpler. The application consisted of Apache with PHP and MySQL. There wasn\u2019t much that I had to do, nor that could go wrong.<\/p>\n These days everything\u2019s<\/em> different. There are database, caching, queueing, and log servers. On top of that, software is governed increasingly by complex and demanding legislation. So as well as the applications becoming more sophisticated, the rules that govern them are also growing in complexity.<\/p>\n As a result, we need a process or architecture that allows for complex, sophisticated systems to be regularly built and deployed, one that both manages and reduces this complexity as much as possible.<\/p>\n Consider these five benefits of continuous delivery from Martin Fowler<\/a>, and I\u2019m sure you\u2019ll agree that CD is essential:<\/p>\n Who wouldn\u2019t want these benefits?<\/p>\n If there was one mantra, automate all the things<\/em> would be it. By automating everything, processes are both well defined and repeatable. Following this logic, if processes are well defined, that means that they\u2019ve been thought about \u2014 in depth \u2014 for some time.<\/p>\n So it follows by consequence that you know your software and its needs at an intimate level. Combine that with an array of tools that make automation easier than it\u2019s ever been, and you have 1) a recipe for regular, successful deployments and 2) something that people will adopt with a passion.<\/p>\n It\u2019s not to say that people don\u2019t focus. But, I feel, up until now, there were valid excuses for a lack of automation. The options that were available took a lot of effort to use, whether because of education, time, cost, or a combination of all three.<\/p>\n However, in more recent times, this is decreasingly the case. There are so many tools springing up and reaching a sufficient level of maturity that there\u2019s no reasonable excuse not to use them.<\/p>\n These include open-source tools such as Rocketeer, Capistrano, Phing, Deployer, Forge, and Envoyer, as well as CI services like Codeship<\/a> and solutions such as Docker, which provides a complete development-to-production workflow.<\/p>\n Regardless of the tool you choose, it\u2019s hard to find one that\u2019s either immature or lacks an intuitive interface. Given that, the time to automate everything is well and truly here. The reasons for not automating all the things are gone.<\/p>\n Then there are the benefits that automation brings. Automation breeds reliability, predictability, and security.<\/p>\n When software can be built the same way each and every time, organizations can create software with confidence. Creating software with confidence leads to more predictable release cycles, greater visibility, and greater feedback. This in turn leads to software that is more likely to have a higher level of quality and customer satisfaction.<\/p>\n Then there\u2019s the fact that automated builds encourage other best practices, such as testing. You could say the tipping point\u2019s been reached. What\u2019s more, the mindset in the developer community, at least the ones that I participate in, is sufficiently behind it.<\/p>\n I\u2019m encouraged in this thinking because I\u2019ve seen what\u2019s happened when the tooling and mindset shift reached a critical mass previously, such as with testing. Once reached, the speed of adoption only increased until it became almost universally accepted.<\/p>\n This might be a controversial statement to make, but it\u2019s one that I\u2019m willing to put my money on. The reasons why are uniformity and simplicity.<\/p>\n Let\u2019s explore those points in some further depth. A typical, even clich\u00e9d, response over the years when something would go wrong in a deployed application would be \u201cit works on my machine.\u201d While that may have been true, it never helped the user who was prevented from or who\u2019d lost an hour or more of work.<\/p>\n To that end, a variety of solutions were created that sought to minimize the difference between all environments involved in a software solution, whether that was development, testing, staging, or production. Of those, some of the most notable are Vagrant, Chef, Puppet, Salt, and Ansible.<\/p>\n However, even the simplest of these, Ansible, still requires effort, knowledge, and time to use effectively. Yes, they create idempotent environments, ones which can be versioned along with the code that they support. But they\u2019re still complex setups, and builds are both resource- and time-intensive.<\/p>\n Contrast that with the solution \u2014 and model \u2014\u00a0that Docker<\/a> provides. Here\u2019s an example of a Contrast that with an equivalent, well-structured Ansible configuration. I think you see where I\u2019m going with this. The Docker configuration is significantly smaller and less involved to both understand and to maintain.<\/p>\n What\u2019s more, and as the presentation The Docker ecosystem and the future of application deployment<\/em><\/a> points out, building environments, whether locally or remotely, with Docker is a lot faster than with virtual machines. It also avoids configurations that are (operating system) distribution- or language-specific.<\/p>\n To be fair, in Docker\u2019s earlier days, there wasn\u2019t a clear path from development to production. But in recent years, as the adoption of Docker has increased, the toolchain has matured, and the number of commercial vendors supporting it grows<\/a>, this lack of clarity is all but a thing of the past.<\/p>\n Given that, I see Docker as a game changer for deployment in the years to come. It does have some detractors who have leveled valid criticism at it. But I see the foundation for these criticisms continuing to erode.<\/p>\n If history is anything to go by, being able to sustain a multitude of vendors and tools shouldn\u2019t be the case. In most other industries, there\u2019s always an initial explosion of interest followed by an explosion of companies to support that interest.<\/p>\n But gradually some players consume others until there are only a few players left. This holds true in mass media, shipping, auto-making, hardware, and even software in the earlier days. It wasn\u2019t all that long ago that companies such as Microsoft and Oracle were consuming any number of smaller companies, even if the synergies weren\u2019t there.<\/p>\n But in this particular software niche, I don\u2019t see it holding true as it has previously. It\u2019s my firm belief that it cannot, primarily because of the enormous amount of variation and specialization of software being created.<\/p>\n What\u2019s more, as software is not bound by the hard realities and costs of other industries, an almost unthinkable array and variety of software can be created. This software will have competing demands and needs and not fit into a one-size-fits-all model. Given that, I don\u2019t see how any one or even a small group of vendors could ever hope to cater to all of it. I\u2019m not saying that it won\u2019t happen, but I highly doubt that it would happen.<\/p>\n Having said that, I do see a certain level of commoditization happening. I see vendors coalescing around key areas and specialties. I see there being a few key players in the relevant spaces, such as storage, deployment, logging, caching, queueing, etc.<\/p>\n But I don\u2019t see a future where there\u2019s only a handful of vendors covering everything. While some companies have tried (and continue to try) to set the terms and conditions for how software is created, they\u2019ve never succeeded \u2014\u00a0not in the long term. Perhaps because software development came out of the hacker mindset or because software is so malleable.<\/p>\n But software is also a tool to solve a need, and people will always have needs to solve. Those needs, while sometimes similar, will never be the same. Given that, there will always be a need for variety and diversity of solutions on offer.<\/p>\n To sum up, these are my four predictions for the future of the deployment space. The software that we\u2019re writing (specifically in the web space) aren\u2019t simple pages with dates and copyright notices anymore. They\u2019re complex, often sophisticated applications that perform all manner of tasks.<\/p>\n From tools such as Zoho Books<\/a> and FreeAgent<\/a>, which help us manage our clients and accounts, to mytaxi<\/a> and Lyft<\/a> for finding a ride, the software that we\u2019re writing is growing ever more complex, composed of any number of components and backend services.<\/p>\n Given that, the complexity and demands on us to be able to deploy changes, bug fixes, and releases are also growing. Yet the available tools have also matured and refined over the years as well.<\/p>\n It\u2019s for these reasons that I believe that the future of the deployment space is a combination of processes, techniques, and tooling to make our lives easier and less error prone.<\/p>\n Do you agree or disagree? What does your crystal ball (or more important, your experience) tell you? Do you have some unique insights to share?<\/p>\n This article wouldn\u2019t have been possible without the input from countless colleagues and friends across the wider software development community. So thank you to all those whom I bugged and hassled for their input.<\/p>\nContinuous Delivery Will Be the Norm<\/h2>\n
\n
\n
Everything Will Be Automated<\/h2>\n
Docker, Docker, Docker<\/h2>\n
docker-compose.yml<\/code> file for building a set of Docker containers to support a rudimentary application (you can see the complete configuration on GitHub<\/a>).<\/p>\nversion: '2'\r\n\r\nservices:\r\n nginx:\r\n image: nginx\r\n ports:\r\n - 8080:80\r\n volumes:\r\n - .\/docker\/nginx\/default.conf:\/etc\/nginx\/conf.d\/default.conf\r\n volumes_from:\r\n - php\r\n\r\n php:\r\n build: .\/docker\/php\/\r\n expose:\r\n - 9000\r\n volumes:\r\n - .:\/var\/www\/html<\/pre>\n
A Multitude of Vendors and Tools<\/h2>\n
In Conclusion<\/h2>\n