devopsy.kinsta.cloud

Category: Features

  • Low-Code Makes API Testing More Accessible

    Low-Code Makes API Testing More Accessible

    APIs are rising both in quantity and business value. But with that growth comes an increasing number of vulnerabilities, which could affect cloud service dependencies and internal APIs. Functionality and uptime could also suffer as cloud services evolve their APIs with new versions. Thus, API endpoint testing is critical to ensure a reliable back end. With growing interest across the organization to stabilize these integrations, how do we test APIs in a reproducible way that non-developers can grasp?

    Low-code platforms — tools that enable workflows with visual programming models — are opening doors for citizen developers to construct applications in a visual mode. Similarly, the low-code concept could aid API testing by providing an easier method to create API tests to verify functionality and uptime. This could arm quality assurance, DevOps and site reliability professionals with an easier means to test high-value integrations and their UI representations.

    Amid a growing headless movement, APIs are now powering many end-user experiences. However, during a developer drought, it may be challenging to find talent with integration know-how.

    I recently met with Dan Belcher from Mabl to discuss combining low-code and API testing. Here, we’ll uncover why it’s difficult for non-engineers to conduct API testing and consider what API testing must address to ensure today’s software meets tomorrow’s digital innovation demands.

    A Low-Code Approach to API Testing

    The software landscape has evolved rapidly in recent years. “Many forces have combined to create an incredible amount of change,” said Belcher, citing DevOps, CI/CD, the API economy and agile enterprises as examples. In this era, applications are becoming more dynamic, disrupting the way teams conduct end-to-end quality testing.

    API-based cloud services are part of this new frontier, becoming popular building blocks within modern applications. Yet, integrations require upkeep as cloud services evolve and version. Without continuous testing of API-based cloud services, organizations could easily suffer from breaking change and poor usability.

    Unfortunately, as it stands, typical QA teams aren’t well-equipped to handle ongoing regression testing for APIs. Instead, “developers, historically, have been the only ones that understood API testing,” explained Belcher. For years, API testing has been relegated to the realm of developers, who use tools like Postman to perform unit-level testing. But why is API testing so difficult for others?

    What Makes API Testing Difficult?

    Well, to start, non-engineers are typically more accustomed to UI-based testing. These environments use a structure designed for anyone to consume, making it easy to locate fields and confirm values, Belcher explained. When it comes to API testing, you often must handle massive chunks of JSON responses to match fields and surface issues. Testing API responses typically requires writing code, parsing JSON and writing it to variables, Belcher explained, which may be difficult for non-developers to implement.

    Or, difficulties could arise when testing asynchronous endpoints, Belcher added. Asynchronous APIs often involve background server processes that take a while to respond. This comes at a moment when event-driven architecture (EDA) is a growing trend. Take AsyncAPI, a standard API specification for EDA APIs, which recently joined the Linux Foundation. A recent report found AsyncAPI production usage tripled from 5% in 2019 to 19% in 2020. According to Belcher, testing such asynchronous services requires an infrastructure for continuous testing to anticipate these emerging scenarios.

    Four Crucial Areas For API Testing

    So what should API tests be focusing on? Belcher highlighted four areas that warrant close examination throughout the API testing process:

    • Functionality: This is the core functionality. Does the API do what it promises? Does it return the correct data?
    • Uptime: What is the API’s availability? Are all endpoints available in production?
    • Speed: This ensures cloud dependencies meet SLAs. What is the latency? Is there drift in API performance over time? Though API monitors like Api.expert help aggregate industry performances, they might not always reflect your specific customer-level realities. Belcher recommends not placing faith in supposed performance and instead, clocking your own.
    • End-to-End: Belcher stresses the role APIs now play across customer-facing presences. An end-to-end workflow should involve API endpoints, how they interact with one another, and the resulting visual representations. “Just like we have end-to-end testing for UIs, we should have end-to-end testing for APIs,” he said.

    API testing isn’t always combined with other parts of the user experience, but Belcher believes, going forward, end-to-end testing will be critical to ensure all workflows function in concert. For example, if a user profile is created within a browser, teams should verify the user profile has been created at an API level, as well.

    Low-Code API Testing and Shift Left

    APIs are beneficial to avoid reinventing the wheel. However, 100% operational uptime is impossible. Applications will inevitably encounter API problems, including outages, technical failures and functional misrepresentation. Developers also often come to rely upon production behaviors that may not be officially documented, an effect known as Hyrum’s Law. This can cause unstable integrations as APIs version over time.

    Thus, for these reasons and more, it’s a good practice to adopt continuous API testing. With the surging interest in site reliability engineering, spotting API errors early on will become an important aspect in reducing mean time to recovery (MTTR). Testing third-party APIs could also expose production latencies to inform cloud investments.

    “As the pace of change is going up, how do we deliver great quality to our customers?” Belcher asked. API testing is one answer to address this rapid change, and is growing in importance for the software delivery life cycle. It especially rings true for headless frontend experiences, where the API-driven backend isn’t transparent to QA testers.

    Low-code capabilities for API testing could help tear down silos inherent in the development process, enabling more people to participate in testing integrations. Belcher also stresses the importance of improving the usability of API testing for developers and non-developers alike. “We need to integrate with tools developers are already using for verification,” he added.

  • AlmaLinux Foundation Delivers on CentOS Promise

    AlmaLinux Foundation Delivers on CentOS Promise

    A nonprofit organization launched this week to oversee future development of AlmaLinux, a distribution of Linux based on code originally contributed to the open source CentOS project.

    At the same time, CloudLinux, which created AlmaLinux in response to a decision by Red Hat to pull financial support for CentOS, announced that a stable version of the operating system is now available. CentOS itself was based on the Red Hat Enterprise Linux (RHEL) distribution that is made available via a subscription.

    Jack Aboutboul, community manager of AlmaLinux, said AlmaLinux is the result of the $1 million that CloudLinux committed toward creating a distribution of Linux based on a CentOS project used by hosting providers, such as CloudLinux, to run RHEL-compatible applications at a lower cost. AlmaLinux OS is a binary compatible fork of RHEL 8, which the foundation pledged to update to maintain that compatibility.

    AlmaLinux is one of two distributions based on CentOS that have been created. The other, RockyLinux was created by Gregory Kurtzer, one of the original creators of a CentOS project. Red Hat, in the meantime, has moved to make RHEL subscriptions available for free to individual developers.

    Aboutboul said AlmaLinux is more mature than RockyLinux, because it is based on a Linux distribution that has been battle-tested by IT service providers. AlmaLinux also added a SecureBoot capability as well as support for VMware and the Amazon Web Services (AWS) public cloud, noted Aboutboul.

    The AlmaLinux Foundation also decided to publicly share errata about the ongoing development of the operating system, to make it easier for IT teams to troubleshoot issues that might arise in a production environment.

    It’s not clear yet how much support either AlmaLinux or RockyLinux have. However, at this juncture, forks are becoming fairly common across the open source community. Those disruptions, however, don’t seem to be dampening enthusiasm for open source software. A global survey of 1,250 IT leaders conducted by Red Hat finds nearly 80% of respondents expect to increase their use of emerging open source software technologies over the next two years, with the top three use cases being infrastructure modernization (64%), application development (54%) and digital transformation (53%).

    As Winston Churchill famously said, democracies are messy, and the open source community is no exception. Passions run high. At the same time, the various business models that spring up around open source projects often conflict; because of animosity, greed or differences of opinion, it is not uncommon for multiple forks of an open source project to emerge and evolve over time.

    Despite that issue, IT organizations remain committed to open source for two primary reasons. First, no one needs permission to download open source software to a laptop. That enables developers to more easily experiment with new technologies. Second, cost. Many IT organizations prefer to use free open source software, rather than paying to license commercial software. They may one day pay for support, but the number of open source software users still dwarfs the number willing to pay for support; especially since knowledge and expertise is freely and equally shared across a growing open source community.

    Given those benefits, any friction in the open source community itself is largely seen as an acceptable risk and just the potential cost of doing business.

  • 42Crunch API Security Platform Now Available On-Premises

    42Crunch API Security Platform Now Available On-Premises

    42Crunch has announced that the scanning tools it provides to enable DevOps teams to secure application programming interfaces (APIs) can now be deployed in on-premises IT deployments.

    Previously only available as a cloud service, the 42Crunch API Security Platform has also been updated to provide expanded support for the OpenAPI specification for REST interfaces defined by the OASIS standards body.

    Finally, the 42Crunch API Security platform now allows IT teams to share collections of APIs among specific teams and users with different levels of access in addition to providing integration with third-party identity management platforms.

    Dmitry Sotnikov, chief product officer for 42Crunch, said the on-premises edition of the API scanning platform will make it possible for IT organizations, including those that require all the platforms they run to be deployed in an IT environment, to exercise more control over and extend their DevSecOps workflows to include scans of APIs.

    Cybercriminals are increasingly targeting insecure APIs because they potentially provide access to a trove of data, Sotnikov noted. Those same APIs also enable cybercriminals to compromise an entire software supply chain, Sotnikov added.

    At a time when more organizations are deploying APIs, thanks to the rise of microservices, it’s apparent there is a greater need for a tool that dynamically scans APIs for vulnerabilities before they are deployed, said Sotnikov.

    In general, Sotnikov said IT organizations are becoming more sophisticated in their approach to securing software. Ford Motor Co., for example, is using the 42Crunch API Security Platform to secure both internal and external APIs, Sotnikov said. 42Crunch claims its revenues increased 900% in 2020, with more than 150,000 users of the platform.

    As organizations of all sizes become more dependent on software, cybersecurity teams are now reviewing how that software is constructed. Of course, responsibility of security is still shifting left as part of the overall transition to DevSecOps best processes, but Sotnikov said cybersecurity teams still want to verify for themselves that whatever software is deployed is secure. IT organizations are moving away from a “whack-a-mole” approach to security as they embrace DevSecOps, Sotnikov added.

    Unfortunately, APIs don’t always receive the level of attention they deserve. Many developers still tend to view them as an afterthought, and once deployed, it’s not uncommon for APIs to languish for years without being reviewed or updated. Making sure APIs are secure requires dynamic scanning processes to be baked into DevOps workflows if organizations want to ensure the integrity of their software, said Sotnikov.

    APIs are, of course, everywhere now. The days when a handful of APIs were exposed to share data with a limited number of customers and partners are long over. There are almost no applications built and deployed today that doesn’t expose myriad APIs. Cybersecurity teams obviously can’t keep pace with the rate of change being made to those APIs, as new ones are added and others updated or replaced. The onus for securing all those APIs is, now more than ever, clearly on the DevOps team.

  • Red Hat Survey Reveals More Confidence in Open Source

    Red Hat Survey Reveals More Confidence in Open Source

    A recent Red Hat survey revealed how DevOps teams increasingly depend on open source to support their shift to cloud-native environments and digital transformations, and to maintain security in these highly distributed environments.

    Based on a survey of 1,250 IT professionals, Red Hat maintains that the survey respondents — from organizations that were Red Hat customers — were unaware that Red Hat sponsored the study to help avoid “biased or influenced responses,” Red Hat said in a statement. 

    During the past two years, the number of organizations that deemed open source necessary for their digital transformations increased 11% to 53%, representing the majority of the respondents’ organizations. 

    The vast majority (87%) of the respondents considered open source to be “more secure” than or “as secure” as proprietary software, while 84% indicated that enterprise open source “is a key part of my organization’s security strategy.”

    While the survey reflects open source’s importance for security for IT professionals in DevOps, its support of the overall business mission is key, as well, says Momodou Jaiteh, application security consultant at nVisium, an application security provider.

     “Information security is about reducing and mitigating risk to enterprises, from technology, people and process perspectives. It helps enable the business to operate securely in the best interest of its shareholders and customers,” Jaiteh said. “Thus, security typically plays a supporting, [but] nonetheless critical role in the success of the business, especially in a digitally connected world.” 

    Open source software often helps businesses reduce overhead cost in delivering services to their customers through reduced time to market, Jaiteh said. One major additional advantage is “visibility and input from a lot of different people,” Jaiteh added. 

    “Greater visibility often translates to more observing eyes on all aspects of the open source software, which often translates to better security. This is even better for mission-critical software that deals with sensitive information, such as cryptographic algorithms, etc.,” Jaiteh said. “It is not a surprise to see open source used more in infrastructure modernization, because as we move to DevSecOps models of software delivery, infrastructure often is the bottleneck. Therefore, solving for infrastructure helps developers focus on aspects that are unique to their business.”

    While survey respondents ranked improving collaboration between IT and business stakeholders to achieve a digital transformation as their highest priority, implementing cloud technologies or infrastructure ranked second. Infrastructure modernization is thus seen as a prerequisite for a full digital transformation, said Dirk Schrader, global vice president, security research at New Net Technologies (NNT), a cybersecurity and compliance software provider.

     “Open source plays a vital, pivotal role in almost all digital trends driving any industry sector today,” Schrader said. “Cloud computing or containerization is rooted in open source technology, many development libraries are open source, and the market for open source solutions has been a model for servitization; the changes in one’s business model away from selling a product to selling a service, or an integration of service, and product that focus on additional value-add for the customer.”

     For security, the main advantages consist of being able to review, inspect and audit “each and every piece of code,” Schrader said. 

    “The ability of open source to be a base for services makes it the natural companion for any digital initiative,” Schrader said.

  • The Surprising Secret to DevOps ROI

    The Surprising Secret to DevOps ROI

    As a result of my many years of DevOps consulting, I have discovered a simple, but not well-understood, secret ingredient that drives ROI for all the Three Ways of DevOps.

    Measuring and optimizing return on investment (ROI) for DevOps is not well-understood. It is a proven fact that DevOps, when engineered well, delivers tremendous value to organizations by way of continuous delivery practices. Reduced lead time, more frequent releases, lower failure rates and faster time to restore services are well-accepted indicators of DevOps value. It is not a secret that the combination of engineering DevOps practices for people, processes, and technologies around the Three Ways of DevOps – continuous flow, continuous feedback and continuous improvement – gets results. As valuable as these things are, they are not a measure of ROI, and do not tell you what to do to improve the return on your DevOps investments.

    How Do You Calculate and Optimize DevOps ROI?

    First, it is important to understand that ROI for DevOps is best measured using a simple ratio of return (R) divided by investment (I). (OK – for the accounting purists out there; I know the real ROI formula is actually (((R-I)/I)*100%) but that is a technicality that we don’t need for this argument.)

    The “return” of DevOps value is the important factor in the numerator of the ROI ratio. While there are many values that can be attributed to DevOps, the most direct value that can be measured and justified for legitimate comparison purposes is the cost savings associated with accelerating software delivery value streams. Application developers, and others, can get more applications released faster because of DevOps, which has a dramatic effect on valuable cost reductions. The “investment” in DevOps projects is the denominator of the ROI ratio. To optimize ROI, simply increase return by getting more application releases out faster, while reducing the investment required for a DevOps project. Sounds easy enough. But wait! How do you do that?

    The primary factor in the return is derived from reducing bottlenecks. I have found, in more than half of the thousands of DevOps value streams I’ve studied, that the biggest bottleneck is testing! It is a myth that continuous testing is just the execution of automated tests. I am talking about the whole range of ‘testing things,’ including test strategy, test planning, test resource scheduling, test design, test implementation, test environment management, test execution, test results reporting, test result analysis, troubleshooting, fix, retest and test management. That is a lot! In fact, testing things are a source of bottlenecks for every stage of a DevOps pipeline, for all three ways of DevOps. The point is that ROI can be greatly improved by improving testing.

    As it turns out, the primary factor in reducing investment costs also has to do with testing! Putting ‘testing things’ in place is expensive in terms of labor and capital costs for both people and systems. The primary factor to reduce total investment cost is to standardize, share and use ‘testing things’ with as many application pipelines and stages as possible.

    What is the secret ingredient that I have discovered? After all, the importance of testing itself is not much of a secret. I have isolated the key ingredient that is the heart of all ‘testing things.’ The purpose of a test is to determine a verdict. A test verdict is the codified representation of a pass, fail or inconclusive result state of a test, assessed relative to the purpose of the test. Test verdicts are essential, no matter what kind of test it is; no matter the stage in the pipeline a test is used. Without a verdict, all the ‘testing things’ in the world are not valuable.

    So – the secret ingredient for optimizing DevOps ROI is to optimize test verdicts. Those that know how to optimize test verdicts hold the key to optimizing DevOps ROI.

    As I indicated in this eBook I authored for the DevOps Institute, verdicts from properly engineered testing at each stage in the pipeline are essential for assessing the artifacts produced in each stage.

    How Can You Optimize Test Verdicts?

    As I have pointed out in prior articles, well-engineered DevOps requires balancing the nine pillars of DevOps.
    Surprisingly, test verdicts play a crucial role in optimizing all nine pillars of DevOps, and are vital to accomplishing the best return for the least cost investment in DevOps. Here are some examples of how this works for each pillar:

    Leadership – Leaders tend to underestimate the importance that ‘testing things’ have on DevOps ROI, and that the central ingredient of test effectiveness is the optimization of test verdicts. By sponsoring DevOps projects and training programs that drive improved test verdicts, leaders will have a direct and lasting impact on ROI.

    Collaborative Culture – How often have you seen people wasting time arguing over the meaning and importance of a test? Collaboration between application developers and QA and Ops teams is more effective when test verdicts are clear and based on a common understanding of the purpose and importance of each test.

    Design – The creation of excellent tests, designed to efficiently resolve to clear verdicts during the design phase, makes for reusable test assets in all subsequent stages and releases, and can be reused with other applications.

    Continuous Integration – The validation of builds is faster when all integration tests are arranged to get clear verdicts quickly during the build process.

    Continuous Testing – Test verdicts associated with each test are the key information ingredient that test management systems can key off to optimize test selection and test execution for each stage in the continuous delivery pipeline.

    Elastic Infrastructure – Test environment management (TEM) systems can optimize the orchestration of test resources better when test verdicts are clearly understood. Knowing a history of verdicts for a group of tests indicate which resources and how much of each resource are needed to run each test. This knowledge is essential to drive test environment management systems that have scaling algorithms for optimizing the use of ephemeral test environments, and to ensure test resources are used optimally.

    Continuous Monitoring – Reporting and analysis of test results can be a major bottleneck in the pipeline, but can be dramatically accelerated when the test verdicts are clearly defined.

    Continuous Security – Security tests are not much use without a clear verdict. While there is no such thing as 100% security assurance, the aggregate set of security test verdicts helps to profile security for applications and releases.

    Continuous Delivery – Algorithms that govern the ‘doneness’ of an application release candidate, and decisions to promote a release to production, depend on analysis of service level objectives (SLOs) derived from service level indicators (SLIs), including test verdicts. The fidelity and quality of those verdicts is essential for operations and site reliability engineering (SRE) teams to be confident enough to not bottleneck an application release.

    What This Means

    Measuring and optimizing DevOps ROI requires strategies that deliver value by improving returns through reducing bottlenecks and reducing investment costs. ‘Testing things’ are a dominant factor contributing dramatically to both the return and investment components of the ROI equation. A comprehensive strategy for optimizing test verdicts is the secret ingredient for optimizing and leveraging investment in ‘testing things,’ which, in turn, has a dramatic effect on improving DevOps ROI.

  • Linux Foundation Takes Control Of AsyncAPI Specification

    Linux Foundation Takes Control Of AsyncAPI Specification

    The Linux Foundation announced today that it now plays host to an AsyncAPI Initiative that has developed a specification and a suite of open source tools for asynchronous application programming interfaces (APIs) and event-driven architectures.

    Founding sponsors of the AsyncAPI Initiative include Ably Realtime, Apideck, Bump, IQVIA Technologies, Slack, Solace and TIBCO. Most recently, Postman, a provider of API management tools, committed to providing engineering resources to the project as well.

    AsyncAPI provides a language for describing the interface of event-driven systems, regardless of the underlying technology, and supports the full development cycle of event-driven architecture. That approach helps unify documentation automation and code generation, as well as managing, testing and monitoring asynchronous APIs.

    Chris Aniszczyk, CTO and vice president for developer relations at the Linux Foundation, said the Linux Foundation will work with the member organizations to facilitate a governing framework similar to the frameworks other open source projects have adopted under its auspices.

    In general, reliance on event-driven architectures is on the rise thanks, in part, to the rise of digital business process initiatives that require the processing and sharing of data across multiple platforms in near-real-time. The AsyncAPI Initiative makes it simpler for disparate event-driven platforms to be integrated. It’s unlikely multiple organizations involved in a digital business initiative are ever going to standardize on the same event-driven platform, so an AsyncAPI specification provides a critical linchpin.

    Usage of the AsyncAPI Initiative is already fairly widespread, with Adidas, PayPal, Salesforce, SAP and Slack all employing it in production environments. In fact, the Linux Foundation cited research that identified AsyncAPI as the fastest-growing specification being implemented by developers, after seeing adoption rates in production environments triple from 2019 to 2020.

    Event-driven IT architectures have, of course, been around for decades. However, as they have gained traction in the modern era of software development, the need for the equivalent of a REST API for asynchronous communications between platforms, based on different event-driven architectures, became apparent. The AsyncAPI doesn’t replace the need for other types of API specifications, but Aniszczyk noted that, over time, it will soon player a larger role, especially as cloud-native application environments become more distributed and the number of use cases that can’t be addressed using traditional batch-oriented techniques continues to rise.

    In the meantime, the number of providers of event-driven platforms based on proprietary architectures spans vendors ranging from Oracle and IBM to cloud service providers such as Amazon Web Services (AWS). At the same time, open source messaging platforms such as Apache Kafka are starting to have a significant impact on how IT teams build their own event-driven platforms.

    The level of enthusiasm for an API specification that makes all those platforms more interoperable than they would otherwise be is unclear. However, as modern IT platforms continue to evolve, more IT teams are becoming aware of the crucial role API specifications play in preventing them from becoming locked into one platform.

  • Sysdig Adds CSPM Module to DevSecOps Platform

    Sysdig Adds CSPM Module to DevSecOps Platform

    Sysdig today announced it added a cloud security posture management (CSPM) module to its Sysdig Secure DevOps Platform for monitoring application performance and security to enable IT teams to continuously detect threats.

    Pawan Shankar, director of product marketing for Sysdig, said this CSPM capability is based on an open source Cloud Custodian tool that enables IT teams to define rules for accessing cloud infrastructure. In addition, the tool enables IT teams to collect utilization metrics that could be used to turn cloud resources off when they are not being employed. IT teams can now also automatically discover all cloud services being employed, including identifying which ones are misconfigured or might have compliance and regulatory issues that need to be addressed, via a software-as-a-service (SaaS) platform.

    The overall goal is to help reduce the friction that organizations encounter today as they embrace DevSecOps best practices, added Shankar.

    Sysdig is making its CSPM offering available for free, for one account, to encourage DevOps teams to make use of a CSPM capability along with Sysdig’s open source Falco threat detection capabilities. Sysdig today also announced that it extended its implementation of Falco to consume audit logs created on the Google Cloud Platform (GCP). Sysdig donated Falco to the Cloud Native Computing Foundation in 2018. More recently, Sysdig also contributed a sysdig kernel module, along with libraries for the Falco security platform for Kubernetes, that runs in the extended Berkeley Packet Filter (eBPF) microkernel to further improve Linux security.

    The free tier includes a daily check against CIS benchmarks as well as support for inline scanning of up to 250 container images per month running on either the Fargate or Elastic Container Registry (ECR) services provided by Amazon Web Services (AWS).

    Sysdig has been making a case for the convergence of traditional IT monitoring functions and security for several years now. In the wake of some recent high-profile breaches involving software supply chains, the company is betting that more DevOps teams will soon be revisiting how their software supply chains are managed at a time when it’s become easier for malware to move laterally across an entire IT environment. In fact, Sysdig cited research that estimates that malware moving laterally through an organization is involved in 70% of cyberattacks.

    Of course, with the rise of applications based on microservices, the average IT environment is about to become a lot more integrated, which naturally makes it easier for malware to move laterally. IT organizations now require greater visibility across an entire potential attack chain to combat those threats, Shankar noted.

    As DevSecOps continues to evolve, the relationship between developers and cybersecurity teams is also clearly evolving. Now that developers are being held more accountable for cybersecurity, many of them are gravitating toward tools that can be easily integrated within the context of a larger DevOps toolchain.

    It remains to be seen exactly how security tools will be integrated within those tool chains, but for DevOps teams that already rely on Sysdig to monitor their IT environments, the ability to access a raft of additional security services is only a few mouse clicks away.

  • Celebrating the One-Year Anniversary of TechStrong TV

    Celebrating the One-Year Anniversary of TechStrong TV

    A year ago today, we started a new streaming project called “TechStrong TV” to provide the audience with an alternative source of information and entertainment, focused on delivering great tech content, during the unusual times of the COVID-19 pandemic. Little did we know back then what this would mean for all of us.

    In less than a year, TechStrong TV became an award-winning broadcast with thousands of videos, hundreds of thousands of views and more than 600 guest appearances by tech thought leaders, business leaders and industry experts. Our mission is to provide the best in-depth analysis on current industry issues and to deliver the most relevant tech news and the latest information on software development, DevOps, cloud-native, digital transformation and cybersecurity. Most importantly, we started doing this to help our community stay tech strong in times of uncertainty. We are committed to our community and we believe it is our duty to keep everyone informed and updated on everything that’s buzzing in the IT industry.

    TechStrong TV features a variety of video series that make up our daily show, including:

    • DevOps Unbound: A bi-weekly/monthly roundtable sponsored by Tricentis, providing a deep dive into DevOps, with an emphasis on automation, continuous delivery, accelerating transformation, testing and quality.
    • Analyst Corner: Hosted by Mitch Ashley and seasoned industry veterans, focusing on the latest trends and opportunities businesses see during these unprecedented times.
    • CISO Talk: A bi-weekly video series that explores the issues and topics that CISOs are dealing with today and how they prepare for the future.
    • The Lab, by GitLab: This monthly segment features GitLab Sr. Developer Evangelist Brendan O’Leary as he shares the latest GitLab updates.
    • The H4unt3d Hacker: A weekly podcast hosted by cybersecurity researcher and ethical hacker Mike Jones, one of the founders of Anonymous, and featuring like-minded cybersecurity professionals who discuss ideas and topics relevant to the industry.
    • Ambassador Insights: A monthly panel discussion featuring members of the DevOps Institute Ambassadors sharing their expertise and insights on various topics in the DevOps space.
    • WFH Fitness with Jeremy Jones: Jeremy, a member of the MediaOps sales team as well as a certified personal trainer, brings his knowledge of fitness to TechStrong TV with a 20-minute home workout for any level of fitness, from beginner to advanced.
    • Something Old: Replays of some of the most memorable presentations by top industry analysts and IT practitioners from past in-person and online events and virtual summits.

    We’ve had the pleasure to conduct executive-level discussions with outstanding thought leaders such as Sid Sijbrandij of GitLab, Shlomi Ben Haim of JFrog, Sacha Labourey and Stephen DeWitt of CloudBees, Ashok Reddy of Digital.ai, Sandeep Johri of Tricentis, Emmet B. Keeffe III of Insight Ignite and many more.

    Today, we not only celebrate the show, but we also celebrate each and every one of our hosts, guests, sponsors and, of course, our viewers, for being tech strong and supporting our community. We wouldn’t have made it this far without you. So, thank you for being a part of TechStrong TV and stay tuned because we have a lot of great content coming your way. We are only getting started.

    All the episodes of TechStrong TV are available on demand. You can watch our weekly TechStrong TV livestream on Monday, Tuesday and Thursday at 9:30 a.m. ET on the web, or on YouTube at DevOpsTV Channel, Facebook Live, LinkedIn Live, Twitter or on Roku, Apple TV and Amazon Fire TV via the DevOps.com TV app. Also on Android and iOS devices via the DevOps.com mobile app.

  • Tricentis Aquires Neotys to Gain Load Testing Tools

    Tricentis Aquires Neotys to Gain Load Testing Tools

    Tricentis announced today it has acquired Neotys as part of an effort to expand the scope of its tools portfolio into the realm of load testing. Terms of the deal were not disclosed.

    Neotys provides application testing teams with automatic test design and maintenance, user behavior simulation and root cause analysis capabilities using a set of tools that are designed to be integrated within a DevOps toolchain.

    Sandeep Johri, Tricentis CEO, said the Neotys platform will extend the scope of Tricentis’ Tosca testing platform that today enables DevOps teams to employ machine learning algorithms to test the functions within an application.

    In general, Johri said there’s now a lot more focus on load testing, thanks in part to the rise of microservices-based applications that are starting to be deployed at scale. DevOps teams are, first, trying to identify, as early as possible, a single point of failure that might bring down an application. Second, modern microservices-based applications are designed to degrade gracefully when there is no single point of failure. Identifying what issues are leading to that degradation can be challenging, given all the dependencies that might exist within a microservices-based application.

    Neotys claims to have more than 600 enterprise customers, including BNP Paribas, Dell, Lufthansa, McKesson and Verizon. Tricentis claims to have more than 1,800 customers, including McKesson, Accenture, Nationwide Insurance, Allianz, Telstra, Rockwell Automation, Moët Hennessy-Louis Vuitton (LVMH PCIS) and Vodafone. The acquisition of Neotys will reduce the number of vendors that an organization needs to engage to gain access to a portfolio of testing tools, Johri noted.

    As IT organizations embrace DevOps best practices, more responsibility for application testing is clearly shifting left toward developers. However, it’s not quite clear to what degree that shift is either eliminating or reducing the need for dedicated application testing teams at the back end of the application development process.

    At the same time, many rote testing tasks are now being automated using machine learning algorithms. Those algorithms don’t completely eliminate the need for humans to test applications, but they do significantly reduce the testing time required. They should also create more time for developers to collaborate with one another to review more complex interactions within an application that machine learning algorithms are unlikely to be able to automate any time soon.

    The amount of time organizations devote to application testing has always been constrained. As deployment deadlines approach, often the first thing that gets reduced is the amount of time allocated to application testing. In many cases, developers deliberately don’t address some known issues until the first or second update to an application that has already been deployed in a production environment.

    Of course, integrating application testing within a DevOps process enables organizations to identify more potential issues earlier when they are easier and less expensive to fix. The challenge has always been getting developers to appreciate the value of testing early and often in the application development process.

    Regardless of how application testing continues to evolve in the age of DevOps the one thing that is certain is no matter how automated it gets developers are going to be more involved than ever.

  • Achieving Reliable Observability Part 1 – Making Cloud-Native Observability More Robust

    Achieving Reliable Observability Part 1 – Making Cloud-Native Observability More Robust

    I was having a conversation with a CxO level customer as part of an AIOps/Observability workshop, and from what I could tell, most are confused about how to properly operationalize cloud-native production environments – especially the monitoring/observability portion. Here is how the conversation went.

    “Andy, we are thinking about getting [vendor] to use for our observability solution based on your recent research. What do you think?”

    “Well, I don’t want to endorse any specific vendor, as they are all good at what they do. But let’s talk about what you want to do, and what they can do for you, so you can figure out whether or not they are the right fit for you.” The conversation continued for a while, but the last piece is worthy of being called out specifically.

    “So, we will be running our production microservices in AWS in the ____ region. And we are planning to use this particular observability provider to monitor our Kubernetes clusters.”

    “Couple of items to discuss. First, you realize that this particular provider you are speaking of also runs in the same region of the same cloud provider as yours, right?”

    “We didn’t know that. Is that going to be a problem?”

    “Not particularly. However, you may get into a ‘circular dependency’ situation.”

    “What is that?”

    “Well, as an enterprise architect, I always call for separation of duties as a best practice. For example, having your developer testing the code is a bad idea, having your developer figuring out how to deploy is a bad idea. In much the same way as when your production services run in the same region as your monitoring software – how would you know about a production outage if the cloud region takes a hit, and your observability solution goes down at the same time your production services do?”

    “Should we dump them and go get this other solution instead?”

    “No, I am not saying that. Figure out what you are trying to achieve and have a plan for it. Selection of an observability tool should fit your overall strategy.”

    For those who don’t understand the above conversation, here is the reason why this scenario could be a problem.

    Coming from an enterprise architecture background, we were taught, as a best practice, to operationalize production systems to avoid circular dependencies. This includes not having two services depend on each other, or not to colocate monitoring, governance and compliance systems as part of the production systems themselves. If you were to monitor your production system, you would do it from a separate and isolated sub-system (server, data center rack, sub-net, etc.) to make sure that if your production system goes down, the monitoring system doesn’t go down, too.  The same goes for public cloud regions – although it’s unlikely, individual regions and services do experience outages. If your production infrastructure is running on the same services in the same region as your SaaS monitoring provider, not only won’t you be aware that your production systems are down, but you also won’t have the data to analyze what went wrong. The whole idea behind having a good observability system is to quickly know when things went bad, what went wrong, where the problem is and why it happened so you can quickly fix it. You can check out this blog where I explain this in detail.

    The best practice would be to either:

    1. Consider an observability solution that runs in a different region than your production workloads. Better yet, consider something that runs on a different cloud provider altogether. Although it is exceptionally rare, there have been instances of cloud service outages that cross regions. The chances of both cloud providers going down at the same time would be slim.For example, if the cloud region goes down (a region-wide outage in the cloud is quite possible, and seems to be more frequent of late), then your observability systems will also be down. You wouldn’t even know your production servers are down to switch to your backup systems unless you have a “hot” production backup. Not only will your customers find out about your outage before you do, but you won’t even be able to initiate your playbook, as you are not even aware that your production servers are down.
    2. Consider having your observability solution in a different location/region, yet still close enough to your production services so latency is very low. Most cloud providers operate in close proximity, so it is easy to find one.
    3. Another option is to get a solution that gives you deployment flexibility. For example, there are a couple of observability solutions that allow you to deploy it in any cloud and observe your production systems from anywhere – both in the cloud and on-premises.
    4. You can also consider sending the monitoring data from your instrumentation to two observability solution locations, but that will cost you slightly more. Or, ask what the vendor’s business continuity/disaster recovery plans are. While some think the costs might be much higher, I disagree, for a couple of reasons. First, because monitoring is mainly time-series metric data, so the volume and the cost to transport is not as high as logs or traces. Second, unless your observability provider is VPC peered, the chances are your data will be routed through the internet even though they are hosted in the same cloud provider. Hence, there will not be much more additional cost. Having observability data, all the time, about your production system is very critical during outages.
    5. A very commonly overlooked consideration is monitoring your full-stack observability system. While it is preferable to have the monitoring instance in every region where your production services run, it may not be feasible either because of cost or manageability. On such occasions, monitor the monitoring system. You could do synthetic monitoring by checking the monitoring API endpoints (or do random data inputs and check to ensure it worked) to make sure that your monitoring system is properly watching your production system. Better yet, find a monitoring vendor that will do this on your behalf.

    When/if you get the dreaded 2 a.m. call, what is your plan of action? Just think it through thoroughly before it happens and have a playbook ready, so you won’t have to panic in a crisis.