3 Use Cases for Containers that Should Be Part of Your 2016 Enterprise IT Strategy
Over the past year, while the IT Industry has been abuzz over Docker and containers, CIOs and CTOs have been struggling to figure out what containers are and what these new architectures mean for their organization. Although containers were designed for their simplicity and ease of use, the current land grab from startups and larger players has only led to more confusion for enterprises trying to realize the benefits of adoption. Heading into the new year, we wanted to identify three initial enterprise use cases for containers to have as part of your IT strategy for 2016.
These three use cases are the most common steps to adoption for IT organizations, which in turn can dramatically improve your system’s architecture and operations over time. As you begin thinking about microservices (a software architecture style in which complex applications are composed of independent processes communicating with each other using APIs) and whether it will work for your organization, here are some areas to explore:
Enterprise Use Case 1: Building & Testing Applications Locally
A container’s primary value add is that it significantly simplifies the configuration involved in building software, enabling developers to cut build times on their local machine. By running software through containers, which by nature have a high level of isolation, applications that were previously dependent on a heavily configured VM (and subject to networking and file system conflicts) can run smoothly across systems, even if multiple instances are already running. Additionally, developers can test a number of language versions and environments in parallel, and because you can reproduce environments in seconds, bugs can be investigated quicker. This is typically the first route of adoption organizations should undertake, mainly because of its ease to implement and the fact that it both empowers developers to be more productive and solves real business problems.
Enterprise Use Case 2: Developer Team Collaboration
Just as quickly you can spin up a new container, you can also start disposable development environments, allowing new team members to be productive on their very first day. Code they’ve written will work across the team’s existing code base, allowing teams to work together without the fear of tiny environment differences getting in the way. This kind of standardization not only increases productivity and innovation due to increased feature velocity, but it also leads into dynamic improvements like Continuous Integration (which we’ll explore next). Also, widespread container usage can cut datacenter operating expenses because of a container’s lightweight footprint compared to a virtual machine.
Enterprise Use Case 3: Continuous Integration
Continuous Integration (CI) is a newer practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. In this model, code changes are integrated and tested continuously and shipped when ready. Investing in CI closes the gap in the feedback loop on code changes to minutes versus days. When compared to manual testing, which often takes a day or two to generate full test feedback, additional changes will have occurred during that time, making bug fixing an annoying and difficult undertaking, with developers having to explore multiple changes to get to the root cause of issues that arise. Containers enable CI, making it possible to deliver quality software rapidly and iterate faster than ever to ship code.
Developer adoption of containers is a great first step, but there is even more value to be unlocked by using it as a way of improving overall IT operations over time. Shifting to an architecture built for microservices and DevOps has serious potential to provide significant and lasting competitive advantages for the business. A microservices architecture sounds a lot like SOA, but is substantially less complex and doesn’t require the same level of governance or data modeling between services. With microservices, development teams are aligned to specific business purposes, allowing them to increase feature velocity while being able to coordinate better with other teams.
Though containers are a software solution to effectively deploy microservices, they do not magically create the processes or teams for your company. Microservices architectures are rare in the Fortune 1000 and the investment required to refactor existing applications presents a high risk for most organizations that are not mature or agile enough. While developers will savor the flexibility and control, they will find themselves at odds with the enterprise which wants to manage and operate more simply. This opens up some business challenges that will require IT leadership to address.
This journey will take time and money but the above use cases are a great start to help get you there. If you are interested in exploring whether or not microservices is a fit for your organization, Martin Fowler does a great job laying out the benefits and costs of a micro services architecture. If you decide to move forward with microservices, be sure to check out “The Twelve Factor App” which outlines a methodology for developers to follow using best practices from modern application development, as well as Calvin French-Owen’s recent post on best practices for engineering which he learned while building Segment.
Originally published at archive.work-bench.com on December 2, 2015.