IBM is proud to announce a new offering of flexible DevOps tooling for enterprises that are wrestling with DevOps Day 1 and Day 2 challenges. The offering is IBM DevOps for IBM Cloud Paks (available Aug 4). This DevOps offering includes continuous delivery tools that are designed to help enterprises embrace continuous delivery for speed while improving governance, scale and quality at the same time.
DevOps Day 1 is used to describe the period of time when a team or an organization embarks on the DevOps journey. DevOps Day 1 is focused on automation: automating software builds (continuous integration), application deployments (continuous delivery) and possibly also automated tests (continuous testing ). At this stage, the team is looking for quick wins that will improve time to production, reduce errors that stem from manual processes, and potentially provide more automation as a service to a wide group of colleagues. Once the basic automation is in place and repeatable, the teams then ask, how do we get better? Or just as likely, the business asks: "How can we as a company deliver faster to the market?" and by the way "Don't spend more budget."
DevOps Day 2 is the next phase of the DevOps Journey when a team or an organization implements DevOps in a more strategic, circumspect way with an aim to tackle challenges that became apparent during DevOps Day 1.
Tool Fragmentation
In DevOps Day 1, we notice that developers are using a lot of open source tools. Devs adopt free community technologies to get the job done, leading to a proliferation of open source tools. There are a lot of great open source tools available, each with its own je ne sais quoi for the developer who uses it. But the downside of the open source free-for-all is an incompatibility across tools, lack of easy integration, problems with supported version clashes, and concerns over security and performance of all the varied tools. The diversity becomes a problem in itself.
As we enter DevOps Day 2, we see organizations limiting or standardizing on a subset of tools that form into pipelines. Standardization on the best tool(s) for the job helps simplify the IT environment and improve the depth of expertise on the tools within the organization. Standardization doesn't necessarily mean stablization - the tools could change over time, and there will be overlap in tool lifelines. You often have standard pipelines per team and multiple teams contributing to one application. Now, the concern is more about how to orchestrate and understand these pipelines at the application level. What version of a component is available and in which stage of delivery pipeline? Is Team A's work almost done as Team B gets started - how can I "see" the pipelines?
Accelerated releases
A big part of Day 1 DevOps is getting faster and betting a lot on automation to do that. Automation delivers speed and the gains are easily won in Day 1. Day 2 DevOps expects that releases will get ever faster. Teams may move from quarterly to monthly updates, other teams go straight to daily or even hourly changes. New dev strategies emerge that help with time to market too - like dark launches, A-B tests, and feature flags. The concern now in Day 2 is how to keep track of all the changes? how to ensure quality of so many changes? Automation is the foundation, but governance must be added.
Scalability and moving to cloud native
During DevOps Day 1 when automation is taking hold, there is not a lot of concern about scalability. Questions like "Will my DevOps automation scale to hundreds of applications and thousands of environments"? "Will my DevOps tools serve all my organization's platforms - distributed VMs as well as public and private clouds"? "What about container platforms"? "What about mainframe"?
Reaching DevOps Day 2, teams realize that standardizing on a pipeline that serves all platforms and scales horizontally can increase simplification and reap benefits.
Governing cloud native releases
During DevOps Day 1, building containers and running them in production seems futuristic. Working in DevOps Day 2, teams are actively building and releasing containers, maybe just for dev and test with an eye on using them for production because of the benefit containers afford like easy scaling and portability. What comes to light as more teams are building containers and developing containerized or cloud native applications is that very quickly there are a lot of containers! How can you keep track of each one and its multiple versions? Governance, control, visibility, become increasingly important.
IBM's Cloud Paks offer a secure, performance-tested container platform based on Red Hat OpenShift. The certified containers and common services layered on top of the Cloud Pak platforms provide powerful, secure and scalable tools for the enterprise to solve problems that range from analytics to multicloud management to application development. DevOps for Cloud Paks includes deployment automation, testing and data analytics capabilities for the IBM products that were developed and tested by IBM and IBM clients. DevOps for Cloud Paks extends beyond integrations with the IBM tools to include integrations with many open source products, offering DevOps governance, visibility and cohesion over all of the technologies.
DevOps and the Mainframe
When you talk about the mainframe development for an application, you are probably talking about developers who are separate from the distributed team. These are devs who work on their own, with their special z tools and culture. During DevOps Day 1, the mainframe team starts using some modern tools for development that are no longer on green screen and could be learned by someone not fluent in z systems. This initial step makes it much easier to hire new team members and to work more closely with the distributed teams who have similar development context.
DevOps Day 2 for the mainframe means moving toward the same or similar tool set as the distributed team to the point where there is a single pipeline for both (all) teams. An example of such a pipeline that serves all platforms includes Git, Jenkins, Artifactory, UrbanCode, and Rational Test tools. These tools work across platforms and allow for tighter collaboration among teams, providing governance over the entire delivery process and increased simplification. Sprinkle in IBM Dependency Based Build for the z software builds and IBM Developer for z for code development.
Delivery focus expands beyond CI/CD
During DevOps Day 1, teams have automated all they can and have established a CI/CD pipeline with tools like Jenkins and UrbanCode to deploy applications basically anywhere. In Day 2, data analytics, value stream mapping and machine learning help teams find where the bottlenecks are in the delivery process by collecting data and analyzing data from the pipeline. Automated testing during the CI process lowers the cost of fixing defects and quality tests benchmarks in upper environments allow the continuous delivery process to promote code automatically when it meets quality requirements.
The new offering, IBM DevOps for IBM Cloud Paks provides the out of the box tooling to help with each of these challenges that software delivery teams encounter in DevOps Day 1 and Day2.
To learn more:
#DevOps#devopsforcloudpak