If you’ve read any of my blogs, you’ll recognize the adoption of the term ‘DevOps 2.0’. DevOps 2.0 includes all groups that contribute to delivering working, elastic, secure software and infrastructure with predictable costs. I like this term as it recognizes equality among groups without having to add any additional terms to the DevOps name and brand.
If we followed the precepts of a 'DevSecOps' naming convention, we could easily wind up with more fractional names like - ‘DevRegOps’, ‘DevTestOps’, ‘DevComlOps’, and ‘DevPerfOps’. Not a good place to be for practitioners or leadership trying to build consensus to action.
On to 2018 DevOps 2.0 predictions...Based on DevOps adoption and its visibility in 2017, senior leaders will become more involved in DevOps 2.0. While many DevOps practices have been driven at the grass-roots, or product level, 2018 will see senior leaders developing and delivering powerful narratives to inspire the enterprise and move people to action on DevOps 2.0. Leaders need to align organizational thinking so that all product teams know where they’re going and how they’re getting there
Automation is a common theme in DevOps - and there is lot of basic automation employed in the building, testing and deploying of a product; if the team takes advantage of various IDE plug-ins. However, we see very little automation with it comes to building and managing the engineering environment used to create and deliver products and infrastructure.
DevOps 2.0 organizations will close these gaps in 2018. We see teams losing almost half of their overall productivity because they are manually creating and managing their own engineering environments. Test organization are particularly susceptible to productivity pressures. Engineering environment management includes the installation, configuration and management of the entire tool stack. These tools plan, code, build, test, package, promote, and report on products and infrastructure. 2018 is the year where teams will start to automate the creation and management of these tool stacks. Leaders must understand these issues as Engineering Environment Automation will require senior leadership.
Companies are benefiting from Containers and Clusters today, primarily for simplifying the deployment of products across environments. While containers provide software a reliable and predictable way to deploy to a node, clusters bind multiple nodes together and allow the creation and management of logical infrastructure. In DevOps 2.0, container and clustering technologies will be used to build enterprise ready and fully configured DevOps infrastructure.
A simple example of the difference is having a Jenkins server and its worker nodes manually installed and manually configured by your DevOps team. In DevOps 2.0, the environment and the configuration of Jenkins is built from code. This is known as ‘configuration-as-code’ and it represents true Automation. Finally, this approach can address availability and security requirements to make DevOps 2.0 automation Enterprise ready!
Learn about Astadia's Enterprise DevOps solutions here.
Everybody agrees that automation is key to mainframe modernization regardless of the selected transformation approach, particularly in replatforming or refactoring projects. Not everybody, however, has the vision to automate the journey all the way.
COBOL talent shortage is a major mainframe modernization driver and that’s when every IT leader must make a decision about what will happen to the COBOL programmers in this scenario.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now