Seven Decision Points When Considering Containers

Transcription

1 Market Guide Seven Decision Points When Considering Containers A Continuum of Deployment Choices More than ever, developers and systems architects have a range of choices when it comes to deploying applications, components, and services. Scarcely ten years ago, almost all code was housed on bare metal servers. Now, virtual machines are common deployment targets and containers are becoming more popular. In 2016, Docker alone reported 460,000 applications using their container technology, a 3100% year over year growth 1. Since then the number of container deployments has continued to expand. Containers exist as part of a continuum from centralized mainframes to clustered servers, virtual machines, and ultimately containers. They represent the next stage in virtualized architectures. Conceptually, it makes sense to house services in smaller, more manageable units such as containers but that is not always the case. Industry: Virtualization Technology Date: October 2017 EXECUTIVE SUMMARY Key Stakeholders: CIO, Systems Analysts, Operations Managers, Scrum Masters, Technical Analyst Why It Matters: Containers, like all technology, must be used strategically. As one of many possible architectures for deploying services and applications how one chooses may determine success or failure. Top Takeaways: There are seven critical decision points that must be addressed when considering containers. They are: 1. Isolation 2. Resource Overhead 3. Capacity Utilization 4. System Architecture 5. Portability 6. Deployment Speed 7. Data Persistence 1 DockerCon 2016 Monday Keynote, Docker June prior written permission. Page 1

2 Mainframe Client Server Three Tier N-Tier Clustered Servers Virtual Machines Containers Figure 1: System Architecture Continuum The decision to deploy code to containers versus virtual machines or dedicated servers has some unique characteristics. Amalgam Insights has identified seven key decision points that should be considered when choosing to deploy to containers. These seven decision points can act as guideposts that will help point to or from using containers. prior written permission. Page 2

3 Amalgam Insight Market Guide: Capacity Utilization System Architecture Figure 2: Seven Decision Points for Container Isolation Containers provide a reasonable degree of isolation without high resource overhead. They allow for namespaces, or collections of processes, that are isolated from other namespaces running on the same Linux server. Each service or application stack is kept from interfering with other similar stacks. Like virtual machines, processes can only access the resources associated with its own container. Unlike virtual machines, however, containers are a feature of the operating system and can potentially disrupt the operating system in which it is running. Virtual machines run an entire operating system making it more difficult to cause problems with processes running on other virtual machines. When a high degree of isolation is a concern for critical services or applications then virtual machines or single services on a single server may be necessary. If low to moderate isolation is reasonable for a service or applications, then containers are a potential solution. prior written permission. Page 3

4 Resource Overhead Containers have less resource overhead than other forms of virtualization. Since containers are part of the operating system, they don t repeat an entire operating system for each instance. There are many containers to one operating system and, hence, the overhead of multiple copies of an operating system are avoided. This saves resources when a large number of independent applications or services are packed together on one physical server. This contrasts with virtual machines that typically need an entire operating system per virtual machine on each physical server. As is the case with virtual machines, containers can limit the amount of resources that applications can consume. They just require fewer resources to begin with than is typical with other forms of virtualization. If resources are constrained or a large number of server or application processes need to be packed onto a single server, containers make a good choice. Capacity Utilization The need for higher capacity utilization is a major driver for container deployments. Containers allow more applications, components, or services to run safely on a single piece of hardware. In other words, more containers can be packed onto a single server with less consumption of resources than can virtual machines. The more services or applications that can run successfully on a single server, the higher the capacity utilization. Containers are an excellent choice for small services that don t require extensive resources. However, if an application or service will take up the majority of the resources of the server anyway, capacity utilization may already be high enough. In that case, the case for using containers is weaker. It will not be possible to house many of them on the server before it is overburdened. When moderate resource use is expected, a virtual machine may be an alternative. Virtual machines won t have the density of containers but that s not necessary in all cases. If the application or service won t take up much of a server s resources and optimizing for capacity utilization is a concern, then containers are a reasonable choice. prior written permission. Page 4

5 Architecture One of the drivers for the growing popularity of containers is the emergence of highly distributed architectures based on microservices. As the name implies, microservices are small services that perform very limited tasks and communicate through RESTful APIs. Microservices designs utilize many, perhaps hundreds, of services running at once and require some degree of isolation and resource limitation. Without isolation, a single tiny service could disrupt many other services running on the same physical server and cause widespread service disruption. Containers are useful for other types of architecture including n-tier and even client-server. There is no formal link between containers and microservices that requires one with the other. They do, however, complement each other well. If the architecture is highly distributed with many independent services, then containers should be considered. Since this is basically the definition of a microservices architecture, containers tend to go together with microservices architecture. Portability Containers are highly portable. They can run on a range of hosts from dedicated Linux servers to virtual machines to cloud services. If a container needs to be duplicated, in a clustered environment for example, copies can be made and instantiated on another host. If a container needs to be moved to a different host, perhaps one with more resources, it can be shut down, moved, and instantiated quickly. The portability of containers is extremely powerful when moving from development, to test, to production deployment. Developers can have their own local containers that represent the target environment, which can then be copied to multiple internal test environments, and eventually deployed to a cloud service. This can be a boon to Agile-style development where rapid changes, testing, and deployments happen in short bursts rapidly and repeatedly. If the potential for moving services or applications from one host to another will enhance development and testing, especially to support Agile development but also for normal operations or migration, then containers may be an attractive tool. prior written permission. Page 5

6 Deployment Speed Containers deploy very rapidly. Development containers can be spun up quickly from within many development systems such as IBM Bluemix or Microsoft Visual Studio. A number of tools from the ecosystem, especially Docker Enterprise and Google s Kubernetes, help to quickly configure, manage, and deploy container clusters in production environments. Deployment speed is important for Agile development. With rapid sprints yielding many releases, the ability to have a secure development environment that can then be translated into a demo system and eventually deployed quickly and repeatedly is essential. Even if the project philosophy is not Agile, slow deployment can act as a drag on development projects which extends timelines and budgets. If a project has a need for rapid deployment of code, especially if it happens often such as in an Agile environment, then containers may help to manage rapid deployment. Data Persistence One of the ways that containers are able to be so portable and lightweight is because they are ephemeral and stateless. Containers generally do not support persistent data. External data stores can be mounted in a container and databases accessed through its APIs but cannot permanently store data locally within the container. This is in stark contrast to virtual machines which usually have mountable file systems that endure when the virtual machine is shut down. In many cases, this lack of data persistence is not a problem. Services and applications are usually storing data in databases rather than in local filesystems. If data is managed centrally or externally to the service or application then a container is appropriate. Otherwise, if data must be kept locally and persist, then containers will be a challenge. Virtual Machines Plus Containers: A Middle Ground Strategy Containers, like all technology, represents a series of compromises. In many instances, a one-size-fits-all strategy won t work and a middle ground that leverages the capabilities of virtual machines and containers may make sense. Therefore, it is not uncommon to see containers deployed within or alongside virtual machines. prior written permission. Page 6

7 Virtual machines can provide higher isolation from services that reside on different virtual machines while containers can help provide isolation within the virtual machine. The virtual machine can also deliver localized persistent data while containers can offer higher capacity utilization within the virtual machine itself. There are many other use cases where virtual machines and containers are complementary and not competitive. If it containers seem like a good idea but there are critical compromises that can t be made, consider combining virtual machines and containers. Containers can exist within a virtual machine or alongside virtual machines in a mixed architecture. Security Considerations If a decision has been made to utilize containers, there are a series of implementation and design decisions that need to be made. Security is one of the more important ones. Some of the strengths of containers, especially portability and the ability to rapidly deploy containers, raise security concerns. Security issues with a service or application could rapidly proliferate throughout a cluster. Adding agents to each container, a typical method of managing application or service level security, overrides one of the key advantages of containers their lightweight nature. The low resource overhead of containers is one of their main attractions and adding traditional security agents to each container would drive up that resource usage and hence, reduce the desired capacity utilization on the host server. Security is not a criterion for choosing containers over other technology; It is always a concern no matter what choice is made. The unique lightweight and portable nature of containers requires container-specific security that secures the container without negating its advantage. If containers are to be a part of an architecture, container specific security needs to be a part of the implementation and design. Conclusion Containers are an important tool for rapid deployment of services or applications. They are lightweight and can be spun up and moved quickly. A well-developed ecosystem exists to configure, manage, and monitor container clusters. Containers are especially attuned to microservices architectures and Agile development. prior written permission. Page 7

8 They have some downsides as well. Isolation isn t as strong as having separate virtual machines and locally stored data is not persistent. Security solutions also need to consider the unique design of containers. This means that containers are not the solution for all situations, any more than virtual machines are the solution for all code deployments. It is important to understand the critical criteria when deciding on container technology, understanding how it fits into the overall development, test, and production environment. In some cases, combinations of containers and virtual machines will provide the best solution with the fewest compromises. In other cases, containers may not be appropriate at all. Containers, like all technology, embodies a series of compromises and choosing the right course is a balancing act. These seven decision points will help to guide a conclusion about containers and where they fit in the overall system architecture. Making the right decision about containers will determine the success or failure of the entire projects so choose wisely. Tom Petrocelli Contributing Analyst October 31, 2017 prior written permission. Page 8

9 About Us ABOUT AMALGAM INSIGHTS AUTHOR: TOM PETROCELLI Is a leading research, advisory, and consulting firm focused on Technology Consumption Management: the technology, personnel, and strategies to unlock business value from new technologies for emerging and disruptive business models. This focus on the purchase and utilization of technology bridges key CFO-CIO gaps in maximizing the value of technology investments and successfully supporting enterprise technology. AI provides over 20 years of experience in supporting high-growth and disruptive companies with a focus on translating new technologies into Digital advantage. Tactically, AI focuses on the following practices as part of the Technology Consumption Management umbrella: Hybrid IT management Subscription Revenue Management Financial Planning Management Strategic Performance Management Design Thinking & Technology Evangelism Tom Petrocelli is a contributing analyst with Amalgam Insights. His area of interest is collaboration, developer tools, IT project efficiency, governance, and methodologies, and DevOps. He also looks at how large regulated companies, especially financial services companies, manage IT projects. Tom has over 33 years of experience in the IT industry. Prior to Amalgam Insights, Tom: Worked for a large, global, banking corporation. Was the research director for Enterprise Social, Mobile and Cloud Applications at Neuralytix. Before Neuralytix, Tom was the senior analyst, Social Enterprise at Enterprise Strategy Group. Before becoming an analyst, Tom held various senior and executive management positions. Phone: Website: This paper was sponsored by CloudPassage. Disclaimer: Amalgam Insights provides consulting, research and advisory services to a variety of technology consumers and vendors, and may have revenue-based client relationships with companies mentioned in our research. prior written permission. Page 9