devopsy.kinsta.cloud

Category: Blogs

Oracle Looks to Increase Pace of Java Innovation

With the latest release of Java, it should become simpler for DevOps teams that build and deploy applications with the most widely used programming language in the enterprise to innovate faster.

Georges Saab, senior vice president, Oracle Java Platform, said Java 22 is unique in the history of Java in that it is specifically designed to enable developers to invoke capabilities that are available in beta and preview while still working with the other functions supported in the venerable programming language. The overall goal is to increase the pace of innovation in environments based on Java applications, he added.

The latest edition of the Java Development Kit (JDK), for example, provides access in preview to capabilities developed under a Project Amber initiative that makes it simpler to express strings that include values computed at runtime while also improving the security of programs that compose strings from user-provided values and pass them to other systems.

Meanwhile, a Project Loom initiative, also available in preview, streamlines error handling and cancellation in a way that improves observability using an application programming interface (API) that enables structured concurrency, while a Scoped Values capability provides a way to share immutable data within and across threads.

A Project Panama initiative adds a Vector API that promises to compile instructions at runtime when, for example, making use of retrieval-augmented generation (RAG) techniques to extend artificial intelligence (AI) models.

In terms of additional capabilities that are now generally supported, Java 22 adds an API to enable Java programs to safely interoperate with code and data running in memory outside of the Java runtime.

Most importantly, from an application performance perspective, the latest iteration of the language streamlines garbage collection processes in memory to reduce the number of times a Java application might otherwise need to be paused.

Despite the number of alternative programming languages that exist, the bulk of enterprise-class applications continue to be built in Java. While many developers are at least familiar with multiple programming languages, most tend to favor one primary programming language. Java developers, especially, have shown little inclination to abandon the language even as other programming languages, such as JavaScript, have emerged that are either simpler to use or, as in the case of Rust, may provide more robust security capabilities.

Less clear is at what rate developers are upgrading to the latest iteration. In some cases, developers are still making use of version 8, 11 or, more recently, 17. It may be a while before the bulk of Java developers are ready to make the jump to Java 22. In addition, DevOps teams will then need to decide when there is enough critical mass to warrant upgrading runtime environments to support another iteration of Java.

One way or another, either via an edition of Java provided by Oracle or another vendor, the programming language isn’t likely to be supplanted any time soon. The challenge now is providing support not just for the various versions of Java that might be running but, inevitably, all the other software artifacts written in various languages that are now also routinely moving through DevOps pipelines.

March 26, 2024
Survey Sees Cloud Developer Environment Adoption Gaining Momentum

A global survey found that while 95% of developers and business leaders are familiar with cloud development environments (CDEs), the reasons for adopting one vary widely. The survey polled 223 developers and business leaders working for organizations with more than 2,000 workers and 250 developers.

Conducted by Coder, a provider of a CDE, the survey, for example, found that while 15% cited optimizing the developer environment setup process as a reason for adopting a CDE, another 14% cited making management tasks such as onboarding or improving remote access easier.

Coder CEO Rob Whiteley said while CDEs clearly improve the productivity of application development teams and improve security by reducing the amount of source code running on notebook and desktop workstations, organizations looking to adopt CDEs need a significant amount of cultural resistance. Application developers have historically set up their own development environments on their own local machines. That approach, however, means that in addition to making it more challenging to collaborate also requires organizations to spend significant time and effort locking down each endpoint being employed by their developers, noted Whiteley.

In fact, those issues are why many platform engineering teams formed to centralize the management of DevOps workflows are implementing CDEs, he added. The ultimate goal is to establish a set of guardrails while still enabling developers to self-service their tooling requirements, noted Whiteley.

In fact, many DevOps teams have already built a homegrown version of a CDE that they currently maintain. Coder and other providers of CDEs are making a case for using a platform supported by a vendor rather than devoting resources to supporting a custom CDE, said Whiteley.

As DevOps workflows continue to evolve in the age of artificial intelligence (AI), it’s only a matter of time before more organizations embrace CDEs, he added. The sheer volume of data that developers will be working with will make it impractical to continue to use local machines to build applications, said Whiteley.

Regardless of the motivation for adopting CDEs, significant cultural changes are coming to DevOps workflows that need to evolve as application development continues to become more distributed. In the post-COVID-19 era, it’s now not uncommon for application development teams to consist of IT professionals working in different time zones. That creates a pressing need to leverage cloud services to provide the level of collaboration those teams need to achieve.

It’s not clear how many CDEs have been deployed, but as the pace at which applications are being built and deployed continues to accelerate, the days when organizations could allow each developer to maintain their own development environment are coming to an end. Organizations need to determine as quickly as possible whether the code being created will actually run in a production environment. The more time spent trying to reconcile differences between development environments and the production environment where the application runs, the longer it will take to complete any given project.

Unfortunately, time is the one thing that most DevOps teams no longer have the luxury of spending on application development initiatives that, in addition to multiplying, are also becoming much more complex to manage with each passing day.

March 26, 2024
Best Practices for Configuring MySQL Replication

MySQL provides several replication configuration options. However, ensuring it is done correctly may take time and effort, with considerable choices. Replication is a crucial initial step to enhance availability in MySQL databases. A properly designed replication architecture can significantly impact the accessibility of your data and prevent potential management complications. This article will delve into best practices for replication, covering local and long-distance scenarios.

Active and Passive Setups

When using active/passive mode for replication in MySQL, one server acts as the source while others serve as read-only replicas. The replicas can handle read-only queries, but all writes must be directed to the source. This configuration distributes the load across all replicas. Still, in the default asynchronous replication mode, there might be a delay between when data is written to the source and when it’s available on the replica. Keep this in mind while designing your application.

Alternatively, the active/active configuration allows multiple servers to handle both read and write operations. While it may seem beneficial to have two servers for write requests, each server still needs to process the query workload of the other, making write distribution less effective. Additionally, MySQL lacks native conflict resolution logic, so conflicts can quickly arise, making it challenging to determine the true source of data without significant data loss when a rebuild is necessary.

I recommend using the active/passive configuration for replication and sharding if you require higher throughput from your database.

Enable GTIDs

Global transaction identifiers (GTIDs) are unique IDs attached to transactions in a replicated environment. By default, replicas track processed records in the binary log file of a source database. However, this method is fragile if the source crashes and logs need to be restored.

With GTIDs enabled, each transaction receives a UUID-based ID, allowing replicas to determine if a transaction has been processed. The GTID is a UUID representing the source server, followed by an auto-incrementing ID (e.g., 14a54b2f-2ad0-43b6-b803-72b5d7151d3b:1). As transactions occur on the source, the UUID remains the same while the ID increases. When a replica processes a transaction, the GTID or GTID range (e.g., 14a54b2f-2ad0-43b6-b803-72b5d7151d3b:1-10) is stored in the gtid_executed table.

This process significantly reduces the risk of data becoming unsynchronized due to unprocessed or excessively processed transactions.

Replication Modes for Optimal Configuration

MySQL offers two replication modes that behave differently and should be understood to ensure optimal configuration for your environment. By default, MySQL employs asynchronous replication, where transactions are sent to the source, read by replicas and processed independently without source validation.

Alternatively, MySQL supports semi-synchronous replication, enabled as a plugin. In this mode, transactions are received by the source and processed by replicas, but the source waits for at least one replica to accept the transaction before responding. Semi-synchronous replication provides greater data consistency, though it introduces some overhead in response time.

With semi-sync mode, there are additional options that can be adjusted. By default, the primary server waits 10 seconds for a replica with semi-sync mode enabled to acknowledge the transaction. If data consistency relies on semi-sync, consider increasing this timeout value to ensure guaranteed consistency.

It’s important to note that these modes can be mixed and matched. For instance, you can configure one replica with semi-sync and another without, ensuring that one specific server always has an up-to-date copy of your database while other replicas catch up at their own pace. This approach aids disaster recovery by easily identifying the best candidate for recovery.

Understanding the distinctions between these modes will help you make informed decisions that align with your business needs.

Optimize Replica Instances With Separate Log Storage

Replica instances in your environment rely on the binary logs of the source for accurate information, as mentioned earlier. These logs are stored on the same disk as the database by default. However, this setup can overwhelm busy databases due to high throughput, including database manipulation and reading binary logs for replication. To address this, storing the binary logs on a separate disk from the database is recommended.

This approach offers performance benefits and cost savings in cloud environments where free volumes have strict IOPS limits.

Monitor Replication and Metrics in Managed Clusters

Monitoring is crucial for all infrastructure, including replication. With monitoring, it is possible to know if data is being replicated after configuration. SolarWinds database performance (formerly VividCortex) and Prometheus are popular solutions for monitoring replication and other metrics in managed clusters. Regardless of the chosen solution, it is essential to promptly notify the appropriate individuals when issues arise and address them before they escalate.

Create a Failover Plan for Minimizing Disruptions

Inevitable software or hardware failures necessitate failover planning to minimize potential disruptions. Utilizing replication offers resilience by ensuring multiple servers house your online data simultaneously. Therefore, your team must possess a well-prepared strategy should the primary data source fail. The following example outlines an unplanned failover process:

● Ensure the downed source remains offline to avoid unexpected replication issues.
● Identify and remove the read_only option from the chosen replica that will serve as the new data source. If using semi-sync, select the replica previously configured with the plugin and source.
● Update your application to direct queries to the newly promoted source.
● Modify the remaining replicas to start replicating from the new source.

Optimize Cross-Region Replication

Cloud providers typically provide services across multiple geographic regions comprising several data centers. These data centers, known as availability zones (AZs), are strategically located within the same region but far enough to withstand disasters. Replicating databases to different physical locations is recommended but requires careful consideration. Replication introduces additional latency due to the distance the data needs to travel. Fortunately, latency between AZs is generally low, with AWS claiming single-digit millisecond latency within the same region.

In contrast, there is significant latency between regions. For example, at the time of writing, the latency between us-east-1 and us-west-1 was reported to be over 60ms by Cloudping.co. Replication across regions results in replication lag, which is the time difference between data being written to the source and being written to a replica. This lag is even more pronounced when replicating across longer distances.

Asynchronous mode should be used for replication across regions to avoid unnecessary delays for applications making requests.

A comprehensive understanding of replication configuration options is crucial. However, it is equally important to determine the optimal configuration for these options. This can significantly impact your MySQL cluster’s operational efficiency and data-serving capabilities.

March 26, 2024
From Chaos to Clarity: Streamlining DevSecOps in the Digital Era

These days, securing the software development lifecycle from end to end requires organizations to deploy, maintain, and master a cacophonous mix of tools that often do more to create discord rather than bring harmony to DevSecOps processes. The reason for this is simple: Each tool employed to secure a software supply chain independently runs scans and generates alerts that lack context, are often redundant, or flat-out contradict one another.

Developers and the software engineers that support these applications are, of course, expected to correlate the steady streams of alerts and address vulnerabilities to meet security thresholds required to propagate the release to an upstream environment. The reality is that not all of the vulnerabilities flagged as high and critical need fixing, nor is it possible for a team to address all of the vulnerabilities. On average, a development team has the bandwidth to address 10% of its vulnerability backlog in any given month. This makes it imperative to prioritize the vulnerability backlog based on impact rather than severity if we are to give these development teams a ghost of a chance to succeed in improving their security posture.

The constant alert storms also lead to fatigue and introduce a real risk of false negatives. The one that got away!

DevSecOps workflows today are little more than sections of an orchestra playing without a score with the expectation that some methodology to consistently lock down a software supply chain will magically manifest.

What’s obviously missing is an orchestration framework that triggers the security workflow in response to changes within the SDLC. Ideally, it works seamlessly with the CI/CD workflows, but without being dependent on them, creating a symphony capable of providing a better security posture for the organization.

The Trouble With DevSecOps

In cloud-native, microservices-based application development environments, teams could be developing using multiple technologies, each optimized for delivering a certain service. Each technology may require a certain specialized scanning tool—and that’s just code; by the time we add binary, infrastructure pipeline, data and identity to the mix, you end up with a vast array of tooling and a huge set of policies that every change needs to be assessed against.

Yes, you can scan containers on a periodic basis before deploying to production and that might be OK if you are deploying one release per month. However, even then you could argue that by the time the vulnerabilities are picked up, it’s too late and you have already lost the battle on efficiency.

The very reason you went with a microservice-based architecture is so that it’s easy to scale and quick to build and deploy. Ideally, you would want to be releasing features rapidly for your customers. This means a very high degree of change, which in turn means the point-in-time assessment you did will simply not be fit for purpose in terms of protecting your assets. Every commit has the potential of exposing a new risk, which may end up being discovered too late if left to point-in-time assessments.

Instead, if security is orchestrated seamlessly and asynchronously through tool-agnostic interfaces across your CI/CD pipelines, delivering the outcomes required to secure your digital assets from the first commit right through to the production deployments and beyond, you have truly adopted DevOps. In this scenario, every change is assessed in real-time, and its impact is projected across to development, operations, and security with a clear call to action.

This approach also provides a more extensible and scalable framework for organizations as they advance through their journey of DevSecOps adoption.

Summary

No development team deliberately sets out to build and deploy an insecure application. The reason applications with known vulnerabilities are deployed so often is because the cognitive load associated with discovering and remediating them is simply too high. The average developer can only allocate 10% to 20% of their time remediating vulnerabilities. The rest of their time is spent either writing new code or maintaining the application development environment used to write that code. If organizations want more secure applications, they need to find ways to make it easy for developers to correlate, prioritize and contextualize the vulnerabilities as they are being identified. Most of the time when developers are informed a vulnerability has been discovered in their code, they have long since lost context.

Vulnerabilities need to be immediately identified at the time code is written, builds are created, and pull requests are made – and identified in a way that is actionable. Otherwise, that vulnerability is likely to be thrown atop the massive pile of technical debt that developers hope they’ll one day have the time to address.

At this juncture, it’s only a matter of time before governments around the world enact legislation that will hold organizations more accountable for the security of the software they build and deploy. Savvy DevSecOps teams already recognize that existing approaches to managing DevSecOps workflows will need to be revamped to address these requirements. The challenge and the opportunity now is to put in place a scalable security orchestration framework that eliminates friction in DevSecOps workflows and drives efficiency through real time assessments, ensuring that your software is secure by default.

March 25, 2024
Five Great DevOps Job Opportunities

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

Indeed.com

Western Climate Initiative
Sacramento, California
DevOps Engineering Manager
$175,000 to $200,000

CareerBuilder.com

Leidos
Herndon, Virginia
Senior DevOps Engineer
$122,200 to $220,900

SimplyHired.com

Hallmark
Remote
DevOps Engineering Manager
$120,000 to $160,000

Dice.com

LTIMindtree
Atlanta, Georgia
Azure DevOps Lead
$100,000 to $130,000

LinkedIn

Nintendo
Redmond, Washington
Associate Engineer – DevOps
$84,800 to $127,200

March 25, 2024
Job Hunting

March 25, 2024
OpenTelemetry Project Maintainers Add Code Profiling Capabilities

This week at the KubeCon + CloudNativeCon Europe conference, the maintainers of the open source OpenTelemetry observability agent software project being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) revealed they have added profiling capabilities to enable DevOps teams to identify the root cause of issues down to a specific line of code.

Austin Parker, director of open source for Honeycomb and a maintainer of OpenTelemetry, said while several providers of IT observability platforms have in the past year added code profiling capabilities, it makes more sense to provide this as a capability surfaced by OpenTelemetry in a way that any IT platform can easily consume.

The overall goal is to reduce the amount of time it takes to troubleshoot IT issues by identifying not just the code at issue but also the development team responsible for it, noted Parker.

OpenTelemetry defines a format that makes it simpler to centrally manage the collection metrics, logs and traces using open source software. In general, OpenTelemetry continues to gain traction as DevOps teams look to rationalize the amount of commercial agent software they need to deploy, update and manage.

In effect, OpenTelemetry is aggregating agent software that, in terms of observability, provides no differentiated value, said Parker. That’s critical because as application environments become more complex, it’s all but impossible to manage them without being able to broadly apply the agent software required to instrument them.

In the future, OpenTelemetry is expected to add additional capabilities such as data pre-processing, filtering or routing to redact sensitive data in a way that still fosters observability.

Ultimately, as OpenTelemetry becomes more widely employed, it makes it significantly easier for developers to understand how their application is performing, noted Parker. Over time, armed with those insights, developers will build and deliver higher-quality applications, he added.

It’s still early days as far as adoption of OpenTelemetry is concerned, but it’s clearly well on its way to becoming a de facto standard for enabling observability. The number of developers who have access to not just metrics and logs but also traces should steadily increase as the cost of instrumenting code declines.

Of course, finding a way to collect that data inexpensively will also be crucial for applying artificial intelligence (AI) to DevOps workflows. After all, before an AI model can be trained, it needs access to verified data.

In the meantime, DevOps teams might want to consider at what rate they can replace existing commercial agents deployed across the enterprise. Much of that agent software is more mature than OpenTelemetry, but over time, the economic arguments for using open source agent software become compelling. Many of the providers of observability platforms have already made support for OpenTelemerty available by default.

Regardless of approach, the need for observability has always been apparent. The issue is that there is a world of difference between monitoring a pre-defined set of metrics and being able to launch queries to identify the root cause of an issue that metrics alone are not going to be able to surface.

March 22, 2024
Time to Extend DevOps Visibility to the Network Edge

Performance issues regularly confound DevOps teams after an application is deployed, despite the number of tests run before deployment. Upon further investigation, the issue that is most frequently overlooked is the distributed nature of the application itself. End users accessing applications from multiple locations are never going to have the same level of internet service, so software that may be running perfectly well in locations that are major urban technology hubs, such as New York, San Francisco or London, is not necessarily going to provide the same experience in farther-flung regions, especially rural areas that are halfway around the world.

All internet services are not created equal. Intermittent network latency issues can have a profound impact on application performance simply because of the laws of physics. The farther away an end user is from the data center where the application is hosted, the more likely it becomes network latency will adversely affect application performance.

Unfortunately, most DevOps teams lack any visibility beyond the data center environment where the application is running. Naturally, the first step toward gaining that level of insight starts at the edge of the network.

Internet Stack Visibility

There is a wide range of services that make up an internet stack, each of which can adversely impact the performance of distributed applications. Everything from virtual private networks (VPNs) and content delivery networks (CDNs) to domain name system (DNS) servers and switches adds latency that, depending on how network traffic is being routed, can have a major impact on application performance. Any one of these services might be experiencing an outage or, more challenging to detect, intermittent degradations that unpredictably impact application performance. Whether it’s a software-as-a-service (SaaS) application being accessed in the cloud or an internet-of-things (IoT) platform running at the network edge, pinpointing which internet service might be the root cause of an issue requires the ability to closely monitor and observe that traffic.

Without any visibility into the internet stack, surfacing the insights needed in a way that provides the context required to optimize and troubleshoot a specific application becomes an impossible challenge. All the time and effort spent building an application can come to naught simply because no one understood the impact network latency would have on the application before it was deployed. Even after an application is deployed, any change to the way network traffic is being routed can have major consequences. Without any means of understanding what changes may have occurred, it might be weeks or months before an organization realizes it may need to log a service request or switch service providers.

Any truly comprehensive approach to observability clearly needs to include an analysis of the internet services upon which organizations crucially depend to ensure a consistent application experience is delivered and maintained. Depending on how the IT team is structured, those insights can be fed into an observability platform that the organization has adopted or correlated using an internet performance monitoring (IPM) platform.

DevOps Needs NetOps

Regardless of the approach, it’s never been more crucial for network operations (NetOps) and DevOps teams to be able to align their approaches to monitoring distributed computing environments. More latency-sensitive applications are being deployed than ever. In an ideal world, DevOps teams working closely with NetOps should be able to programmatically provision and alter networking services as needed. Not every internet service can be adjusted via an application programming interface (API), but most NetOps teams have access to consoles that enable them to upgrade to different service levels when needed. At the very least, a service provider will work with them to make any changes required.

Of course, it becomes more challenging to negotiate if the NetOps team doesn’t know which element of the Internet stack needs to be upgraded. A service provider that typically doesn’t have any visibility into the application might spend weeks trying to determine which element of the Internet stack they manage is at fault. IT teams that have their own means of monitoring a set of internet services are going to be able to work with their service providers to resolve those issues much faster.

Summary

Savvy IT teams are all too aware of how prone internet services are to outages and brownouts, so as a rule, they tend to make sure network traffic can be rerouted from one service to another. That approach also provides the added benefit of maintaining some pricing leverage as they negotiate fees for the services provided.

It’s also worth remembering providers of networking services that know a customer is locked in may not have as much incentive to make sure networking services are running at peak efficiency. The only way an IT team is ever going to know what level of service is being delivered at any given time is, of course, to generate an IPM report that precisely details what services were actually available at what level of performance. Otherwise, they are wholly dependent on the report a service provider presents alongside their monthly bill.

Just as critically, the reports generated by an IPM platform also surface insights that, when shown to application developers, create a potential opportunity to optimize their code. Without that level of analysis, every developer will assume the network services are either broken or poorly managed. The challenge and the opportunity now is to provide internet performance intelligence in a way that every stakeholder cannot just act on but, just as critically, implicitly trust.

March 22, 2024
Edge Computing Requires DevOps at Scale

The rise of edge computing is about to drive a long-overdue convergence of DevOps, data engineering, security, networking, operational technology (OT) and machine learning operations (MLOps) best practices, which will ultimately make IT teams more responsive than ever to the needs of the business.

Historically, each of these IT disciplines has tended to work in isolation, with deliberate handoffs being made between the various teams employed to provision and maintain various services. The challenge is that as more applications are deployed at the network edge, the need for IT teams to work hand-in-glove is crucial. Applications not only need to be deployed across a much more distributed computing environment, but they also need to be regularly updated and patched.

At the same time, increasing amounts of data are being processed and analyzed at the point where it is collected and consumed. More stateful applications running at the network edge are passing aggregated analytics data back to applications running in the cloud or on-premises IT environment. That shift requires a fundamentally different approach to how storage is managed across multiple edge computing environments and the various federated backend systems spanning the enterprise.

Organizations will typically need to store files locally on edge computing platforms while also storing copies of those files in the cloud using an S3-compatible storage service that provides access to inexpensive object-based storage to enable everything from data protection to driving artificial intelligence (AI) applications. That multi-protocol capability creates an opportunity to not just build new stateful distributed applications but also modernize existing applications regardless of what protocols are being used to store data.

Most edge computing platforms today are managed by OT teams that report directly to the leaders of specific business units. However, as more of these platforms are connected to networks, the greater the imperative to centrally manage them as part of any effort to lower the total cost of IT. After all, the most expensive element of IT remains the cost of the labor still required to manage it.

Naturally, sharing data in near real-time across a distributed computing environment puts more pressure on network operations (NetOps) teams. Instead of updating applications in batch mode once a day, data continuously streaming from thousands of edge computing platforms needs to be synchronized with multiple applications to surface the latest, most accurate insights.

More challenging still is that much of that data is being used to train AI models that ultimately require the associated inference engine created to be deployed at the edge. To process terabytes of data, the underlying platform required to support those inference engines also will need to be measured in terabytes. Over time, AI models tend to drift or, in the case of generative AI, outright hallucinate, over time. Data scientists will need to work closely with DevOps teams to replace those AI models because, unlike a traditional application, they can’t be updated via a patch. The entire AI model needs to be replaced with one that is not just more reliable but also—and just as importantly—safer.

Finally, the need to secure edge computing platform is nothing short of critical. Cybercriminals tend to view these platforms as gateways to the rest of the enterprise. Each new edge computing platform deployed extends the size of the attack surface that needs to be defended. Unless cybersecurity teams are deeply involved in building and deploying edge computing applications and platforms, it’s only a question of when, rather than if, a breach will occur.

It may be a while before these various IT fiefdoms converge, but at this point, it is all but inevitable. In fact, it will soon be difficult to distinguish between edge computing and the rest of the IT environment as event-driven applications spanning multiple platforms become more the norm than the exception.

DevOps teams, as part of their relentless commitment to automation, should naturally be at the forefront of these efforts. Rather than confining DevOps principles to how applications are built and deployed, the time has clearly come to automate IT workflows on an end-to-end basis. The only way to programmatically manage edge computing at scale is to also apply DevOps principles at scale. Also known as platform engineering, that approach enables organizations to manage distributed IT environments at scale without requiring organizations to hire a small army of IT teams to manage it all. There will always be a need for specialized expertise, but as IT continues to evolve the siloes that slow down the pace of innovation will need to come down.

Not every member of an IT organization needs to know how to expertly manage every task, but they should be familiar with the inherent dependencies that exist between applications, networking, storage and cybersecurity to advance the goals of businesses that have never been more dependent on IT.

Each organization needs to determine the pace of convergence that best suits its needs, but the faster it occurs, the greater the return on the investment in edge computing will become. The challenge and the opportunity, as always, will be managing yet another major IT transition, where the issues that need to be resolved are as much cultural as they are technical.

March 22, 2024
How Generative AI Enables Unified Continuous Testing Platforms

It is time for a unified continuous testing platform.

Existing software testing platforms and tools specialize in testing activities for a subset of the different stages of value streams. The landscape of software testing tools includes a wide range of solutions, each with its strengths, focusing on specific aspects of software development, delivery and operations.

For instance:
• Unit Testing Tools focus on the earliest stages of development, allowing developers to test individual units of code for correctness.
• Integration Testing Tools aim to test the interactions between different modules or services within an application.
• System Testing Tools are designed for end-to-end testing of the complete system before it goes live.
• Performance Testing Tools assess the application’s behavior under load and stress conditions.
• Security Testing Tools focus on identifying vulnerabilities within the application.
• User Acceptance Testing (UAT) Tools facilitate the final testing phase, where end-users validate the solution against their requirements.

The challenge with unifying these diverse testing needs into a single continuous testing platform is multifaceted. Such a platform needs to seamlessly integrate with a wide variety of development tools and environments, support different testing methodologies, and be flexible enough to adapt to different organizational processes and quality standards.

While there are Continuous Integration/Continuous Deployment (CI/CD) tools that incorporate multiple testing stages, they often do so by integrating with specialized testing tools rather than offering a unified testing solution themselves. These CI/CD tools are closer to orchestrating the various testing activities rather than unifying them under a single platform’s capabilities.

However, the concept of a fully unified continuous testing platform, covering every stage from requirements through to deployment and in-production testing, represents a significant opportunity for innovation in the software development tools space. Achieving this would likely require leveraging advancements in areas like generative AI, as discussed in my prior blog Applying AI/ML to Continuous Testing to create adaptable, intelligent testing processes that can cover the full spectrum of testing needs in a cohesive manner.

Benefits of a Unified Continuous Testing Platform

Improved Efficiency and Speed: A unified CT platform integrates testing across all stages of the software development lifecycle (SDLC), significantly streamlining the testing process. This integration facilitates automated, continuous feedback loops that promptly identify and address defects, allowing development teams to quickly iterate and improve. As a result, teams can release new features and fixes more rapidly, accelerating the product’s time to market and enhancing responsiveness to customer needs and market changes.

Enhanced Quality and Reliability: By ensuring comprehensive and consistent testing across the entire application, a unified CT platform plays a crucial role in identifying and mitigating issues early in the development cycle. This early detection helps maintain a high level of software quality and reliability, leading to increased user satisfaction and trust in the product. The consistent application of quality standards across all testing phases contributes to a robust and dependable software product.

Cost Savings and Reduced Maintenance: Automating the testing process through a unified CT platform not only optimizes resource utilization but also significantly reduces the costs associated with manual testing and late-stage defect remediation. Early defect detection translates to lower fix costs, and the streamlined process decreases the overall time-to-market. Additionally, high-quality, reliable software requires less maintenance, further reducing long-term costs and freeing up resources for innovation and development efforts.

Improved Collaboration Across Teams: A unified CT platform fosters a culture of collaboration and transparency among development, testing, and operations teams. By providing a common framework and tools for all testing activities, it breaks down silos and enables seamless communication and collaboration across the SDLC. This improved collaboration ensures that teams are aligned with the project goals, can share insights more effectively, and work together to identify and solve problems more efficiently, leading to better outcomes.

Together, these benefits highlight how a unified Continuous Testing platform can transform the software development process, making it more efficient, cost-effective, and collaborative while ensuring the delivery of high-quality and reliable software products.

While many tools address specific parts of the testing lifecycle, the vision of a single platform that seamlessly unifies all stages of testing from requirements to in-production remains an ambitious goal. It’s a gap in the current technology landscape that presents both a challenge and an opportunity for future development.

Challenges for Unified Continuous Testing Platforms

Creating a continuous testing platform that unifies test activities for all stages of the end-to-end value stream is a complex challenge due to several factors:
1. Diversity of Technologies and Tools: Modern software development environments are highly diverse, incorporating various programming languages, frameworks, and technologies. Creating a platform that seamlessly integrates with all these technologies is challenging.
2. Complex Integration Points: Continuous testing needs to integrate with multiple stages of the development pipeline, including development, deployment, and operations. Each of these stages might use different tools and processes, making it hard to create a one-size-fits-all solution.
3. Varying Quality Metrics: Different teams and projects may have different definitions of quality, success criteria, and performance metrics. A unified testing platform needs to be highly customizable to cater to these varying needs.
4. Change Management: Adopting a new platform requires changes in the organization’s processes and workflows. Resistance to change is common in organizations, and transitioning to a new way of testing can be met with skepticism and inertia.
5. Scalability and Performance: Ensuring the platform can scale to handle the testing needs of large organizations with thousands of tests running concurrently is a technical challenge. Performance issues can become a bottleneck, affecting the overall efficiency of the development process.
6. Security and Compliance: Integrating testing across all stages of development also introduces security and compliance challenges. The platform must ensure that sensitive data is protected and that testing practices comply with regulatory requirements.
7. Cost and Resource Constraints: Developing, maintaining, and supporting a unified continuous testing platform requires significant investment. Organizations might be hesitant to commit the necessary resources without clear evidence of return on investment.
8. Evolution of Practices: Software development practices and tools are constantly evolving. Keeping the platform up-to-date with the latest practices and technologies requires ongoing effort and innovation.

Despite these challenges, there is a growing recognition of the value of continuous testing throughout the software development lifecycle. Some companies and open-source communities are making strides in this direction, creating more integrated and flexible testing solutions. However, achieving a fully unified platform that addresses all these challenges is an ongoing effort and represents a significant opportunity for innovation in the software development and testing industry.

Generative AI Can Facilitate a Unified Continuous Testing Platform

Generative AI can play a significant role in overcoming the challenges associated with creating a continuous testing platform that unifies test activities for all stages of the end-to-end value stream. Here’s how generative AI might address each of the challenges:
1. Diversity of Technologies and Tools: Generative AI can be trained on a wide range of programming languages, frameworks, and technologies to understand and generate code or testing scripts. This capability allows it to adapt to different environments and create testing materials that are compatible with various tools and technologies.
2. Complex Integration Points: AI can analyze the workflow of development pipelines and suggest optimal integration points for testing. By learning from different CI/CD (Continuous Integration/Continuous Deployment) configurations, AI can recommend best practices for integrating testing seamlessly into existing workflows.
3. Varying Quality Metrics: Generative AI models can be customized to understand and apply different quality metrics and success criteria based on project-specific requirements. By training on diverse datasets, these models can adapt to various definitions of quality and generate relevant tests or analysis.
4. Change Management: AI can assist in the change management process by simulating the outcomes of adopting new testing platforms, thereby providing evidence-based benefits and mitigating resistance to change. Furthermore, AI-driven analytics can highlight the efficiency gains and quality improvements to support the transition.
5. Scalability and Performance: Generative AI can optimize testing processes by identifying redundancies and suggesting improvements, thus enhancing performance. Additionally, AI can dynamically allocate resources based on testing needs, ensuring scalability without compromising efficiency.
6. Security and Compliance: AI models can be trained to identify and flag potential security and compliance issues in the testing process. By continuously learning from the latest security standards and compliance regulations, AI can help ensure that testing practices meet the necessary requirements.
7. Cost and Resource Constraints: By automating the generation and optimization of test cases, generative AI can significantly reduce the manual effort required, lowering costs and resource demands. AI can also help prioritize testing efforts based on risk assessment, ensuring that resources are focused where they are most needed.
8. Evolution of Practices: Generative AI models are inherently adaptable and can continuously learn from new development practices, tools, and technologies. This ensures that the testing platform remains up-to-date with the latest advancements in software development.

Generative AI has the potential to transform continuous testing by providing adaptive, efficient, and intelligent solutions to the complex challenges of unifying test activities across the end-to-end value stream. However, realizing this potential requires careful design, extensive training of AI models, and ongoing management to ensure that the AI systems remain effective and aligned with evolving testing needs.

Summary: Call to Action

The need for a unified Continuous Testing (CT) Platform has never been more urgent. Current testing platforms, each adept in their niche, cover only fragments of the software development lifecycle (SDLC), leading to a disjointed and inefficient testing process. This fragmentation not only slows down development and deliveries but also compromises the quality and security of the final product. The dream of a single platform that seamlessly integrates all stages of testing, from requirements through to deployment and in-production testing, represents a monumental leap toward efficiency, security, and quality in software development.

The challenges in creating such a platform are manifold, ranging from the diversity of technologies and tools to the evolving nature of software development practices. Each challenge, from integrating diverse technologies and managing change within organizations to ensuring scalability and compliance, adds complexity to the development of a unified CT platform. Yet, the potential benefits of overcoming these hurdles are immense, promising a significant boost in the speed and quality of software delivery. The industry’s recognition of these benefits is growing, evidenced by the efforts of some companies and open-source communities moving towards more integrated and flexible testing solutions.

Generative AI emerges as a beacon of hope in this quest, offering innovative solutions to the multifaceted challenges of unifying test activities. By harnessing the power of generative AI, the industry can address the diversity of tools, integrate complex testing stages, adapt to varying quality metrics, manage organizational change, scale efficiently, ensure security and compliance, and evolve with the practices of software development. The path forward requires a concerted effort, but investments in AI-driven testing innovations can realize the vision of a comprehensive, unified, continuous testing platform. This is not just an opportunity for enhancement but a call to action for the industry to redefine the future of engineering platforms.

March 21, 2024