by Daniel Pohl, Director of Product Management

Read the other posts in this series:

1. Part 1: IaC Makes Your AWS CI/CD Pipelines Run Smoothly
2. Part 2: Why IaC + CI/CD Pipelines Are Simpler for Containerized Applications
3. Part 3: IaC + CI/CD Pipelines for Applications on Amazon EC2
4. Part 4: IaC + CI/CD Pipelines for Kubernetes Apps (Amazon EKS)

Containerized applications running on Docker or Kubernetes are popular in part because containers are easier to secure and manage than virtual machines with complete operating systems.

Containers are easier to secure because they contain only the minimum O/S components needed to run the application.  For example, a Windows Server container probably would not contain the Windows GUI – this Windows component does not benefit Windows’ ability to host the application.

This minimization decreases the operating system’s attack surface and helps harden the container against malware or intrusion attacks.  Also, the container’s minimum O/S is less likely to require O/S patches than a full operating system because only patches for those minimum included components must be applied.

Many containers, including containers for different application roles (e.g. backend app Server, frontend webserver), can be hosted on a single virtual machine.  DevOps teams benefit because, with containerized applications, they are responsible for securing and managing fewer virtual machines with complete operating systems.

The CI/CD pipeline processes benefit when the host’s complete O/S is abstracted from the applications that execute within the containers.  A change to the host’s complete operating system (e.g. O/S patching) is unlikely to affect applications executing within the hosted containers.

Containerization is not always feasible

However, containerization is not always feasible.  Many applications require deployment on full Linux or Windows operating systems, including:

• Applications requiring a 3^rd party component that requires O/S installation
• Applications requiring direct access to local file system, perhaps for high speed file access
• Legacy applications – IT staff has other priorities than upgrading legacy applications to run on containers

If your application is not containerized and you want to deploy on AWS, then your applications will run on EC2 instances (virtual machines) with complete Windows or Linux operating systems.  Each application role (e.g. “frontend webserver”, “backend appserver”) will require distinct EC2 instance(s) configured specifically for that role.

Applications hosted on EC2 can still enjoy the benefits of the combined IaC and CI/CD pipeline process described in Part 1.  However, your CI/CD pipeline processes must consider that any changes to the complete operating system (e.g. O/S patching) might affect the executing application.  The pipeline processes, especially application testing, should also execute whenever any O/S changes occur.

An application’s EC2 instances must be configured, deployed, managed, and monitored.  Management tasks include O/S patching, backups, hardening, malware detection, and intrusion detection.  Remember – these are the same types of management tasks that are minimized through containerization, but here we are discussing applications hosted on complete EC2 instances.

Containers or not, Logicworks can help

Logicworks AWS Managed Services takes over these server management responsibilities so your team can focus on application development.  Logicworks has developed the tooling and 24×7 processes to perform these tasks in a best-practice and compliant manner.

If your application requires EC2 hosting, stay tuned for Part 3 of this series to learn more about how Logicworks Managed EC2 services provides similar benefits as container technologies, but for applications that are not architected for containers. If your application can be designed for and deployed on containers (or serverless), then stay tuned for Part 4: CI/CD for Kubernetes and EKS.