Author: Mike Vizard

  • ACCELQ Further Automates Testing of Low-Code, No-Code Apps

    ACCELQ Further Automates Testing of Low-Code, No-Code Apps

    ACCELQ today unveiled the cloud-based ACCELQ Live test automation platform that is continuously integrated with a wide range of low-code and no-code application development and deployment platforms.

    ACCELQ CEO Mahendra Alladi said the goal is to make it simpler to run complex tests across a multi-cloud computing environment.

    Usage of low-code and no-code tools has greatly expanded since the start of the COVID-19 pandemic. Many organizations are now relying on these tools to accelerate a wide range of digital business transformation initiatives. The challenge they encounter is that many of these processes depend on multiple applications that have lots of interdependencies across which it is difficult to conduct tests, noted Alladi.

    The ACCELQ Live platform reduces testing complexity by automatically updating itself as, for example, Salesforce or ServiceNow platforms are updated. It also provides access to pre-built codeless automation assets modeled on business processes via a live link. The company is also moving toward creating a marketplace where software vendors and service providers can build and deploy pre-built testing assets, as well.

    Gartner predicts the adoption of low-code and no-code technologies will nearly triple by 2025. Testing those applications creates a major challenge as the pace of application development increases. The only way organizations will be able to keep pace is by embracing test automation platforms infused with artificial intelligence (AI) capabilities, said Alladi. In effect, ACCELQ’s ACCELQ Live represents an effort to democratize the testing of cloud and enterprise apps, he added.

    As organizations increasingly appreciate their dependence on software, the way tests are being conducted is rapidly evolving. In addition to dedicated testing teams, developers and application owners are becoming more involved as responsibility for testing applications continues to shift further left. The challenge organizations face is the volume of applications that are simultaneously being constructed has significantly increased. Platforms that automate many lower-level testing functions are gaining traction as a means to enable humans to focus more of their time and energy on testing more complex functionality. The goal now should be to first rely on test automation platforms as much as possible and then employ humans to fill in the gaps as necessary, said Alladi.

    It may be a while before most organizations achieve that level of test automation. However, with each passing day, it’s apparent that AI will play a larger role in application testing. The issue that many DevOps teams are now working through is how to incorporate test automation platforms within the context of a larger workflow.

    In the meantime, the rate at which application testers become burned out should decline as more routine errors are uncovered by machines. It’s not likely AI will eliminate the need for dedicated testing teams any time soon, but as more rote tasks become automated there is going to be more time to focus on enhancing overall quality at a time when application environments have not only become much more distributed but also a lot more complex.

  • Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Legit Security today revealed that it discovered a privilege escalation vulnerability in GitHub repositories that has since been remediated.

    Liav Caspi, Legit Security CTO, said the company worked with GitHub to remediate the issue prior to disclosure. Legit Security researchers reported they found hundreds of GitHub instances rated with over 1,000 stars each that could be subject to the vulnerability.

    Caspi said the company also reached out directly to most of those affected sites, including an instance of GitHub that is used to develop the open source Nginx web server that is employed across hundreds of millions of websites.

    Cybercriminals could exploit a vulnerable build script to modify code or built artifacts that would result in software being shipped with code controlled by some other entity. The vulnerability could also enable access to sensitive secrets, such as keys, that are used to access cloud services or simply create a malicious pull request.

    Legit Security researchers employed a set of risk assessment tools that are part of a larger software-as-a-service (SaaS) platform that enables them to apply security policies across their entire software development life cycle. Earlier this year, the company made available a free Rapid Risk Assessment tool to provide organizations with more insights into their software supply chains. Security research findings, along with other security best practices, are embedded within the policies that can be enforced via the Legit Security platform.

    In the wake of a series of high-profile breaches, there is now more focus on the security of software supply chains than ever. Gartner estimated that 45% of organizations worldwide will have experienced attacks on their software supply chains by 2025, a threefold increase from 2021.

    Despite those concerns, however, the rate at which new applications are being deployed and updated doesn’t appear to be slowing. Organizations are too dependent on software to encourage customers to slow down the development and deployment rate of applications. It will, however, take years for organizations to properly train developers to correctly employ security tools within their application development processes, otherwise known as DevSecOps best practices, to reduce the number of vulnerabilities that now routinely manifest themselves in production environments. The only practical alternative is to embed more tools that automatically discover vulnerabilities in code during the application development process.

    Regardless of the DevSecOps approach, the ultimate goal remains to build more secure applications faster. That can only be achieved if there are more guardrails in place that prevent developers from inadvertently introducing vulnerabilities into an application. The more frequently applications are updated, the more likely it is that a vulnerability will be introduced. Each time those vulnerabilities are discovered after an application is deployed in a production environment, the more expensive they are to remediate. As the volume of vulnerabilities increases, it’s also only a matter of time before the sheer number of security issues that need to be addressed overwhelms both developers and security operations teams alike.

    Application security, of course, has not always received the attention it deserves, but demands for increased application security can no longer be ignored.

  • WhiteSource Offers Free Spring4Shell Vulnerability Tool

    WhiteSource Offers Free Spring4Shell Vulnerability Tool

    WhiteSource has launched a free command-line interface (CLI) tool that detects vulnerable open source Spring4Shell vulnerabilities (CVE-2022-22965) that are impacting Java applications built using the Spring development framework.

    Susan St. Clair, director of product management for WhiteSource, said the WhiteSource Spring4Shell Detect tool is similar to the tool the company made available earlier this year to detect Log4Shell vulnerabilities in Java applications. It provides an exact path to direct and indirect dependencies along with how to find a fixed version of the Spring framework to accelerate remediation efforts.

    Spring4Shell is yet another zero-day vulnerability that has been given a 9.8 severity score. As a result, DevOps and cybersecurity teams are now racing to update applications impacted by this vulnerability before cybercriminals can exploit it. The Spring4Shell vulnerability enables remote code execution (RCE), and the Java applications impacted employ versions 5.3.17 or 5.2.19 of the Spring framework and version 9 or higher of the Java Development Kit (JDK).

    The vulnerability allows an attacker to remotely execute arbitrary code on the target server. It allows attackers to abuse a RequestMapping annotation that maps incoming HTTP requests into their appropriate handler functions. The vulnerable condition occurs when RequestMapping is used in conjunction with traditional Java objects as the handler parameter. Such an attack might allow access to all website internal data, including any database. It might also allow access to additional internal resources to gain more permissions or to pivot to other parts of the internal network.

    It’s not clear how pervasively Spring4Shell might impact Java applications compared to Log4Shell vulnerability that affected a logging tool, but more security researchers are looking for RCE vulnerabilities within Java application environments. Organizations now will need to determine whether to maintain legacy applications that might be subject to more zero-day vulnerability discoveries or replace them with newer applications that are developed in a programming language that might be more secure. There is, of course, no guarantee a new application will be more secure than a legacy application, but the chances are good a modern application will have fewer vulnerabilities than a legacy application simply because the underlying programming tools and platforms are more advanced from a security perspective.

    In the meantime, DevOps teams likely will be looking for instances of Spring4Shell vulnerabilities for months to come. DevOps teams that have access to a software bill of materials (SBOM) naturally will be able to find those instances more easily than organizations that don’t. However, the percentage of organizations that have SBOMs is still comparatively low. However, as zero-day vulnerabilities become a larger security issue, SBOMs are being implemented more widely as organizations review their software supply chains.

    Whatever the path toward ensuring application security ends up being the level of scrutiny being applied to application development and deployment, processes will in the months ahead accelerate the adoption of best DevSecOps practices across organizations large and small, whether they like it or not.

  • GitLab Updates CI/CD Platform to Improve Dev Productivity

    GitLab Updates CI/CD Platform to Improve Dev Productivity

    GitLab has made available a 14.9 update to its namesake continuous integration/continuous delivery (CI/CD) platform that adds epic-linking, integrated security training, rule mode for scanning result policies and a revamped design, among other capabilities. The updated environment makes it easier to discover the state of the application development projects, GitLab said.

    Cindy Blake, director of product marketing at GitLab, said these updates are part of an ongoing effort to embed technologies within the CI/CD platform that will make applications both more secure and compliant with various mandates before they are deployed in a production environment.

    For example, DevOps teams can now take advantage of a user interface through which they can use a rule mode to design and edit policies without the need to access YAML files directly.

    GitLab has also partnered with Kontra and Secure Code Warrior to provide content that will drive security training functionality. This content can be accessed via the GitLab platform whenever a vulnerability is discovered.

    The overall goal is to make it simpler for organizations to shift left because expecting every developer to become a security expert is not especially realistic, noted Blake. The ability to automate many of the security tasks that developers face is a way of showing empathy for the daunting challenges they face.

    In general, as application development becomes more complex, GitLab is moving toward making its CI/CD platform more accessible to a wider range of organizations, including those that might only be starting to embrace DevOps best practices. The epic-linking capability, for example, makes it easier to identify “related”, “blocking,” or “blocked” relationships to better track and manage epic dependencies across GitLab groups.

    The two biggest challenges organizations face today are securing their software supply chains and improving the overall productivity of the developers. In most cases, those two goals are tightly coupled; every minute a developer spends on security is one less minute they spend writing code. In fact, many organizations are finding that, in addition to salary and benefits, many developers are using the level of friction they will encounter when building and deploying applications as a guide to decide which organizations they want to work for. As a result, many organizations are now looking to modernize their application development and deployment environments with an eye toward attracting the best developer talent.

    At the same time, of course, organizations are looking to improve the productivity of the developers they do have. In the age of digital business transformation, there are many more application development initiatives being launched. The challenge organizations face is that hiring and retaining developers remains a major challenge.

    It’s not clear how eager organizations are to replace their existing CI/CD platforms. However, the pressure to improve the overall developer experience is mounting at a time when organizations are increasingly dependent on software. Arguably, going forward, the ability of any organization to compete will be dependent on the productivity of application development teams. Platforms and tools that get in the way of enabling organizations to build and deploy more secure software faster will be discarded.

  • GitLab Allies With Rezilion to Add Workload Analysis Tool

    GitLab Allies With Rezilion to Add Workload Analysis Tool

    Rezilion has integrated its workload analysis tool with the continuous integration (CI) framework provided by GitLab. The move is part of an effort to make it simpler for developers to discover issues such as vulnerabilities before they upload code into a repository.

    Sam White, a senior product manager for GitLab, said this integration will provide developers with an instant feedback loop that will enable them to address a wide range of issues before their code is ever reviewed. Rather than experiencing the shame of, for example, missing a vulnerability, the Rezilion platform enables developers to quickly write code while relying on a code analytics tool to surface common mistakes that they can remediate as they see fit, he added.

    Rezilion CEO Liran Tancman added that the proprietary workload composition analysis engine, dubbed Unison, on which the Rezilion platform is based makes it feasible to shift more responsibility for application security further left without requiring developers to become cybersecurity experts.

    Unison automatically creates a model of all the applications that include the underlying infrastructure and runtime environments. It reverse-engineers and maps that environment in memory to dynamically track the inventory, provenance, runtime execution, exposure and interdependencies between each piece of code and can generate a software bill of materials (SBOM).

    The code that is most in need of immediate attention is also surfaced directly with the GitLab user interface, said Tancman. That capability can reduce remediation time of the vulnerability backlog an organization might be working through by as much as 70% over time, he added. Rezilion enables organizations to achieve that goal because non-exploitable vulnerabilities are marked as “false positives” that shouldn’t hold back a release.

    Tancman said that without this level of automation it would be extremely challenging for an organization to implement a set of DevSecOps best practices. It might take developers years to attain the level of cybersecurity training that would be required in the absence of the automation enabled by the Unison engine, he noted.

    Historically, the relationship between application developers and cybersecurity teams has been tense. Cybersecurity teams tend to put off code review until it’s about to be deployed in a production environment. It’s not uncommon for an application to be pulled at the last minute because of a vulnerability discovered by a cybersecurity team. In some instances, that vulnerability is a legitimate concern but in others, it turns out to be a false positive because the flagged piece of code isn’t actually included in the application.

    By providing developers with a workload composition analysis tool within the context of a CI framework, GitLab is trying to reduce the level of friction that the process tends to create between developers and cybersecurity teams.

    It may be some time before most organizations fully master DevSecOps, but it’s clear that merely telling developers they will be held accountable for application security without providing the appropriate tools isn’t going to make applications any more secure.

  • Rocket Software Extends DevOps Reach to IBM I Platforms

    Rocket Software Extends DevOps Reach to IBM I Platforms

    Rocket Software has added support for the IBM I platform as part of its relaunch of a DevOps platform that also runs on IBM mainframes.

    Chris Wey, president of the data modernization business unit at Rocket Software, said the Rocket DevOps continuous integration/continuous delivery (CI/CD) platform will make it possible for organizations that employ both IBM I midrange platforms and mainframes to modernize application development and deployment using a common framework.

    Modernization of application development on mainframes has been occurring for some time. A survey of more than 500 U.S. IT professionals conducted by Rocket Software found 44% of respondents employ multiple DevOps tools, but slightly less than a quarter (24%) have a comprehensive DevOps platform in place.

    Rocket Software is expanding its DevOps reach to include the IBM I platform because organizations that rely on this platform have the same pressing need as other organizations to more quickly build applications, said Wey.

    It’s not clear to what degree organizations are still building new applications for what have become venerable IBM platforms. A Rocket Software survey found that while 82% of respondents are migrating workloads to the cloud, only 4% reported they are migrating completely to the cloud. The bulk of most mission-critical applications running on mainframes are online transaction processing (OLTP) applications that require a level of processing capability that still can’t be easily matched using any other platform. There are plenty of instances where certain classes of workloads have been migrated off the mainframe to run on lower-cost platforms. However, there are still many enterprise applications that continue to run faster on mainframes than they could on any other platform.

    In most cases, Wey noted, organizations will be deploying and updating applications across hybrid cloud computing environments for years to come. The immediate challenge they face is a lack of DevOps skills among the IT teams that manage IBM I systems and mainframes, he added.

    Rocket Software also provides access to a set of application development tools for building modern applications on IBM platforms. Most recently, the company added support for an open source Python software development (SDK) that IBM created for the Python programming language to the Rocket Open AppDev for Z framework for building mainframe applications.

    The overarching goal is to make IBM platforms more accessible to a wider range of application developers and DevOps professionals that today mainly work on distributed computing platforms, noted Wey.

    One way or another, the divide that has existed between legacy platforms and distributed computing systems is continuing to narrow. Many organizations are trying to lower the total cost of IT by centralizing management of both these classes of systems versus continuing to hire and retain separate IT teams.

    The IBM I platform traces its lineage back to AS/400 systems that were first launched in 1988 as an integrated midrange minicomputer rival to VAX/VMS systems from Digital Equipment Corporation (DEC). Fast-forward more than 30 years later and there still are many IBM I platforms running long after VAX/VMS systems have all but disappeared.

  • Harness Acquires ChaosNative to Meld Chaos Engineering, DevOps

    Harness Acquires ChaosNative to Meld Chaos Engineering, DevOps

    Harness this week announced it acquired ChaosNative as part of a plan to more deeply integrate chaos engineering with DevOps workflows.

    At the same time, the company added a Harness Service Reliability Management (SRM) and Harness Security Testing Orchestration capability to its continuous integration/continuous delivery (CI/CD) platform.

    Chaos engineering, as a discipline, refers to experiments on a software system that test its resiliency in the face of an unplanned outage. The goal is to deliberately make resources unavailable to see how the application environment either adjusts or whether it fails.

    ChaosNative’s LitmusChaos platform, which manages these chaos engineering tasks, was donated to the Cloud Native Computing Foundation earlier this year.

    Scott Sanchez, chief marketing officer for Harness. said the company plans to shift chaos engineering further left as part of an effort to enable developers to test the resiliency of their applications before they are deployed in a production environment.

    It’s still early days where adoption of chaos engineering within DevOps workflows is concerned. Many IT leaders’ performance is measured based on the stability of application environments. The idea that they should deliberately break something as part of an effort to make an application more resilient requires a shift in mindset, noted Sanchez.

    However, once IT leaders start to appreciate how chaos engineering actually improves the availability of applications it’s only a matter of time before the practice becomes more widely implemented, he added.

    In the meantime, Harness is looking to automate more of the lower-level tasks that today’s DevOps teams often manually manage. Harness SRM enables DevOps teams to automatically track service level objectives (SLOs) that are attached to specific pipelines within the Harness CI/CD platform.

    The Harness STO module, meanwhile, makes it simpler to orchestrate security testing across multiple pipelines.

    In general, there is now more focus on the productivity of DevOps teams as the number of applications that are being built simultaneously increases. The challenge, however, is not just the number of applications but also the dependencies that exist between them.

    Harness is making a case for a CI/CD platform that automates DevOps tasks by employing, for example, machine learning algorithms to identify which applications are most likely to fail before a build is completed. The goal is to reduce the amount of time DevOps teams waste waiting for builds to complete only to discover that the application almost immediately failed.

    The time, effort and cost of maintaining a DevOps platform will naturally vary as the overall environment becomes more complex. However, as DevOps processes become more automated, the platforms themselves become more accessible to a wider range of organizations. Today, the effort required by a DevOps to set up and then support a CI/CD environment is often considerable.

    Nevertheless, as more organizations rely on custom applications to drive digital business processes, it’s only a question of when and to what degree DevOps best practices will be more widely adopted. After all, the total cost of application downtime is only going to rise in the age of digital transformation.

  • How Work-From-Anywhere Impacts DevOps

    How Work-From-Anywhere Impacts DevOps

    Brian Lavallée from Ciena talks with Mike Vizard about how the work-from-anywhere movement has impacted DevOps, networking and security. The video is below, followed by a transcript of the conversation.

    Mike Vizard: Hey, guys. Thanks for the throw. We’re here with Brian Lavallée who is senior director for solutions marketing at Ciena. Brian, welcome to the show.

    Brian Lavallée: Thanks. Nice to be here.

    Mike Vizard: You guys just put out this study talking about what’s happening on the technology impact from working from home. A lot of folks are accessing cloud resources. They have home networks that may or may not be up to the task. Are we looking at some sort of networking crisis coming up as we move to working from anywhere? Do people understand that bandwidth is going to be an issue?

    Brian Lavallée: I wouldn’t say it’s a crisis, but it is a work in progress. Just over the last year, year and a half, the global pandemic, our homes have turned into the new branch office, the new classroom. People are learning, playing, and working from home, and it’s put additional stress on the network. One of the main challenges is speeds, because now you have two, three, four people accessing the same broadband connection from home at the same time, and then you have the whole security aspect, where if your home is the new branch office, very often you need additional security to do work, not only with your head office, your colleagues, but also with your cloud applications.

    Mike Vizard: I have found myself trying to fight for bandwidth with an 11-year-old, so I know what the issues are and what the problems can be. Do you think companies, as we go forward, are going to turn around and say to their employees, “Here is the router we want you to use”? Are they going to give them that router, or the access point at home? How far will they go to make all this happen and maybe provide that additional layer of security?

    Brian Lavallée: Yeah, I think, for sure, adding additional security, even availability, a more resilient connection is necessary going forward. Companies or enterprises are going to implement this differently. Some may do a lot of their security capabilities in the cloud. This allows you to have a centralized location to do all your security, you know, talking about SASE, _____ connectivity, and because it’s centralized, it’s easier to implement and control, rather than having specialized devices or specialized software sitting on everybody’s laptop. If you’re a large enterprise, you can have thousands to many thousands of people working from home, so centralizing your security aspect with a high-speed connection is probably the way moving forward.

    Mike Vizard: What impact does that have back on the core networks? I mean, if everybody has suddenly got more bandwidth at the edge, does that have a cascading effect up through the rest of the network infrastructure? Do I need additional core routers or networks? How will this play out in your mind?

    Brian Lavallée: Yeah, _____. Content is created and consumed at the edge, and that’s from humans or machines ‒ think sensors, cameras, and so on. Definitely, as we open up the access ramps, 5G is a way of opening up the wireless access ramp, plus you have a variety of wireline broadband technologies for the home, even the offices. For sure, it has a knock-on effect into the core network because, if you think about it, most of the content and applications that you access, whether it’s on your smart phone, your laptop, tablet, or whatever device you’re using, it’s sitting on a datacenter somewhere. That could be a datacenter close to you, an edge datacenter maybe sitting in the same city as you. It could be a datacenter on the other side of the world sitting in Norway or Sweden or Finland.

    Mike Vizard: I’m feeling like a lot of the applications that people are starting to build, consume data and analyze data at the point at where it’s created more, it’s more happening out at the edge. Is there a lot more sensitivity around latency? Will the laws of networking physics come back and bite us soon, and are we seeing new classes of applications?

    Brian Lavallée: Yeah, and that’s a good question because it leans into the topic of discussion, one of the hotter ones today, which is edge computing or edge cloud. By putting storage and compute access closer to the end-users ‒ again, those end-users could be humans or machines ‒ it does inherently reduce the latency only because you have a shorter physical distance to travel. But, we have to remember latency is not just about distance, it’s about the amount of network nodes that are sitting between you and your content, so the more network devices you go through ‒ switches, routers, and so on ‒ the more latency is incurred and accumulated. Pushing the storage and compute closer to the edge with high-speed connections is a very good way of reducing latency, and it also opens up a whole bunch of new applications where latency is a critical factor beyond just increased speed.

    Mike Vizard: I feel like right after the pandemic, we sent everybody home, we gave them their little wireless network, we hooked them up with a VPN, and they accessed the applications in the office. Then, they went out to the cloud and they had this kind of backhauling effect of the network traffic flow. You mentioned SASE. Are we going to change the way we think about how applications are deployed and how we access them, whether they’re up in the cloud? Is the routing concept that we’ve known all these years changing? How do you think we’re going to go forward from here?

    Brian Lavallée: Yeah, so I think the increased adoption of cloud-based services is an unstoppable juggernaut. It is happening. There are security concerns. Our survey that we did, the study, we did show that there was a security concern of moving more and more into the cloud, but the cloud providers, the telecom operators, they’ve done a lot of excellent work over the last few years to address security, make increased security for their end-users. The cloud-based service providers, they realize that security is top of mind above everything else, so I think that will continue going forward. As more and more end-users are accessing cloud-based applications and content, the network becomes a critical factor because the network now is sitting in between you and the content you’re trying to access.

    Mike Vizard: Do you think the bad guys have figured all this out and they’re targeting people at the end point now and looking at these slightly misconfigured networks? Sometimes we’re using fraud RDP protocols. Are they getting it? Are they after us?

    Brian Lavallée: They’ll always be there, nefarious actors, bad actors, whatever you want to call them, so they will always be there, but the cloud providers, the telecom operators, they know this, so they are consistently upgrading, modernizing, and putting increased security capabilities into their network. It’s always going to be a battle of people who want to do not so good things with the network and content, and the people that actually run those datacenters and networks. I think that will continue going forward, it’s kind of human nature, but we’ve made great strides as an industry, and that’s across IT, telecom, and cloud-based services in terms of security. With more and more people from home, I mean right now we’re living in probably the largest working-from-home experiment of our species, and, if you think about it, the network, it has bent in a few places, right?

    Most of the networks are running hotter, but it hasn’t broken. The Internet has not broken. A lot of people early on thought that if everybody moves home, it’s not that you have more capacity coming to the home, but the traffic patterns have changed. During the day, when a lot of people went to school and work, the traffic was to the schools and the head offices, but now the whole traffic pattern has moved into the home. Although a lot of people were concerned, I think the telecom operators deserve a lot of credit. The network has bent in a few places, but it hasn’t broken, and they’ve just learned a lot over the last year, and the networks will just be that much more reliable going forward.

    Mike Vizard: Prior to the pandemic, the carriers were trying to encourage people to offload from the network and use WiFi. Now we have 5G, and people are talking about 6G and who knows what comes after that. Are we getting to a point where we can just run 5G into the home? Will that get cost-effective at some point and we won’t have all these WiFi routers, or will it always be some sort of a balance between 5G, 6G and WiFi and we have to figure it out?

    Brian Lavallée: Yeah, I mean my personal opinion on that, I think it will always be a mix of technologies. I’ve been in this industry long enough to know that a technology network completely disappears, at least not in my career. It always has places of use. The big difference with 5G over 4G LTE and previous technologies, and even WiFi, previous generations of mobile technologies, it brings a lot of new benefits to the table, right? If we look at the faster speeds, this is what gets the most press coverage because that’s what people will see right away, but it also brings much lower latency. We’re talking order of magnitudes lower latency. It connects to a wider variety of connected devices, such as sensors and smart devices, and then we have this whole concept of network slicing, which can guarantee end-to-end performance.

    You can guarantee the speed, latency, and resilience. We haven’t had that in the past with any mobile network generation, and, to a large extent, we haven’t even had that on the wireline technologies. So, 5G coming right into your home, if you think about it, if you’re a network operator, it’s much easier just to send a 5G hotspot, it could be a router, residential gateway to somebody’s home, they turn it on, they plug it in the wall, and it discovers the mobile network and then BOOM, you’ve got one-gigabit-per-second capacity right to your home. That is, I think, the way of the future in many cases, but there are some technical challenges that still need to be overcome. But, most operators are looking at 5G fixed wireless access to the residential, but even businesses as something in their toolkit going forward to compete with wireline technologies.

    Mike Vizard: Do you think there is a rebellion coming among the end-users who are using this stuff? When you hear them, they’re kind of complaining a lot about the experience, so do you think that at some point they’re going to start picking what companies they want to work for based on what kind of work-from-home, work-from-anywhere experience they can get? Will that factor into hiring and retention more than it has in the past?

    Brian Lavallée: Yeah. I mean, the network is critical infrastructure today, especially for the younger generation who were born and raised on having always-on connectivity. I think that will continue going forward. But, as more people work from home, I know we hear a lot of talk about the new normal, what ire the workplace, for instance, or the school systems going to look like after the pandemic subsides? We don’t really know. But, what I think we do know is more people will be working from home. I see it in my personal life, I see it with my colleagues, I see it with friends and family. Their companies are looking at implementing working from home at least a couple of days a week. There are a lot of benefits to the company to do this, as well, so the network will become that much more important.

    I think people will shop around if the provider they have, the network provider, is not giving them the performance that they need, and it will become a highly competitive marketplace. I mean, it is pretty competitive now, but I think it will be that much more so going forward in terms of speed, latency, and availability, the three main things that you need with a high-speed connection to your home.

    Mike Vizard: I might even one day factor networking costs into my compensation packet, but we’ll see what happens.

    Brian Lavallée: There you go.

    Mike Vizard: What is your best advice to people who are on the IT side of this equation, they’re the network managers, they’re security people. What is the conversation that they should be having higher up the food chain to the board of directors about what needs to happen to really enable this next wave of work?

    Brian Lavallée: Yeah, I mean, the higher speed to the home is something that a lot of people talk about. We just talked about it earlier, more people working, playing, and learning from home, so capacity will always be at the forefront of discussions and having competitiveness for an operator with another operator. But, I think increased security features, this could be wrapped around a broadband connection to your home, so rather than just buying a high-speed pipe to your service provider, they would also provide you with SASE type of capabilities, so security, firewalls, and so on. I think looking at bundling, IT services with the connection is definitely the way to go. It is a differentiator, and it is what people will be looking for because if you’re the average home user, whether it’s for playing, learning, or working, you really don’t care what technology you’re buying, as long as it’s cost-effective and it meets your needs.

    I think my advice for the operators is to look at what is available recently, some of the newer technologies ‒ virtualization and SASE technologies and the SD _____, a whole bunch of other technologies ‒ and start to wrap these into a bundle that you solve most, if not all of the needs of the subscriber, and then you could differentiate far above and beyond just a higher speed.

    Mike Vizard: All right, guys, you heard it here. Faster things that are insecure do not necessarily represent progress. Hey, Brian, thanks for being on the show.

    Brian Lavallée: Happy to be here. Thank you.

    Mike Vizard: All right, guys, back to you in the studio.

    [End of Audio]

     

  • Survey Sees App Testing More Widely Distributed

    Survey Sees App Testing More Widely Distributed

    A survey of 900 application testing professionals conducted by PractiTest, a provider of a platform for managing testing tools, suggested the number of organizations that have dedicated testing teams is declining at a steady rate.

    The survey found a 15% decrease in organizations with dedicated testing teams that have six or more members. At the same time, however, the survey found only 18% of respondents reported that all testing is done by individuals that are not part of a dedicated testing team.

    Joel Montvelisky, test specialist and chief solution architect at PractiTest, said that shift indicates that more organizations are steadily incorporating testing within DevOps workflows. In fact, more than 60% of respondents said DevOps and Agile processes led to teams being more organized and stable, with two-thirds (66%) reporting that development teams were releasing features more frequently with more functionality.

    However, only 38% of respondents said they were active participants in a continuous integration/continuous delivery (CI/CD) workflow. A full 90% said they needed to coach or train other members within the team and just over half (54%) reported that estimations of the time required for development and testing were accurate.

    Two-thirds also said collaboration with developers is also improved when applying DevOps processes, with more than half reporting fewer serious bugs made it into production. More than half also said they monitor software in production and deployment environments. The number of testers who defined themselves as engineers has gone up by 14% year-over-year. However, only 44% report that automation has replaced 50% or more of their manual testing efforts.

    A full 95% or more of survey respondents identified application programming interface (API) testing, Agile methodologies, functional testing and scripting as high on their list of priorities. In contrast, big data testing, internet of things (IoT) testing and machine learning/artificial intelligence (AI) testing were cited as important or very important by only 60% of respondents.
    Finally, about a third of survey respondents noted that non-testers are now involved in testing activities.

    Montvelisky said the PractiTest survey makes it clear that while developers are a little more involved in testing than they were a few years ago, organizations still relied on testing specialists that are becoming more integrated into DevOps workflows. This is especially important as more organizations launch digital business transformation initiatives that require them to build software using the same types of DevOps processes that independent software vendors (ISVs) employ.

    It’s still too early to say just how far testing might shift left toward developers, but as testing becomes more automated—thanks, in part, to increased reliance on AI—the types of tests that will be conducted by a dedicated testing team will evolve. In fact, it’s unlikely automation will eliminate the need for those teams any time soon. Rather, testers will be augmented by AI technologies that will help them to keep pace with the accelerated rate of application development enabled by wider adoption of DevOps best practices within organizations both large and small.

  • Log Management Challenges Grow With Observability Adoption

    Log Management Challenges Grow With Observability Adoption

    It appears that, in many IT environments, observability is becoming too much of a good thing. A global survey of more than 315 IT executives, cloud application architects, DevOps professionals and site reliability engineers (SRE) conducted by Dimensional Research on behalf of log data management platform provider Era Software, found 96% are witnessing an explosion of log data.

    The survey also found 79% of respondents reported the overall cost of observability and log management will skyrocket in 2022 if current tools don’t evolve.

    More than three-quarters of respondents (78%) also noted attempts to manage volumes of log data have had mixed or unwanted results such as an inability to access data. Nearly two-thirds (65%) are also evaluating their observability options while the other 41% are considering it.

    Stela Udovicic, senior vice president of marketing for Era Software, said the survey makes it clear that as organizations rely more on logs to analyze IT events, the cost of storing all that log data is becoming a significant challenge. Overall, the survey finds usage of observability tools and platforms has jumped by 180% as IT teams struggle to manage increasingly complex IT environments.

    On the plus side, more business users are benefiting from log data. A full 83% of respondents report that business stakeholders outside of IT use insights from log data, with 96% reporting log data is being used to solve business problems.

    Observability has always been a core tenet of DevOps best practices, but achieving it has always been a challenge. Monitoring tools are designed to consume predefined metrics to identify when a specific platform or application is performing within expectations. The metrics tracked generally focus on, for example, resource utilization. However, whenever there is an issue, it can still take days, sometimes weeks, to discover the root cause of an issue through what amounts to a process of elimination.

    In contrast, observability combines metrics, logs and traces—a specialized form of logging—to instrument applications in a way that makes it simpler to troubleshot issues without relying solely on a limited set of metrics that have been predefined to monitor a specific process or function. DevOps teams can employ queries to interrogate data in a way that makes it easier to discover the root cause of an issue. Observability platforms correlate events in a way that makes it easier for analytics tools to identify anomalous behavior indicative of an IT issue.

    The issue that arises is that IT teams need to find a way to store all the data generated by the logs they need to analyze. Each IT team can, of course, could reduce the amount of log data they retain. However, there is always a concern that in the event of an incident critical log data won’t be available.

    Udovicic said most IT organizations have historically viewed storing log data as a necessary evil. The primary issue most of them encounter is the simple fact that log data is not easy to work with, she noted.

    Regardless of how organizations view log data, the amount of it that needs to be managed will only increase as DevOps workflows become more mature. The issue IT teams need to come to terms with now is finding a way to minimize the cost of storing it all.