To properly prepare cloud-based applications for containers, be sure to emphasize a service-based architecture and understand your management options upfront.
Container technology is an increasingly popular choice for application hosting in the enterprise. But, to fully take advantage of the benefits of containers, development teams first need to properly prepare their applications, including those in the cloud, for the move.
Compared to VMs, containers are more lightweight; they take up less room on a disk and have a much lower overhead. This enables multiple containers to run more efficiently on one machine than multiple VMs could. To maximize this benefit, it’s best to migrate from a monolithic application architecture to a service-based one. Identify ways to make cloud-based applications more modular and lightweight.
For example, you could reduce or isolate dependencies, pay down code debt and identify and remove bottlenecks that prevent parallel execution.
This type of service-based architecture also makes it significantly easier to reuse containers and scale an application only when needed. Rather than load balancing for a deeply coupled, monolithic application to accommodate increased traffic, the web server container can scale up but doesn’t needlessly scale the subsequent processes that don’t experience high loads.
Development teams generally configure containers with code-level manifests, which describe, among other items, the packages a container requires and the code that it should run. You can manage container manifests within a version control system, which enables incremental updates to better tune the application architecture as needed with minimal effort and cost.
When you migrate cloud-based applications to container technology, prepare a manifest that matches its current hosting architecture as closely as possible. This provides a solid platform for future improvements.
However, the introduction of code-level manifests changes the dynamic in which development teams interact with operations teams. While the move makes it possible to run local development environments that are in parity with production environments, it also gives developers the ability to change the fundamental configuration of the containers the application runs on. This isn’t inherently an issue, but without proper discipline, it can become problematic.
Generally speaking, when you properly configure containers, they should be ephemeral. This lets you stop, destroy and recreate them at any point with minimal configuration. However, file storage complicates this trait. When a container is rebuilt, files stored in an ephemeral file system are automatically wiped, which can introduce a host of challenges around file uploads or containerized database servers.
To work around the challenge with containerized database servers, you could share a local directory on the host machine with a running container. However, the use of an external, cloud-based database is a more manageable option. Similarly, a cloud-based object storage service offers a more reliable and scalable way to handle file uploads than sharing a local directory. An article by Zachary Flower
You must be logged in to post a comment.