Introduction
Containers are not a new thing – they’ve been a hot topic for a couple of years. Docker, the company that became a synonym for the technology and now has a huge community worldwide, was founded 14 years ago. Despite those facts, we see a rather slow adoption of the containers both in our customer base and in our own R&D teams. This is rather strange considering the technology has so many clear advantages over the standard VMs. The reason may lie in the fact that all techies mostly stick to familiar practices. Many would like to leverage the container technology, but it is understood as something that requires a change in the way we do infrastructure along with a new toolset, new development processes, new monitoring processes, etc. Suddenly the bar gets too high, and many people don’t know where to start. It feels like one has to spend a month or two figuring out the technology first.
As often in life, we could use something without knowing each detail about it. Many drive a car and have no knowledge of how the combustion engine works or how exactly the gearbox gives traction to the wheels. We don’t care about it, as long it is usable enough – for one, it is enough to unlock, put gasoline, switch into gear and use the steering wheel. In a similar manner, this read will suggest small and practical examples of how to use the containers in a known context so that everybody can achieve small wins while getting familiar with the technology.
VMs vs containers
Everybody uses VMs and often the containers are seen as their next generation. Let’s briefly check the differences in multiple categories.
Size
_ Figure 1: Source: Docker.com_
Figure 1 shows the runtime differences between a container structure and a VM structure. Notice the overhead every VM brings – it has a thick layer of an operating system instead, and it shares the host operating systems via the container abstraction in a much more optimal way. By this, the containers have a much smaller footprint in terms of memory, hard disk allocation and much faster boot-up time. Their performance is also better and more persistent.
Purpose
VM is a general-purpose computer – you can run desktop and server applications in one. As in a normal computer, there is no limitation or best practice for the number of applications that one can run.
A container uses the host operation system in isolation. It is small and fast, but per best practice, it runs only a single application. Further, this app can only be headless, as the container, contrary to the VM, and does not have a UI console to work with desktop applications. Headless means that the application will be accessible only via the network interface – TCP endpoints, REST endpoints, web UI, web services, etc. The two latter facts explain why often the containers are used in the microservices architecture – they contain a single service type application.
Persistence
VMs are an abstraction of a normal computer and as such, they persist with everything that is written by the processes running inside it. We could revert back to a state-based snapshot of the virtual machine, but no data gets lost on restart. Contrary to this, the containers are immutable. Every data generated in the process space of the container gets lost on restart. The data that needs to survive a reboot has to persist in a volume mapped to the host operating system.
Sharing, moving, encapsulating
Virtual machines are not designed to be shared between developers. While this happens and everybody had a project VM called something like “dev setup virtual machine revision 32,” it is always a cumbersome process involving copying via hard drives, network shares, etc. In contrast to this, the containers are designed to be shared. The mechanism for sharing containers is through a container registry – this is a server component, similar to a VCS that can hold many types and versions of a container. Like source code, those containers can be pushed and pulled and tagged with a version, eventually enabling sharing between developers or promoting to an environment like test or production. Unlike code, and much like VMs, the containers provide a fully packaged solution that contains all dependencies – OS settings, environment variables, tools, libraries, etc. In summary – the containers are providing a solution of the “it worked on my machine problem” but without imposing the problem of sharing or promoting huge virtual machines.
Easy start
So, what are the quick wins for the containers with webMethods? Let me propose multiple scenarios in the original post on the Software AG Tech Community – some are easy, some are more advanced.
Road map and further readings
Software AG is going to bet more and more on containers for the delivery of its classical on-premises products. Soon, we will launch our own public container registry with regularly updated container images. You should also monitor our official GitHub account for any samples around the CI/CD promotion and container orchestration.
For a deeper understanding of how to deploy container solutions with webMethods, take a look at the more comprehensive blog post on containers and container orchestration. The topic is also discussed in the following webinar.
This article is part of the TECHniques newsletter blog - technical tips and tricks for the Software AG community. Subscribe to receive our quarterly updates or read the latest issue.
Top comments (0)