Introduction to Platform Engineering

Platform engineering seeks to streamline development and testing activities. The aim is to enable the team to concentrate on innovation and software quality, rather than being hampered by mundane tasks, such as raising tickets, or resolving configuration issues. By modernising the developer experience (DevX), platform engineering empowers developers and testers to be more productive and deliver superior technology.

Internal Developer Platforms (IDPs)

A key component of platform engineering is the creation of Internal Developer Platforms (IDPs). These platforms abstract the complexities of environments and provide developers with self-service capabilities, automation, and modern tooling. The IDP serves as a central hub to simplify tasks for developers and testers, reducing cognitive load and enabling teams to focus on innovation and quality.

An effective IDP provides:

• Reduced cognitive load
• Freedom to innovate
• Easy access to environments
• The right tools and software
• Reduced toil
• Less waiting
• A clear path for improvement and efficiency over time

IDP’s may differ by organization, but typically include dev tools, self-service, CI/CD, visibility, automation, and dev/test environments.

Development (Dev) Tools

The goal is to ensure new team members can become productive without spending too much time setting up their environment. This can be achieved by providing pre-configured developer environments – using IDEs such as browser-based VS Code with necessary extensions, or preinstalled applications on developer laptops. Shared configuration files, containerised or virtual development environments, and IDE options enable developers to work with their preferred tools.

For example, in the PopUp lab, VS Code with extensions like Zowe Explorer and IBM Z Open Editor have increased team productivity. Enabling developers to use familiar and preferred tools makes them more productive, and happier in their work, enhancing overall team performance.

Self Service

Self-service capabilities aim to accelerate development processes and increase output by reducing friction points and dependencies. This autonomy helps developers make decisions and take ownership of their work and eases the burden on supporting teams.

Self-service can be facilitated through resources such as Ansible playbooks for configuration changes (read more about what we have done here), which standardise processes and enable non-experts to safely make updates. API exposure allows integration from other teams without direct involvement. Enhanced observability supports self-service by enabling team members to independently access information, reducing wait times and context switching. By allowing developers to deploy changes, adjust configurations, and make infrastructure changes themselves, the team operates more efficiently and flexibly.

CI/CD Pipelines

Continuous Integration and Continuous Delivery (CI/CD) pipelines are fundamental modern DevOps practices. They provide fast feedback on code builds, testing outcomes, and deployment to test environments for validation.

In our lab, we have built pipeline templates and reusable workflows in GitHub Actions, enabling us to establish, for any new project, pipelines which include unit testing, integration testing, and end-to-end testing. Our approach is to start with basic tests packs and a working pipeline, and iteratively increase the test coverage. Our CI/CD pipelines also support auditability and transparency. Even when full automation may not be immediately feasible, incorporating manual steps into pipelines is a valuable stepping stone towards greater automation.

Visibility

Visibility is crucial for efficient resource use, informed decision-making, and waste reduction. Understanding what constitutes normal operations helps identify anomalies. Increased visibility (monitoring, inventories, dashboards and reports) goes a long way to reducing technical debt that arises when resources are forgotten and unnecessary new solutions are built.

In the PopUp team, we recently built a Prometheus and Grafana solution to increase visibility in our lab. We have progressed from a situation where people relied on 2 Linux admins to give them the infrastructure information they needed, to being able to immediately determine the answers to most questions alone. Our dashboards also display Z info, including which version of z/OS is running on a PopUp, z/OS status, DASD volume usage, and more.

Automation

Automating repetitive or error-prone tasks delivers significant benefits over time. Automating scripts and pipelines enables codified knowledge, so new joiners can quickly become productive without extensive training. Codification also enforces best practices, provides audit trails, and supports governance, with manual steps gradually being automated as processes mature.

In our lab we have heavily invested in Ansible automation, both for Z and Linux. We have built a range of playbooks to automate Z activities, including z/OS health checking, maintenance, config management, software installation, and user management.

Development and Test (DevTest) Environments

For mainframe teams, the absence of z/OS environments can halt development and testing, and in many cases has led to project cancellations. Traditional approaches often require raising tickets and waiting extensive periods for environments. In some cases, environments are entirely unavailable (our market survey echoes this).

The PopUp product enables z/OS environments to be spun up on demand, running on x86 or IFL resources. This enables the development of mainframe utilities and new customer features without the delays and limitations of shared resources.

Having disposable environments enables teams to experiment safely without impacting others or being constrained by corporate guidelines. Our new product option – FastTrack – can take snapshots of entire z/OS environments, enabling users to reset to previous states easily. This fosters innovation, as unsuccessful experiments can be effortlessly rolled back.

Each dev team member has their own disposable z/OS environment which they use for innovation, development and testing, training, and more.  We are not constrained by shared environments and can develop risk-free, knowing the environment can be recreated in seconds if needed. Furthermore, one of our clients reported that environment creation time reduced from six months to five minutes. As a result, downtime was eliminated, dependency on shared LPARs removed, and delivery cycles increased from 10 per year to 50. At PopUp Mainframe, we believe Platform Engineering brings tangible benefits to a development operation.