Synopsis

DelOps – Delivery to Operations

As DevOps is meant to be a cultural rather than a technical transformation we realized that in the implementation diversities of respective solutions an essential and time-consuming part is missing which has been left out because more of its organizational than its technical impact. Affected sectors are those which heavily rely on external software suppliers delivering neutral versions of software needed to be customized and deployed on-premise because of segregation of responsibilities, confidential and audition policies.

Especially the financial sector is affected and not affine to go for a cloud based solution or other DevOps innovation in the near future. To fully implement the missing link between the supplier(vendor) and the client a combination of disruptive and old technologies challenges today’s skill-sets. We successfully implemented a solution to amend and automate in a generic and almost industrially standardized way the communication between the vendor and the consumer to enable a full end-2-end application deployment automation incl. infrastructure and configuration management.

Problem Worth Solving

There are two aspects in the “traditional” DevOps approaches, which are partially implemented or completely missing. In the following, we try to tackle the core of both aspects. They mostly relate to companies coming from the financial sector or non-IT companies (“buy not make companies”) that enrich their processes through external software solutions. 

In focus are traditional private banks which are affected extremely by special regulations and restrictions due to security policies and a lack of contemporary IT know-how. These entities excel themselves by uncontrolled purchase of line of business application without considering non-functional and operational requirements. 

External changes coming as external package deliveries to those lines of business application must go through an internal change management process to be approved and successively customized/configured and deployed to internal infrastructures. The infrastructure as well is often subject to changes which opens another topic on automation of infrastructure provisioning.

Our Solution

First missing puzzle piece Automated processing of external software packages and computable release notes including automated infrastructure provisioning.

The typical and official build and deployment pipelines start on premise, making it easy to map deployable artefacts and their content to an internal infrastructure through plugins, built-in or extension functionalities of the build tool. For example, a Nuget package from Microsoft or an EAR file from JBoss is a good example. However, how

can volatile contents of third party deliveries from external software suppliers be embedded in the internal DelOps processes in a similar way? Some potential solutions can be found on popular design patterns coming from software engineering to solve this problem. Using the adapter pattern, a DSL (Domain Specific Language) or the transformation approach by XSLT, a standardized processing of volatile content of deliveries can be introduced here. We started an open source initiative as DerSalvador GmbH to create a standard protocol in describing (third-party) package contents. The solution consists essentially of an XML-DSL or JSON-DSL which is designed for generic packet contents. This DSL is of course extensible according to the specific requirements. It includes not only typical DevOps aspects, but also all business and operating processes such as change and release management, monitoring, security and automated provisioning of infrastructure. The goal is also to integrate these processes into the entire DevOps deployment process in an automated form. For example, an ITIL Standard Change could be automatically detected, the security checks, and the automated UAT test executed, so that a production deployment of external packages could take place in minutes. Nowadays the introduction of a standard change in private banks in production still takes very often about 2 days. These bottlenecks are found in companies with a rigid change and release management culture and a DevOps- unfriendly environment. Our DelOps approach can achieve deployment Lead-Times similar to successful Fintech Startups.

Second Missing Puzzle Piece Continuous review for security gaps in build and deployment pipelines

In the context of automating application and infrastructure deployments right up to production, the possibilities of extensive manual security, compliance, and policy tests based on the concept of “Segregation of Duties (SoD)” are often forgotten or inadequately implemented. Risks arise when external libraries are used in the deep dependencies tree of the open source community, for example, which are not even known to the developer. These libraries can contain both vulnerabilities and explicit viruses. A full automated discovery is difficult. The OWASP (Open Web Application Security Project) community, for example, or official online databases with information on third party libraries and their security holes, can provide a remedy here. They are usually equipped for embedding in Build, and Deployment pipeline with REST-APIs to enable a fully automated check. Developers are usually not inclined to use these plugins, so that often the responsibility falls back to the Sys-, or SecOps. Only with the DevOps culture such important processes can be established into a common pipeline.