PREMISE: The next generation of application platforms are rapidly evolving, but they are still being defined. The current landscape is a mix of open source projects and vendors that are bringing blended business models to market. We look at the elements of these architectures and how companies should consider modularity in their architectural choices for next generation applications and infrastructure.
Applications-architectures drive infrastructure-architecture decisions. Next generation applications, focused on social, mobile, big data and IoT are not only driving better end-user experiences, but they are also being proven to impact the competitive balance within a variety of industries.
There is no doubt that containers have drawn the interest of CIOs, Enterprise Architects and Developers over the past 6-12 months. CIOs are interested in finding ways to accelerate the transition to modern application frameworks to drive their business forward. Enterprise Architectures are interested because containers bring the promise of application portability that is needed for evolving Hybrid Cloud architectures. Developers are interested because they align directly to emerging microservices frameworks that are needed for modern, scale-out applications.
These themes and trends were discussed on theCUBE at both DockerCon and Red Hat Summit. With any advancement in technology, there will be tradeoffs and new challenges. This research examines the elements of the emerging container architectures.
Below – Patrick Chanezon of Docker’s Technical Staff walks the container stack
Below – Lars Herrman, Red Hat GM of Containers unpacks the container ecosystem
Container Architectures – A Primer
Before moving into container architectures in depth, it’s important to understand a few basic principles.
- Containers are best suited for modern or next-generation applications, which are often written using distributed frameworks. This means that the underlying container infrastructure architectures will need to be modular and flexible.
- The core concepts that will be discussed are not entirely new. In fact, most elements exist in today’s virtualization architectures – such as Service Discovery, Cluster Management, and Resource Scheduling. Many IT professions interact with these embedded concepts in tools like VMware vCenter and vSphere, but for virtual machines instead of containers.
- The ecosystem of companies building elements of the container architecture is rapidly evolving. In most cases, they began by creating a single tool, but are evolving to have a more complete stack to service a complete container infrastructure.
Container Architectures – In Depth
As discussed in Container Ecosystem Unlocking the Speed of Developers, one of the main reasons for container popularity is simple setup and operations. Containers can run natively on most versions of Linux and with free tools (e.g., Boot2Docker) on both Mac and Windows.
Moving from a single container to a functional architecture to support production applications can require a complex set of tools and configurations.
Looking at the architectural “stack” beyond a single container, we begin to get a sense of the number of elements that would typically be required to run a next generation application on containers.
Initially, there are several important things to note about this diagram:
- None of these elements are hardware or cloud dependent.
- Implementations may combine some of these layers into a single piece of software. Individual functions have been separated to display where vendors and tools fit into the broader architecture.
- Not all elements are mandatory. Some elements could be manually configured within other elements, or may not be required depending on the application needs (e.g., virtual machines, service discovery)
Viewing the stack from bottom to top, here is a definition of what each element contains and examples (italicized and see Figure 4 below):
| DevOps Tools | These are the set of tools that are often run on a local machine to help setup containers, virtual machines or initial application packaging. This might be better named “Developer Tools” or “Operations Tools”.Hashicorp Vagrant, Docker Machine, VMware AppCatalyst |
| Physical Host (or VM) | These are the actual computers where the containers will run. These could be a local laptop, a Data Center server, or a Public Cloud instance.VMware ESX, Microsoft Hyper-V, KVM, LXD |
| Container OS | This is the Operating System (Linux or Windows) that interfaces with the underlying physical host and delivers the OS-level services that are shared by all containers on that host.CoreOS, Red Hat Atomic, RancherOS, Canonical Snappy, VMware Photon |
| Container Runtime | This is the software layer that manages containers (create, start, stop, destroy) on a specific host.Docker, Rkt, Lattice |
| Containers | This manages the interaction between the application and the Container OS. While some people will draw an analogy to a virtual machine, containers do not contain the entire OS. |
| Marketplace / Image Management | These are the servers (run on-premises or as a Cloud SaaS application) that hold and manage the container images.Docker Registry, CoreOS Registry |
| Configuration Management | These are the tools that manage and automate the configuration files and deployments.Ansible, Chef, Puppet, Docker Compose, Terraform |
| Container Networking | Also known as “Software Defined Networking” (SDN), this is the framework that manages the routing of packets between containers.Docker Networking, WeaveWorks, Flannel (CoreOS) |
| Container Cluster Management | This set of services helps to establish clusters of containers that will appear to the application as a single set of services. It manages availability of the container resources within a defined cluster.Docker Swarm, Hashicorp Serf |
| Service Discovery | As more elements / microservices are added to an application, it can be difficult to know what is available and where it is located. Service Discovery manages the advertisement and permissions of services as they come onto the network.Hashicorp Consul, etcd (CoreOS) |
| Container Scheduling | This service looks at the most efficient location for container placement on host machines. It manages capacity planning, failure/restart and scaling applications are requirements or demand changes.Kubernetes, Mesos |
| Application Scheduling | Working closely with the Container Scheduling service, this is a set of application-specific services that will describe the requirements of how an application should be deployed (resources, timing, dependencies).Marathon, Chronos, Hadoop, Spark |
| Security | All elements of security that are needed within container architectures; from the OS to Authentication services to Data Management.CoreOS Linux, Intel Clear Containers, Docker Notary, Hashicorp Vault |
Container Implementations – Flexibility, Interoperability and Challenges
[NOTE – Figure 4 (below) does not include every implementation in the marketplace, but highlights some of the most widely used today]
One of the challenges that companies have as they look at the container ecosystem is the large number of elements and implementations. Adopting this stack is daunting when combined with the shift away from traditional, monolithic application architectures that were often delivered as packaged suites from ISVs.
The second challenge is that start-up companies are often releasing individual projects as “tools” instead of “suites” of software. In many cases, these companies are leading the projects or they are lead by open source communities that don’t actively market their projects (e.g., Apache Foundation
The third challenge is that many of these tools are both interoperable and interchangeable. Docker CTO/Founder Solomon Hykes often uses a phrase, “batteries included, but removable” to describe Docker’s architecture. Many early customer implementations will use elements that align to different projects, instead of a vertical stack from a single vendor or open source project. In the near term this is great for early adopters that want flexibility as they evolve their new architectures, and have the technical skills to work with all of these diverse technologies. In the long term, this may create challenges for companies that want stable environments or don’t have access to a broad range of emerging technical skills. It will also create greater demand for public cloud services that augment these container architectures (e.g., Amazon Elastic Cloud Services or Google Container Engine), as they can off-load and abstract some of the complexity for their customers.
Summarizing Container Architectures
Container technologies and architectures are rapidly being created and evolving. Many start-ups are driving the foundation of the new tools and frameworks, within open source communities. We are beginning to see the next stage in container evolution, as companies bring more solution-level offerings to market, for both on-premises and public cloud.
These container architectures are being adapted for Cloud Provider, Enterprise, Government and Mid-Market companies. In some cases, the ability to mix and match architectural elements creates a unique advantage for a company if they have the necessary internal skills. In most cases, where technical skills may be evolving or immature, there will be greater levels of adoption as more architectural elements are packaged together to create simpler deployment and operational models.
ACTION ITEM: For companies interested in modern application development for their business, now is the time to be exploring both the container architectures. The ability to rapidly experiment and develop the necessary skills around these domains will be critical to the success of IT organizations looking to keep their business relevant in the software-defined era we’re quickly moving into. It is important to not only engage with the vendors bringing these tools and platforms to market, but also exploring how to engage with the open communities.
