CDA and Container Technologies

CDA supports container orchestration tools such as Kubernetes or Docker Swarm to create agile applications that can be easily deployed. CDA and Automic Continuous Delivery Director play a key role in bridging the gap between container technologies and the reality of complex enterprise application delivery.

Automic Continuous Delivery Automation can deploy three different types of Applications:

On-premises applications (monolithic, multi-tier): server-based java/.net apps, packages ERP apps, mainframe apps
Hybrid applications: on-premises cloud hybrid apps, multi-tier microservices hybrid apps
Next generation applications: cloud, microservices, containers, multi-channel, complex service dependencies. Focus on shift left: release and test pipeline configuration, continuous testing, and analytics across complex multi-channel release pipelines.

Next generation applications break up the services of a traditional multi-tiered Application (FRONTEND-DATABASE-REST API) into smaller chunks, aka microservices. Microservices are small components with a single function, for example, analyzing a report. They run in a container (for example, Docker) with the minimum resources to make them work (code, runtime, system tools, and system libraries). Containers are portable: Any environment supporting a container standard can run the container.

Each microservice can trigger an event when a change takes place. For example, a microservice can trigger an event in CDA which releases a new feature request within a defined interval. After the event is triggered, other microservices listen out, and act accordingly. For example, the request is evaluated with data that is gathered from a user community voting system and the most popular request gets picked. Then an e-mail is sent to a developer with the feature request and a link to the ide.

Containers can be easily modified while the application is still running, which greatly reduces downtime. Services are isolated and so is the risk. All services have a corresponding deployment type, which allows non-disruptive rollout of a new container. Furthermore, developers have more control over the code and therefore play a more relevant role in the application deployment (shift left).

The following table compares some aspects of monolithic/multi-tier and containerized Application Deployments:

Feature	Monolithic / Multi-tier Applications	Containerized Applications
Process	Provision Environment.	Terminate, Instantiate, rinse, and repeat.
Artifacts	Collect artifacts and distribute them to endpoints.	Containers = Artifacts
Workflows	Deploy artifacts and use workflows for configuration Management workflows to scale up / down, tear down, and so on	Code and Configuration are packaged up in container. No need for workflows Superior container orchestration options available
Agents	Agents are required for workflow execution.	No agents are needed.
Toolchain	Pre- and Post Orchestration of toolchain using workflows.	Pre- and Post Orchestration of toolchain outside container scope using scripts.

Scenario

You can perform an event-driven ticket remediation by using the orchestration capabilities of CDA together with CA APM, Kubernetes, AWS, Event Engine, and ServiceNow.

In this use case, CA APM monitors a Kubernetes Application. The front-end part is a Docker container that is hosted with a Kubernetes cluster, which gets the information from a SQL Server database. When a disaster occurs, CA APM sends an alert (REST request) to the Event Engine. Then, the Event Engine triggers the execution of a deployment Workflow in the Automation Engine. This workflow executes some Actions to recover from the problem that is detected by CA APM and protocols everything in a ServiceNow ticket.