BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Electric Cloud Enhances Platform With Additional Mainframe and Microservices Capabilities

Electric Cloud Enhances Platform With Additional Mainframe and Microservices Capabilities

Bookmarks

New ElectricFlow DevOps Automation support for mainframe includes native automation capabilities both pre- and post-deployment and pipeline governance and security. A new native microservices model allows microservices to be treated as first-level objects so that they can be modeled independently of applications and environments, controlling container deployment either inside applications or as stand-alone, shared foundational components to container runtime environments.

New mainframe capabilities include:

  • System-level automation on z/OS, including JCL code and REXX
  • Native WebSphere and DB2 deployments on mainframe
  • Integration with Compuware ISPW to extend DevOps practices to the mainframe lifecycle
  • Integration with Compuware Topaz suite to incorporate static code analysis, unit testing and functional testing in the mainframe pipeline
  • The ability to extend all the above to other mainframe SCCM tools through an API and DSL
  • The current catalog of mainframe plugins for ElectricFlow includes: Compuware ISPW and Topaz, IBM WebSphere and DB2, z/OS for systems management and CICS Configuration Management

InfoQ asked Electric Cloud CTO Anders Wallgren to describe the pipeline governance and security capabilities now available to mainframe deployments:

ElectricFlow supports authentication through corporate directories (LDAP/AD) using an Access Control List (ACL) architecture. The ACL architecture supports inheritance and denial of access, which is a superset of RBAC, making RBAC straightforward to implement. All objects in the platform (applications, releases, environments, users, groups, etc) are governed by these ACLs. The inheritance mechanism makes it possible to delegate access to certain objects without having to make the delegate an administrator user of the system. Extending these capabilities to the mainframe means the mainframe is no longer a separate citadel of automation but an integral component. ElectricFlow can now be used as the policy enforcement engine to ensure only approved and compliant activities/actions/deployments move through to the mainframe. If someone Telnets directly into the mainframe and makes a change to a process or component in the pipeline, ElectricFlow is able to detect those changes (and reject them or rerun the process) by comparing what is actually being presented for the next stage against what was intended to be presented. If there is a difference, ElectricFlow provides the visibility and the logs into what changed and at what stage of the pipeline, providing the first bread crumbs for incident analysis.

Wallgren explained further that, throughout the pipeline, defined exit and entry criteria (called "gates") govern the progress of the software through the pipeline stages; these gates can be manual or automatic. Manual gates require human intervention to approve or reject progress through the gate and notifications are supplied to the proper groups or individuals who are responsible for such decisions. The UI reflects that the pipeline is "stalled" waiting for human approval but automatic gates can be used to accelerate this process where possible; for example, a gate can instantly block or allow progress based on code coverage results after the unit testing stage, or if test success rates don't meet certain thresholds. Wallgren added:

Security testing tools (static or dynamic) can be incorporated into the pipeline to, for example, make sure that third-party libraries are approved and not out-of-date with respect to security bulletins. Environments are subject to blackouts and reservations through the calendaring system. Release dependency requirements must be met - if Application A depends on a new version of Service B, then deployment of Application A can be blocked until that version of Service B is available.

InfoQ asked Wallgren to explain why the mainframe and microservices announcements were made simultaneously:

Microservices introduce complexities and challenges, so the dashboard and management functionality is designed to provide visibility and control over them. Digital transformation is driving changes in companies of all sizes, especially larger ones with vital Systems of Record resident on the mainframe. Moving those Systems of Record to distributed or cloud systems is often difficult. Organisations can’t just abandon their Systems of Record; they either have to find a way to make it an integral component of their strategy or find a way to safely transition away from it. ElectricCloud looks at the mainframe and digital transformation as an ecosystem. The combination of mainframe integration and microservices capabilities provides organisations with the ability to make their mainframe an integral component of their digital strategy as well as providing the pathway, via microservices, to transition off the mainframe safely and at the speed of the business. A deployment package (of microservices) could be made of a number of items one/some of which would be z0S related.

ElectricFlow previously addressed container management challenges such as container-specific scripts and automation and version dependency at runtime, particularly with large container inventories. The new version of ElectricFlow provides the native microservices support and a series of new plug-ins for deploying to native Docker environments, Docker Swarm, and Docker. ElectricFlow DevOps Insights now includes new dashboards, which provide information about microservices deployments in a given time period, by environment and per cluster. The microservices dashboard can be broken down by successes, failures, most commonly deployed and which clusters are most heavily utilized. DevOps Insights provides details on how many microservices were deployed by ElectricFlow versus how many were deployed directly.

Electric Cloud customer SOMOS used a mainframe to manage and administer over 41 million Toll-Free Numbers in the US and Canada for over 30 years. Recently, they decided to move off this 30-year-old mainframe application. Gary McKay, ScrumMaster at SOMOS, said:

One of our many challenges was how to modernize and build a DevOps culture and environment for SOMOS while simultaneously moving to a microservices architecture. We chose Electric Cloud’s ElectricFlow because of its support for both containerized and mainframe workloads, and because it can coordinate delivery of those workloads across all our development and production environments.

Rate this Article

Adoption
Style

BT