devopsy.kinsta.cloud

Tag: automation

Latest Chef Habitat Release Embraces On-Premises IT

Chef today announced that the Chef Habitat automation framework for building and deploying applications can now be used in on-premises IT environments.

Mike Krasnow, a senior product manager for Chef, said version 1.5 of Habitat makes it possible to now store applications packages and their dependencies locally in addition to the cloud. In addition, pre-built application packages and dependencies from the Builder service can be deployed across multiple on-premises instances.

An Applications tab in Chef Automate now shows the service groups and instances that are deployed to make it easier to understand what’s deployed where and the health of each service. Both the Habitat Builder installer and the application dashboard are integrated with Chef Automate, which uses the same installer as Chef Habitat.

Finally, the Habitat Supervisor module is now more stable, easier to configure and manage, and provides improved support for Windows applications.

Krasnow said Chef has seen a 300% increase in the use of the software-as-a-service (SaaS) instance of Chef Habitat in the last year. Organizations that have embraced Chef Habitat include Alaska Airlines, Rakuten, and Walmart. That rate of adoption should increase now that an on-premises edition is available, he said, including among IT organizations in highly regulated industries that are not allowed to employ cloud services. In fact, at least 70% of all application workloads are still deployed in on-premises IT environments.

Chef Habitat appeals most to organizations that have embraced best DevOps practices to programmatically deploy applications, said Krasnow. There are rival automation platforms that make use of declarative approaches to automation that appeal more to IT generalists. However, he noted, organizations that want to empower DevOps teams tend to prefer a more programmatic approach.

For more than a decade now Chef has been driving adoption of IT automation. However, it’s only relatively recently that organizations have been employing IT automation at scale as part of their efforts to embrace best DevOps practices. As interest in IT automation frameworks has risen, so too has the number of options. Some organizations are even employing multiple IT automation frameworks within different business units. They may one day standardize on a single IT automation framework, but many DevOps teams will simply opt to employ the IT automation framework the members of their team already know. If the members of that team in charge of IT operations don’t have a lot of programming expertise, chances are high they will opt for a more declarative approach. DevOps teams that have developers who deploy applications on their own are likely to prefer a more programmatic approach.

Regardless of the platform chosen, it’s clear the days of manually deploying applications using custom scripts are coming to an end. IT organizations now require an industrial approach to managing IT as a factory. The biggest challenge achieving that goal is no longer the technology but rather the culture of the IT organization.

— Mike Vizard

January 29, 2020
Are US Workers Threatened by Automation?

There’s been plenty of predictions about the impact of automation on the workforce: from enhancing the ability of workers to do their jobs to those who argue intelligent automation will eventually decimate the human workforce. The issue even made it to the Democratic presidential 2020 primary race with candidate Andrew Yang’s “Freedom Dividend.”

Still, if a recently published survey from business process automation provider Sykes is any indication, American workers aren’t very concerned. In fact, two-thirds of those Americans surveyed indicated they have yet to see automation on the job: 66% said that automation did not assist them with repetitive tasks in 2019. That response diverged with millennials (those 25 to 34 in this survey), with 41% saying that automaton has assisted them in their jobs last year.

Most Americans show a positive attitude toward on-the-job automation. According to the survey, 63% of respondents said that they could be better at their jobs if automating certain tasks enabled them to do more in less time. Not surprisingly, the percentage was highest, 71%, with the youngest (18 to 24) age group. Further, two-thirds of respondents said they would more likely apply at a company that is investing in automation technologies.

Indeed, the majority (58%) of respondent employers are actually providing some or a lot of training or other resources to help employees keep current with technological change.

The vast majority, 84%, of respondents believe their jobs will soon involve new automation technologies and expect some of their work to be completed by automation in 2020. While most respondents were open to increasingly working with automation to complete their jobs, few want to work for bots. The majority, a sizable 87%, said they are more willing to take orders from a human than a software bot (13%).

What industries do respondents think will be the most impacted by automation? In order, the U.S. workers surveyed believe manufacturing (65%), telecommunications (50%), and transportation (38%).

When it comes to public programs designed to mitigate the impact of automation on the workforce. However, 57% of workers believe that the U.S. government has a responsibility to compensate workers whose jobs are lost to automation. Of those, only 32% believe Universal Basic Income is the way to address jobs lost to automation, while 25% look to the existing welfare system. About 43% of workers do not think it’s the government’s role to compensate those whose lost their job because of automation.

The Sykes survey is based on the responses of 1,500 employed within the United States.

— George V. Hulme

January 24, 2020
LogicMonitor Acquires Unomaly to Advance AIOps

LogicMonitor this week revealed it has acquired Unomaly, a provider of tools infused with machine learning algorithms that make it easier to analyze large volumes of log data.

Tej Redkar, chief product officer for LogicMonitor, said the acquisition of Unomaly will advance a previously announced AIOps initiative through which LogicMonitor will embed advanced analytics and automation capabilities into its core IT monitoring platform. Rather than requiring DevOps teams to acquire a separate platform to take advantage of AIOps, LogicMonitor contends AIOps is simply an element of the next logical iteration of an IT monitoring platform.

Unomaly will help LogicMonitor achieve that goal by identifying patterns in streaming log data that are indicative of anomalies that warrant further investigation, said Redkar. Unomaly works by first establishing a baseline for the IT environment. It then records a profile for each log event that includes the event’s structure, sources, frequency patterns and intervals. Similar profiles are then merged into one aggregated profile, with dynamic parameters to reduce the amount of data that needs to be analyzed by several orders of magnitude. If an anomalous event occurs within a rolling 60-second window on a single log source, Unomaly will bring those events together to identify and score a situation based on the type and number of anomalies.
Redkar noted this approach not only provides more context about the events but it also greatly reduces the amount of log data that needs to be stored. Unomaly is also designed to accept data in any format.

As IT becomes increasingly more complex, organizations of all sizes need more observability. However, because all the dependencies within the IT environment are becoming too complex to track manually, IT organizations will need to rely more on machine and deep learning algorithms to observe the IT environment.

Naturally, that increased reliance on algorithms will alter the role of IT operations teams. Most IT operations teams will find themselves supervising algorithms that are surfacing issues and making recommendations, said Redkar. Rather than eliminating the need for IT operations expertise, AIOps will be employed mainly to manage IT environments operating at a significantly higher scale, he noted.

It will take some time for this transition to play out as issues such as the explainability of AI models are worked out. Some of the lower-level functions within an IT operations environment undoubtedly will be eliminated, so job roles will change. However, many of those functions will be rote tasks that many IT professionals don’t especially like to perform.

IT vendors are, of course, involved in something akin to an algorithms arms race to infuse AI into their management platforms. In some cases, they will develop these capabilities themselves. In other cases, they will acquire startups to gain access to AIOps platforms. Most IT vendors will be mixing and matching a variety of AI technologies they developed themselves and acquired. Regardless of the path pursued, it’s no longer a question of whether AIOps will be applied to managing IT, but rather when.

— Mike Vizard

January 17, 2020
The Difference Between Capacity and Scalability Planning

Not only does the tech industry love terms, we love to make them super nuanced. For example SecOps versus DevSecOps, continuous delivery versus continuous deployment, hybrid cloud versus multi-cloud, etc. These terms may seem similar on the surface, but when you dig in they are quite different.

Here are two more: capacity planning versus scalability planning. Both are critical aspects of keeping applications up and running, but two different activities.

The reason we invest time in capacity and scalability planning is simple: We want to make sure that system resources such as compute, storage and memory are not the cause of an application outage. It is a response to expected and unexpected increases in application usage, as well as the steady growth of application adoption.

Here are a few differences between capacity planning and scalability planning.

Long Term Versus Short Term

Capacity planning is more focused on the base resources, as it relates to the long-term growth in application traffic. The goal is to have enough resources to handle the steady state of the application without breaking the bank by over anticipating usage. With capacity planning there is a big assumption that the application requires to always have a pool of resources available.

Automated Versus Static

Scalability could be a manual task, you see utilization creeping up and you respond with more instances. This is probably more common than not. But I don’t believe it’s the overall objective of most teams. Auto-scaling is the goal, where the system knows on its own when it’s time to spin up new resources. The public cloud providers, instrumentation of kubernetes, etc., help support this. Whereas capacity planning is a more deliberate identification of needs, and then statically setting those resource needs within the cloud.

Strategic Versus Responsive

Similar to static versus automated, capacity planning is a more strategic activity whereas scalability planning is a more responsive activity. Usually, scalability comes up during peak usage activities such as black Friday sales or school registrations.

Capacity planning generally calls for more research and leveraging tools such as load balancers and historic data to understand the best path forward. It also should involve the input from the broader team, especially development to discuss the resource usage of new functionality and application architectures.

There is a good possibility that scalability planning could be all that is left with some modern applications. The reason this might be true is resource allocation theoretically can be 100% application based, where the resources are always one step ahead of current utilization. In order to embrace this model resources need to be provisioned 100% automatic, which means that all infrastructure needs to be scripted. As more companies adopt serverless components of their application, this is already inherently true.

Capacity planning is where most operations teams spend their time, but resource utilization is shifting left and scalability planning is becoming more common. Scalability planning has become the responsibility of DevOps engineers, SREs and even developers. The main reason capacity planning will survive the long haul relates to budgets. While the application itself can fully control the infrastructure laid out before it, the IT organization and the organization itself will want to impose an upper limit so there is an indicator of when the cost of running the application on the resources may or may not be an issue. Capacity planning in this case will be purely a cost control mechanism, and negotiated just as any budgets are.

— Chris Riley

January 17, 2020
SaltStack Extends IT Automation Framework

SaltStack today added three open source modules to its portfolio that make it easier to automate the management of IT at scale.

Heist is a plugin that allows organizations to create agents that will dissolve after a specific amount of time. Umbra is a plugin that gathers data streams to make it easier for machine learning algorithms to consume.

Finally, Idem is a declarative programming language that enables IT teams to create workflows based on stateful constructs that can be used in conjunction with any IT automation framework or systems management tool.

All three modules are based on the Salt Plugin Oriented Programming (POP) model. Company CTO Thomas Hatch said SaltStack created POP to make it easier to manage modules and libraries of code within a monolithic application without having to transition to a different microservices-based architecture based on containers.

That POP approach also serves to make it easier to test modules within a monolithic application environment, he said.

SaltStack used POP to create Salt, an open source IT automation framework that serves as the foundation for the commercial IT automation platform provided by SaltStack. Organizations that have embraced the open source Salt project include Juniper Networks, Cloudflare, Nutanix, SUSE, LinkedIn and eBay.

Heist extends the Salt project by giving DevOps teams an alternative to having to commit to either an agent or agentless-based approach to managing IT. Instead, DevOps teams can create an agent to collect data that will run only as long as it’s needed.

Umbra, meanwhile, prepares data to be consumed by machine learning algorithms transparently, which Hatch said is critical in providing visibility into how artificial intelligence (AI) models are constructed. That capability is going to be a requirement in any regulated industry that requires organizations to comply with IT audits, he noted.

IT automation frameworks are, of course, foundational to any set of best DevOps practices. While most of the initial IT automation management frameworks were proprietary, the entire category has gained more traction as open source implementations of these frameworks became available. Now DevOps teams have a plethora of open source and commercial IT automation frameworks on which to define a set of DevOps processes.

The biggest challenge in getting IT teams to embrace these frameworks historically has been the preference of many IT professionals for scripts they develop. However, as the scale of the IT management challenge has increased in the age of the cloud, relying on scripts that are often undocumented has become problematic. Industrial-scale IT organizations require IT automation frameworks that allow them to create reusable playbooks that are easily documented. Otherwise, every time an IT professional who authored a script leaves the company, the IT organization soon discovers the script they’ve been relying on that has broken can’t be fixed easily.

The day when all IT organizations rely on some form of an IT automation framework is fast approaching. In fact, the remaining IT automation challenges have a lot more to do with the culture within the IT organization than they do any of the technical capabilities of the platforms being considered.

— Mike Vizard

January 15, 2020
How to Use DevOps for Compliance

Picture this: You’ve been working in an organization’s IT department for a couple of years and tasks have become quite a routine. Some documentation here and there, code reviews, end-user training, routine meetings with the developers and so on. You can do literally everything with your eyes closed.

Then, all of a sudden, the company is going public and you feel like you’ve been thrown into a different dimension. There are new procedures to follow, endless meetings to attend and a ton of paperwork to be shipped. And don’t forget the new compliance regulations.

When this happens, do you gamble and quit or stick around and accept the new reality? Is there a truly viable option?

In comes DevOps.

DevOps means different things to different companies. Some IT experts consider it a fad while others swear of its significance.

In many organizations, DevOps combines development and operations. With it comes automation, efficiency and more transparency. With DevOps, changes can be rolled out much quicker.

DevOps can be the silver bullet for organizations looking to keep up with HIPAA, GDPR, PCI SOX and other industry regulations.

Here are four strategies for using DevOps for compliance.

Keep Track of Documentation

A big part of compliance involves documentation. Yes, boring but critical. With a unified development and operations team, you can merge the documentation processes of those who release changes and those who make them. It’s also easier to get everyone on board when it comes to compliance requirements.

You can use the newfound synergy between dev and ops to avoid documentation bottlenecks by adopting a unified and trackable version control system. Tools such as Git, wiki pages and internal dashboards can be used to harmonize documentation and version control.

Make sure everyone is on board by conducting routine training and holding meetings involving both dev and ops personnel.

Leverage DevOps Automation

Part of the reason why DevOps has attracted so much attention is the automation it brings.

With DevOps, time-consuming tasks such as monitoring pull requests, internal audits, access controls, code reviews, failovers and code coverage can be optimized through a transparent, unified and automated system. For instance, you can link all deployments, code review and build results in a single process to streamline audits and daily operations.

DevOps automation not only helps to streamline internal processes but also in demonstrating that you have met all compliance requirements. Things like access control and failover/recovery processes can stifle your compliance efforts if they are not optimized through automation.

Streamlining Dev Workflows for Compliance

Most compliance problems stem from messy development workflows that are not helpful for those keeping track of updates. For instance, an update that is put into production without going through the normal stress tests or internal reviews is not helpful. With multiple teams working on different features during the development stage, it’s easy to overlook small updates that could potentially introduce vulnerabilities.

DevOps helps to prevent accidental compliance breaches emanating from flawed dev workflows. This is achieved through the integration of stress testing into the development process itself.

With DevOps, you don’t have to wait until an update is ready for production to stress test it. Working with a dedicated compliance team, you can create a compliance blueprint in the form of a testing and logging system to keep track of code that is still in the production stage way before it goes into production.

Foster a Compliance Culture

In a non-DevOps environment, it’s common for different teams or individuals to blame each other, refuse to take responsibility or be out of touch with processes that are not in their job description or assignment. To ensure compliance, a bit of team management is required through communication and culture development.

DevOps makes this process easier thanks to the improved inter-team dynamics, automated processes and increased transparency. It’s easier to merge the dev and ops teams to help identify potential trouble spots and ways of resolving them. The operations staff will not blame the developers when a disaster occurs if they were part of the entire process and vice versa.

Effective teams always take responsibility instead of looking for a fall guy or starting finger-pointing when something is amiss. Inculcate a culture of compliance in your teams by ensuring that they are all aware of what is required of them and their shared responsibilities.

From the above, it is clear that DevOps can be the only thing you need to ensure compliance in your organization. However, adopting multiple recommendations at a go can be challenging. Therefore, take it one step at a time and use available tools, such as Git, to implement some of these processes.

— Ken Lynch

January 15, 2020
Why Is QA so Important in Executing a DevOps Implementation Strategy?

In a rapidly growing global digital landscape, enterprises are facing many challenges. These include changing customer behavior and the need to be in line with the latest technology trends. To address these challenges and to stay up the competition curve, enterprises are adopting a slew of strategies. These comprise expanding the capacity of processes, quick quality checking and delivery of applications and timely marketing of the applications. This is where DevOps comes as a one-stop solution to the aforementioned requirements.

When it comes to assuring the quality of software applications, the Agile and DevOps model of testing is favored over the traditional waterfall model. This is because software applications need to be tested across a swathe of platforms—devices, browsers and operating systems. In the DevOps scheme of things, software builds are continuously integrated and deployed in the development pipeline by using test automation. It involves the development and implementation of new features along with the streamlining of processes.

What Is DevOps?

DevOps is an amalgamation of terms “development” and “operations” and is underpinned on four basic pillars—culture, tools, collaboration and practices. Combining processes and philosophies, the DevOps approach helps enterprises deliver quality builds in the SDLC. Here, development and operations teams no longer work in silos but in close coordination with each other. As a result, quality becomes a shared responsibility and a culture of accountability gains ground. DevOps implementation leads to the quick development and deployment of quality builds, faster solving of critical issues and engendering greater trust and confidence.

Let us understand the best DevOps implementation strategies to derive outcomes such as continuous integration (CI) and continuous delivery (CD). To begin with, getting the QA basics right the first time and every time should be considered as part of the strategy. This is due to the fact that in a pure DevOps ecosystem, the lines between development and QA are blurred.

Test Automation

Since the software needs to have an omnichannel interface with third-party applications to perform optimally, the test process should be automated. There should be a smooth QA-DevOps alignment to detect and mitigate glitches early on in the SDLC. Thus, DevOps testing may involve choosing automated tools that are either open-source or commercial.

Teams Merge

To derive DevOps transformation, the integration of the QA team with other technical specialists becomes important. The final DevOps team should adapt a culture wherein identifying glitches becomes a shared responsibility.

Metrics

Since DevOps testing is all about quick identification and fixing of glitches, the metrics should be defined at the beginning. It will help the DevOps team to stay focused on the challenges and requirements. This calls for the QA engineers to setup test requirements into the workflow and guide the team therein.

Virtualization

The software application should be tested across a slew of platforms—devices, browsers or operating systems. Since it is well-nigh impossible to test the codes for numerous users (during usability testing), the same ought to be created virtually. The QA team can virtualize every test requirement to emulate the behavior of software components. Moreover, it helps to do away with the need for dependencies and addresses constraints faced in interdependent environments.

Choose the Right Tools

To enable DevOps automation, the QA team should choose the right test automation tool. The main criteria for choosing the tool should be the team’s expertise in using it. The tool should offer the ease of writing the test script in a single programming language. It should allow the testing of applications across operating platforms and browsers.

Continuous Integration and Continuous Deployment

These are the outcomes of any DevOps methodology. DevOps continuous integration and deployment encompass adding code changes in a repository and creating automated builds. This leads to an early recovery from failures as well as testing and delivery of products within fast turnarounds. Continuous integration based on test automation leverages regression testing and a version control system when a new code is added. Further, DevOps continuous deployment is about the capability to add new features to the existing applications. This makes enterprises follow a user-driven improvement of software and agile approach.

Conclusion

With the quality of software applications becoming the final arbiter in making an enterprise successful, taking the DevOps approach is crucial. However, since the whole process is hinged on executing comprehensive quality testing, the QA basics should be done right.

— Akshaya Choudhary

January 14, 2020
Five IT Ops-tackles that Stifle Business Growth

I was recently asked about the top five IT obstacles that stifle business growth, and I want to help clear a path too often lined with fear, uncertainty and doubt. In the not-so-distant past, IT was all about the tools. Solutions were more straightforward, teams were less globally connected, and the ever-present data deluge was not changing our business landscape by the millisecond.

With this in mind, I have created a list of the five most common IT obstacles and will pinpoint the single tool you can implement to help alleviate these pain points.

IT Staff Lack Time to Learn New Technologies

This is not to slam our tech teams or leaders; this is just the byproduct of condensed customer schedules, tight purse strings and managing the MOOSE (maintenance and operations of the organization, systems and equipment). The demand on IT teams is high, and we don’t always have the opportunity or the resources to restructure operations for a new tool, as upgrading requires learning new APIs, UI/UX and deployment architectures.

Difficulty Supporting New Technologies Quickly

It is hard to keep pace with IT complexity and manage it properly. New services, applications and infrastructures are constantly being added and there are plenty of vendors out there that will get you locked into solving a single issue versus addressing your macro problems. While the benefits of upgrading are there, the difficulty lies in understanding the complexity of these systems and how to leverage them most effectively.

Lack of Support for Hybrid IT

Hybrid by definition adds complexity, and multi-cloud, on-prem and private/public clouds are only a few ways to make your hybrid dream a nightmare. No matter the combination, understanding different architectures and their components is a must. Additionally, we need to understand how we manage our own data as well as how our vendors are managing it.

IT Complexity

We need to know our machines and architectures well enough to focus limited resources on what impacts the business most. IT will always be complex—there’s always something new, and the amount of information to process is insurmountable and exhausting. Adding context to IT data can help you identify the root cause of overly complex systems. The most difficult task will be to understand the technology well enough to know what to do next.

Inability to Understand Business Impact in Order to Prioritize Tasks

Prioritization is by far the most important aspect of IT. There is a lot of noise, lack of visibility, lack of context, and—the squeakiest wheels of them all—legacy tools. Prioritizing means routing the right people to the right problem to get it solved quickly and elevating IT service visibility, health and risk into the business function.

Let’s Get Digital

IT pros can start to tackle these challenges through prioritization and then automation, or AIOps—the principal of AIOps being to add context to data, using machine processes to enrich the data and bring it to a business level. Understand what is important to the organization and think about the outcomes important to IT. To do this, you can create a realization plan to tackle the low-hanging fruit and create achievable milestones and outcomes. For example, look for opportunities and create a crawl-walk-run phased approach driven by business priorities. Each organization has different needs and different timelines—and this process can be applied to customers, too.

Next, take into account how your team does work and focus on automation as a principle within how you do work. One of the biggest impediments to digital transformation is culture. Remove manual processes, capture tribal knowledge and figure out how to repeat this approach in a consistent way. Additionally, absorb feedback and learn from it. This will drive acceleration when done right, and we all know that better digital experiences boost enterprise value.

Finally, automation is useless if your data is flawed, and accuracy is a key fault for legacy configuration management database systems. Data must be accurate for effective machine-enabled automation. Leverage the tech you have to build an interconnected ecosystem that is fully integrated and automated—and that avoids tool sprawl. Have an open mind to consider new approaches and be brave enough to shed the legacy mindset. Additionally, take into consideration your partners and vendors, and how that team collaborates, to determine your strategy.

The Light at the End of the Tunnel

The path for today’s CIO can be unclear. But you can take bite- (or “byte-”) sized steps to put machines to work and leverage processes that deliver on AIOps. By understanding business outcomes, prioritizing automation as a principle and leveraging trustworthy internal and external relationships, you will have more time in the day for more important tasks. I measure outcomes based on customer experiences, and I ensure great customer experiences by running a great system. While your mileage may vary, moving forward is the most important part.

— Erik Rudin

January 13, 2020
Untapping the Potential of DevOps, Part 3: Keys to Success

Over the course of this series, we’ve talked about some of the common mistakes we have seen organizations make as they either launch or continue their journey into the world of DevOps. But just as it is important to understand the pitfalls that may happen during a DevOps transformation, it is perhaps even more important to know what the key indicators are that drive success. With that in mind, here are a few tried-and-true tactics for making the most out of your DevOps initiatives.

Start With Automation

One of the most powerful areas of impact for DevOps is in driving automation. It accomplishes several things: it increases the velocity of the development pipeline, it can reduce the number of errors or potential errors in code and it often frees up time for developers, allowing them to focus more on creating value and less on repeatable and mundane tasks. By ensuring that DevOps automation goals, including CI/CD, test automation, monitoring, Infrastructure as Code and GitOps are included at the outset of projects, you can better set up your organization for successful software development and delivery—both in the short term and for the long haul.

Strong Communication

When it’s all boiled down, DevOps is like any other advanced business tactic as it relies on strong communication to deliver the most success. As the name implies, DevOps engineers must bridge the worlds of development and operations, so to be truly effective they need to possess fluency in both worlds. Can you have success if you have engineers who are only strong on one side of the equation? Technically, yes. But you will not maximize the amount of value from your DevOps initiatives without stakeholders who can adeptly manage both sides. Additionally, communication with the business and other non-technical sides of the organization is critical. The entire organization should be on board with DevOps, with clear visibility into the transformation—your successes and challenges will come from frequent, effective communication.

Adhere to Processes

DevOps is process-driven, particularly as organizations scale. To work effectively, and to serve real enterprise environments, creating and adhering to processes is key. While automation is important for the rapid delivery of value, effective change management is important for sustainable development and system operations. Process and compliance are an important part of sustainability for large environments. It is also extremely important for organizations where compliance is vital—think industries such as finance, medical and government. By implementing and adhering to well-defined processes, you can avoid future headaches or rework that will slow down the pipeline.

Leadership Buy-in

The most impactful changes have one thing in common: strong leadership. Leadership dedicated to delivering customer value and understanding the software’s prominent role in delivering that value is key. Organizations that cling to outdated methods of development and delivery (i.e. waterfall) lead to slower delivery of value, which is the ticket to extinction. DevOps also benefits greatly from having leaders within the organization who serve as champions for change. By keeping a finger on the pulse of your organization from within, you can better practice change management, identify potential weaknesses earlier on and make your DevOps initiatives work for you.

DevOps can be an extremely effective way to deliver the most customer value from your software pipeline. By keeping these four key indicators in mind, you can better position your team for success and enjoy the benefits of your DevOps journey.

— Jonathan Fries

December 13, 2019
Testing Emerges as DevOps Hurdle in Mainframe Shops

A survey of 400 senior IT leaders responsible for application development using mainframes finds 90% believe automating more test cases could be the most important factor in their success, as the pressure to accelerate innovation increases. However, the same survey finds only 7% of organizations automate the execution of test cases involving mainframe code today.

The survey, which was conducted by Vanson Bourne on behalf of Compuware, also finds the time required to conduct thorough testing is the biggest barrier to integrating the mainframe into agile and DevOps processes for just over the half the survey respondents (53%), followed by a lack of skills (39%) and lack of understanding how code changes will impact distributed applications (34%).

A total of 82% said that unless they can automate more test cases, they will not be able to meet the need for speed the business now requires. That may account, in part, for why 56% of respondents said they plan to start automating the execution of test cases on mainframe code within the coming year.

The biggest benefits expected to be derived from those investments include greater efficiency within the IT team (59%), improved consistency of testing (53% ), reduced chance of human error (47%), reduced pressure on IT teams (47%), accelerated innovation cycles (46%) and less chance of bugs making it into production (40%).

Primary areas of focus for automated testing are ranked as functional testing (63%), followed by integration testing (53%) and unit testing (37%).

The survey also finds development teams are spending, on average, more than half their time (51%) on testing during the release of a new mainframe application, feature or function. That compares to 39% of their time testing applications, features or functions on applications that don’t run on mainframes.

A full 92% said mainframe teams are spending more time testing code than they needed to in the past because of the growing complexity of cross-platform application environments. Issues organizations are contending with are “Manual and time-consuming test processes” (44%), “Mainframe testing processes require specialists that are not always readily available” (40%), “Testing processes are costly” (39%) and “It’s hard to visualize and understand dependencies” (35%).

Not surprisingly, 77% of respondents find it increasingly difficult to simultaneously increase quality, velocity and efficiency to meet business innovation goals when developing and testing mainframe application code. Top concerns when it comes to mainframe development are introduction of security flaws (50%), impact on customer experience (38%) and disruption to operations (36%).

A full 85% said it is becoming more difficult to deliver innovative and faster applications without compromising quality or increasing the risk of bugs finding their way into production.

Steen Brahe, product manager at Compuware, said organizations that have mainframes are usually under pressure to innovate faster now because competition from startups relying on DevOps processes and modern platforms has increased sharply. Rather than incurring the cost of replacing mainframe applications on which the business currently depends, organizations that have mainframes are looking to extend DevOps processes to integrate emerging and legacy applications.

It’s not clear to what degree those organizations will succeed. However, the one thing that is clear is organizations with mainframes that fail to embrace best DevOps processes are already most certainly doomed.

— Mike Vizard

December 11, 2019