A friend recently shared an item on Facebook that described the top 10 developer excuses, including things like “it worked yesterday” and “you must have a virus.” The number one excuse: “It works fine on my machine!”
Well, of course it does. Developers take special care to ensure their development environments have all the system resources, up-to-date operating systems, and the latest versions of frameworks and other tools to ensure it’s smooth sailing for them. However, in traditional software development, they often forget all they’ve done to their environments, and when they move their programs to a test, staging, or production environment, things can go awry. “Oh, right…you need to have the latest beta version of such-and-such obscure framework, which doesn’t run on your operating system anyway.”
Excuses, excuses...
Containers and Why We Need Them
It’s not (always) the developer’s fault. One of the greatest time-wasters in traditional software development is managing multiple environments and making sure they are sufficiently alike that the software works identically on all of them. It’s all too easy for these environments to get out of sync, or for developers to lose track of all the system requirements needed to make their software work. Until recently, it was all managed manually, which meant that clients were billed for work that added no value to the final product. That’s bad for developer productivity, bad for timeline adherence, and bad for business.
Thus, a few years ago some smart people got together to develop the concept of containers. Containers are a bit like virtual machines (VMs). A VM has a complete operating system and resources of its own; the only thing it shares with other VMs is the CPU cores and memory on the VM host. A container, by contrast, shares the host machine’s hardware and operating system, but has its own configuration of other resources, such as frameworks. It’s intended to provide a consistent environment in which an application runs, regardless of the underlying operating system or hardware. Even better, an environment can have multiple containers, each with different configurations, and they won’t conflict with each other.
With containers, a development team can much more easily manage the correct environment configuration for the software being developed. Instead of manually configuring each environment every time a change is needed, the developer updates a container object, which is simply copied to each environment.
Docker and Kubernetes
How is this all done?
It starts with a container engine, a piece of software that enables the creation, configuration, and management of containers on a host machine. The best-known container engine is the open-source Docker, which AndPlus has been using for several years.
As helpful as Docker is in making our Agile sprints more efficient, there is more that could be done in terms of automatic container management and deployment to diverse environments. This gap is ably filled by Kubernetes.
Kubernetes is an open-source “container orchestration” platform, originally developed by Google and currently maintained by the Cloud Native Computing Initiative. Kubernetes takes containers to the next level by implementing automated tools for managing containerized applications, scaling them (that is, allocating resources to ensure they work as expected regardless of data or user load), and deploying them in clustered or cloud environments that may involve diverse hardware and operating systems.
Kubernetes and Docker are complementary, rather than competitive, technologies, and can be integrated into one powerful container platform. At AndPlus, we have been using Docker and Kubernetes together with great success. The combination enables us to automatically update web applications in our private cloud cluster for internal testing and client demonstrations as soon as developers push their code changes out, resulting in a complete transformation in the speed, efficiency, and control with which we manage the product of each sprint.
The Future of Containers
What does the future hold for container technology? Two logical next steps for container technology include the desktop and mobile.
Desktop environments often suffer from configuration conflicts between different applications, conflicts that could be eliminated by deploying containerized applications. This would be especially important in the enterprise, with its diversity of hardware, operating system, and application environments.
For mobile, containers could help in the ongoing effort to realize cross-platform development. Because of the wide diversity in hardware platforms and features (especially in the Android world), this may take a good deal of effort, but the payoff would be well worth it.
At AndPlus, we are grateful for the advantages afforded us by the advent of container technologies, and we are excited about where they will take us next. Contact us today to find out how we can use container technologies to power your next development need.
