Category: Sponsored Content

  • Smoothing the Never-Ending Road to Modernization

    Smoothing the Never-Ending Road to Modernization

    In IT, it can sometimes feel like the finish line keeps getting farther away, no matter how fast we run.

    Cloud migration reshaped how organizations think about infrastructure, offering new scalability and agility, while creating years of intensive migration work that continues to this day. Then, application modernization shifted the conversation from where workloads run to how effectively applications can leverage modern architectures and services. Suddenly, IT teams found themselves modernizing both their applications and their environments simultaneously.

    Today, AI is creating yet another wave of modernization efforts, with organizations seeking ways to connect agents to existing applications and data.

    If it feels as though there’s always another modernization initiative around the corner, that’s because there generally is. In reality, IT has no finish line. After all, the future doesn’t wait for organizations to finish the modernization initiatives of the past.

    Technologies evolve, business needs change, and it’s up to the IT shop to ensure their environments and applications keep pace.

    We’ll never reach an end state where environments and applications are finally, permanently “modern.” But that doesn’t mean IT professionals need to experience life as one mad scramble after another.

    There’s a better way.

    The Move to Continuous Modernization

    We tend to think of IT modernization in terms of major projects such as huge cloud migrations or enterprise-wide application refreshes and upgrade campaigns. But really, much of modernization consists of smaller, recurring tasks like updating libraries, remediating vulnerabilities, and keeping applications aligned with internal development standards.

    Treating all this work as a series of manual projects can eat up significant engineering time and leave IT teams feeling they’re never able to get ahead. But by automating many of these tasks, organizations can free up capacity for real innovation. And especially critical at the current moment: they can make legacy applications and data ready for agents without a rewrite, and without waiting for every last workload to move.

    That’s the idea behind AWS Transform – continuous modernization, a new capability of AWS Transform for continuous, autonomous technical debt analysis and remediation. While AWS Transform already helps enterprises migrate to the cloud, modernize applications, and streamline software maintenance, this new agentic capability gives organizations broad visibility into the state of their codebase across thousands of repositories. It provides detailed dependency mapping to help prioritize findings, and code changes are delivered as pull requests for developer review.

    Out of the box, the offering includes policies for detecting end-of-life dependencies, deprecated frameworks, and other common sources of technical debt. IT teams can also extend these capabilities with remediation patterns specific to their organization, including approved libraries, internal coding standards, or tech debt policies that their platform teams already enforce.

    The goal is to help organizations continuously reduce technical debt and keep their frameworks and codebases AI-ready, without requiring developers to spend all their time managing legacy code in the name of modernization.

    Continuous Modernization in the Real World

    Only weeks after this new offering was announced, organizations are already seeing the impact of continuous modernization. Tasks that once required substantial manual effort now happen much more quickly, at a scale that would have been impossible before.

    Quantiphi, an AI-first digital engineering and services company based in Massachusetts, ran continuous modernization across a large portfolio, compressing a multi-week assessment into days. The company analyzed more than 500 repositories, uncovering more than 3,000 technical debt findings in under a week. By automating technical debt discovery and uncovering actionable remediation insights, company leaders said, they were able to reduce their assessment effort by more than 60%.

    Tech Mahindra, a multinational consulting and engineering company based in India, saw even more dramatic time savings, reducing assessment time across 25 enterprise repositories by 80%, from 40 hours down to just eight. Sanjeev Agarwal, the company’s global head of AWS business, said company leaders see this as the “beginning of a transformative shift” in how organizations approach IT modernization. “AWS Transform’s scanning and analysis engine is solid, and the structured output allows our teams to validate findings quickly and build prioritized remediation plans with confidence,” he said.

    And U.S. healthtech company Netsmart used AWS Transform – continuous modernization to help five teams accelerate projects that were estimated to take between three months and a year. Some were completed as quickly as two weeks. “Dependency mapping has historically been a tedious, complex and ongoing effort,” said Pepper Pancoast, Senior Director of Engineering. “This new capability helps automate dependency mapping on a recurring basis, giving us greater visibility into our codebase health at scale.”

    Learn More

    On October 22 at 1 p.m. Eastern, AWS leaders will join Futurum Group CTO Advisor, Alastair Cooke, for a webinar discussion titled “Continuous Modernization: Why Modernization Never Really Finishes.”

    Together, we’ll explore what changes when organizations stop considering modernization as a project with a finish line, and instead embrace the tools and practices needed to continuously modernize across their IT environments.

    Attendees can expect to learn how to:

    • Turn manual, reactive software maintenance into continuous modernization.
    • Unlock engineering resources and reduce maintenance costs.
    • Gain a broader, more transparent view across their codebases.
    • Reduce tech debt at scale and ensure their codebase is AI-ready.

    Register here to join us.

  • Why Software Supply Chain Security Is Moving to the Gate

    Why Software Supply Chain Security Is Moving to the Gate

    March 2026: malicious versions of axios get published directly to npm. May 2026: attackers forge valid provenance for 42 TanStack packages on npm, with 84 malicious versions shipped before detection. August 2026: a worm uses one maintainer’s stolen credentials to self-propagate through keyv and its dependent packages.

    Builds pull in thousands of open source packages from public registries without a second thought, and attackers are getting very good at poisoning these packages at the source. As dependency installation increasingly runs through agents rather than engineers, these supply chain attacks are going to happen faster and more frequently.

    The software supply chain security ecosystem seems to have converged on the same fix within the last year: proactive enforcement. npm 12 has disabled dependency install scripts outright by default, closing what GitHub called the single largest code-execution surface in the npm ecosystem.

    Repository managers reached the same conclusion. Sonatype’s Repository Firewall can quarantine and auto-release packages ahead of consumption. Cloudsmith runs cooldown policies that hold newly published packages until they have been checked. Socket inspects packages for behavioral indicators of compromise ahead of installation.

    Perhaps the most significant architectural adjustment we’ve seen is that JFrog is deprecating the Block Download feature in Xray between April and November 2026. Thousands of organizations worldwide run their software supply chain through JFrog’s platform, so a change to how Xray behaves affects a large share of code actually shipped.

    Xray keeps scanning and flagging vulnerabilities, but it loses the power to act on what it finds. Curation, licensed and priced on its own, per seat, evaluates a package’s metadata, including its age and publisher and blocks it at the gate if it fails policy.

    Set the commercial questions aside and look at the architecture. A move such as this demonstrates the widely shared conclusion that enforcement belongs at the gate, evaluated before a package downloads, not scanned for after it has already been installed. It is a clear signal about where the whole category is going.

    The question it leaves open is more interesting, and it is the one renewal conversations should actually be about.

    Everyone Will Enforce at the Gate: What’s Left to Decide?

    When gate-based enforcement becomes table stakes, the differentiator narrows to two architectural decisions beneath the enforcement point: who owns the policy decision, and where does it physically run?

    These questions matter because the timeline has changed. Maintainer-account takeovers and self-propagating worms already compromise packages faster than catalog updates or ticket queues can move. The next wave of consumers pulling those packages is autonomous agents installing dependencies with no human in the loop, at whatever speed their compute allows. Both questions lead to the same conclusion: enforcement has to live on the wire, evaluated the moment a request is made, and the policy behind it has to be something the customer controls and can change in seconds.

    Who owns the security policy? In JFrog Curation, policy lives inside JFrog’s own catalog and UI. Cloudsmith takes a more open approach, letting customers write policy as Rego, genuine policy-as-code, with the code executing inside Cloudsmith’s hosted platform. Either way, the vendor’s platform has to be there for the policy to run: JFrog holds the policy itself, Cloudsmith holds where it executes, but neither lets you take the policy elsewhere.

    Where the decision executes is a separate question. Socket, Sonatype’s Firewall Pro, and Veracode’s Package Firewall all answer the question differently: front whatever registry a customer already runs, no platform migration required. But those decisions call out to a SaaS API before a build can proceed. Neutral about which registry you use; but not the same as portable if it depends on the vendor’s cloud.

    Portability also breaks for a reason that has nothing to do with outages. Post-merger and post-acquisition, it is common for a large organization to find Artifactory running in one business unit, Azure Artifacts or Nexus in another, and GitHub Packages somewhere else again, not through any deliberate choice. A policy engine welded to one platform enforces consistently on the traffic that platform sees, and leaves a different, weaker posture everywhere else. Universal compatibility, the same policy applied across whatever registries an organization runs, should itself be table stakes, the only way a security policy can mean what it claims to mean.

    So we see two trade-offs across the software supply chain security ecosystem. Deep tooling in exchange for platform lock-in. Registry neutrality in exchange for external cloud dependency.

    Both trade-offs carry a third cost: developer friction. Developer friction and developer buy-in are two sides of the same coin. JFrog’s own release notes cite CLI timeouts and silent failures as a reason for its own product change. When a vendor admits that a security control developers cannot predict is a cost worth fixing, that’s something to listen to.

    Policy written as code and kept in Git is an ownership question, but it is also a friction question. A change a developer can read as a pull request is one they can trust, while a change that arrives as an opaque update is not. Shipping a new policy in report-only mode before it blocks anything is the same instinct in a different form: nothing kills a developer’s willingness to work with a security control faster than a rollout that breaks a build.

    JFrog, and others, are moving blocking out to the edge, to the point where a request first meets a registry, before anything downloads. That is exactly where Varnish already sits, and has sat for two decades of caching traffic at the edge of other people’s infrastructure. Varnish Artifact Firewall is the position in this market that keeps both the policy decision and the place it runs with the customer, the direct consequence of taking the two questions above seriously.

    Policy is written as Git-native YAML, with a last-known-good fallback if the policy source itself becomes unreachable. It sits in front of the registries a customer already runs rather than replacing them, so adopting it is not a migration, and it works across whichever combination of registries a given organization happens to have accumulated. It is stateless and self-sufficient enough to deploy and scale without professional services, and because it runs in-process, the decision happens before a package downloads, with no round trip to distant clouds.

    Quarantine is the mechanism underneath all of this. A newly published version is held back for a set window before anything is allowed to depend on it, hidden rather than deleted, giving time for a problem to surface before a build can reach it. What happens next depends on what the request asks for. An unpinned request for the latest version resolves to the newest version that has cleared quarantine, so a build that never depended on the held-back version keeps working without ever knowing it existed. A pinned version is designed to pass through as a deliberate choice, not silently overridden. A request that fails policy outright, not just time-held, is denied, and returns a clear error and an audit entry rather than a silent failure. Before any of this reaches enforcement, a policy can ship in report-only mode, logging what it would have quarantined or blocked without acting on it, so a team can see the real impact before switching it on. Each of those outcomes, held, resolved, denied, or simply logged, is visible to the developer at the point it happens, which is what developer control looks like in practice

    Attacks almost never carry a CVE while they’re still active, the community catches them first, flagging malicious versions on databases like OSV.dev within hours to days of publication, well before any CVE gets assigned. Varnish pulls updated rules from OSV.dev automatically, every hour, so a quarantine window is built on a source that is already catching the important details. Other ruleset sources are being added to widen that coverage further.

    What This Means Before the XRay Deprecation

    The case that JFrog makes for gate-based enforcement is effective enough and shows that it is no longer a competitive differentiator but a baseline. What is left for a customer to decide is not whether to enforce earlier, but who writes the rule and whose infrastructure it runs on, and the risk driving that decision is only accelerating. A deprecation deadline is forcing that decision for Xray customers specifically, but the underlying choice is the same one facing anyone in this category: keep paying a vendor, per seat, for a decision made on their platform, or own the policy, and the infrastructure it runs on, yourself.

    https://www.varnish-software.com/

  • Why DNS Needs to Be Treated as Critical Infrastructure

    Why DNS Needs to Be Treated as Critical Infrastructure

    DNS is one of those infrastructure components that only gets attention when something breaks, and by then, the damage is already done.

    An application may appear healthy, servers may be reachable, and network connectivity may show green across the board. However, users cannot get in, and the on-call engineer is staring at logs trying to figure out why. Twenty minutes later, someone checks DNS and finds a record pointing to a decommissioned server, a zone that stopped syncing three days ago, or a TTL change that was made too late to matter.

    DNS connects applications, services, cloud workloads, email, identity systems, and much of the infrastructure underneath them. Yet, DNS is often managed like an afterthought. No formal change process, clear ownership, or tested failover. Just a DNS server humming quietly for years, trusted because it has not failed yet.

    That trust is the problem.

    A DNS Change Is an Infrastructure Change

    A single record edit can have a wide blast radius. Changing an A record affects application accessibility. A wrong MX record can disrupt mail delivery for an entire domain. An incorrect NS record can break resolution for every hostname in a zone. Also, the impact of a bad change can persist long after the mistake is corrected because DNS responses are cached.

    Most teams understand this conceptually, but DNS changes still often happen outside any formal change-management process because the tool makes it too easy to edit a record and move on.

    Before touching a critical DNS record, the team should know what it currently looks like, which systems depend on it, and exactly how to roll it back. TTL deserves particular attention here. Dropping a record’s TTL immediately before a change does not help because resolvers have already cached the old value. TTL needs to be lowered in advance, with enough lead time for existing cached responses to expire.

    After the change, validation should go beyond confirming the update on the primary server. Secondary servers need to be checked. Resolution should be tested from the networks that actually matter.

    A button to make a change is not a process. DNS needs a defined change life cycle.

    Redundancy That Has Never Been Tested Is Not Redundancy

    Most organizations have a secondary DNS server. Many assume that is enough. But it is not.

    A secondary server only provides meaningful redundancy when it is actually synchronized and capable of answering queries on its own. Zone transfers can silently fail. Secondary servers can fall behind by hours or days without anyone noticing. Also, placing the primary and secondary on the same underlying infrastructure, such as the same cluster or network segment, provides no real protection if that infrastructure goes down.

    The same problem exists with recursive resolvers. When clients are configured to use a single resolver, even a brief DNS issue can become a broad availability problem.

    Real redundancy requires verified synchronization, independent infrastructure, and, most importantly, regular failover testing. If the team has never intentionally taken the primary server offline and confirmed that resolution continues, then the redundancy is theoretical.

    DNS Drift Is Slow, Then Sudden

    DNS zones do not become inaccurate all at once. They drift.

    A server gets decommissioned. The A record stays. An IP address gets reassigned to a different host. The PTR record still points to the old one. An application migrates to a new platform. The CNAME record is never cleaned up.

    Each of these is a small gap. Collectively, they create a DNS environment that no longer reflects what is actually on the network. That gap can cause real problems when IP addresses are reassigned. A client following a stale A record may no longer reach the intended host. Worse, if that IP has since been reassigned, the request could end up at an entirely different system.

    Keeping DNS records accurate is not glamorous, but it matters. Zone data should be compared regularly against IP address assignments, DHCP leases, and asset inventories. In dynamic environments, integrating DNS with DHCP and IP address management reduces the manual effort of keeping records accurate. If DNS, DHCP, and IPAM data are siloed, that gap will keep widening.

    Access Control Is a DNS Reliability Problem

    Giving too many people write access to DNS is an operational risk, not just a security one.

    An accidental deletion in the wrong zone, a typo in a critical record, or a zone transfer restriction quietly removed. All these are not hypothetical scenarios. They can happen in environments where DNS administration has no clear boundaries.

    The principle of least privilege applies here. Engineers who need DNS visibility for troubleshooting do not need permission to modify records. Teams responsible for specific services should have access scoped to the zones they own, not the entire DNS namespace. Zone transfers should be restricted to explicitly authorized secondary servers. Recursive resolvers should not be open to the internet.

    These controls make DNS configurations harder to change unexpectedly and that is the point.

    The Real Problem Is Consistency

    There is no single DNS architecture that works for every organization. Internal zones, external services, cloud workloads, and hybrid environments each come with their own requirements.

    What matters is managing all of it consistently.

    That means clear zone ownership, documented naming conventions, defined change procedures, tested recovery processes, and enough visibility to understand how DNS connects different parts of the infrastructure. It also means that as organizations adopt more automated infrastructure, where deployments happen in minutes and IP addresses change constantly, DNS cannot remain a manual process tacked on at the end.

    DNS does not have to be complicated. It does, however, need to be taken seriously.

    When DNS changes are planned, validated, monitored, and governed with the same discipline as the rest of the stack, DNS becomes far less likely to be the hidden cause behind an application or infrastructure problem. That is what treating DNS as critical infrastructure really means.

    Final Takeaway

    DNS may stay in the background, but its impact extends across modern infrastructure. As environments become more distributed, DNS needs the same discipline as the rest of the stack, with controlled changes, tested resilience, clear ownership, and consistent visibility.

    This is where a unified view of DNS and IP address data can make a practical difference. Platforms such as ManageEngine OpUtils bring DNS management together with IPAM and DHCP visibility, allowing teams to correlate DNS records with current IP assignments and investigate inconsistencies without switching between separate management tools. OpUtils supports DNS management across Microsoft DNS and AWS Route 53, making it useful for organizations managing both on-premises and cloud DNS environments.

    Learn more: OpUtils DDI management capabilities

  • Speeding Up Software Delivery Is Changing How We Debug Performance

    Speeding Up Software Delivery Is Changing How We Debug Performance

    Deployment frequency has become one of the clearest markers of a mature engineering organization. Teams that once shipped monthly now ship daily, and teams that shipped daily now ship several times a day. This shift has largely delivered on its promise. Smaller changes are easier to reason about, rollbacks are faster, and feedback loops are shorter.

    What has received less attention is the effect this same shift has had on the practice of debugging performance issues. Several assumptions that previously held, a stable release to compare against, a known change set behind a given incident, sufficient time between deployments to observe a system before the next one lands, no longer apply in the same way.

    A Moving Baseline

    Performance debugging has traditionally depended on comparison. An engineer examines current behavior against a known good state, typically the previous release, and narrows down what changed. This approach works well when releases are infrequent enough that the previous release remains a stable, well understood reference point.

    When deployments occur several times a day, that reference point moves continuously. A regression noticed in production may trace back to any one of a dozen deployments merged since the last time someone reviewed that code path closely. The regression itself is genuine, but the comparison method that once made it straightforward to isolate no longer has a single fixed point of reference.

    This does not indicate that frequent deployment introduces more performance issues. It indicates that the traditional method of identifying them, comparison against a known baseline, becomes more difficult to apply as the baseline itself becomes a moving target.

    Smaller Changes, More Difficult Attribution

    A related effect occurs at the level of individual changes. Smaller, more frequent deployments are generally easier to review and easier to roll back. However, when a performance issue surfaces days after a change was merged, rather than immediately following it, attributing the issue to a specific change becomes a process of elimination across many small deployments rather than an inspection of one larger one.

    A single large release makes attribution simpler in one way, since there are fewer candidates to consider, but harder in another, since each candidate is larger and more complex to inspect. Frequent small releases invert that trade off. Each individual change is simple to review, but the number of candidates behind a delayed symptom grows quickly, and a minor dependency update or an altered query parameter buried in a routine pull request is just as capable of causing a regression as a larger architectural change.

    Neither approach removes the underlying difficulty. It appears in a different form depending on how a given team ships.

    Where Transaction Level Visibility Applies

    This is where visibility at the transaction and code level becomes relevant, not as a substitute for deployment history, but as a means of observing what actually occurred at runtime, independent of which release introduced it. A trace showing precisely which method, query, or downstream call consumed the time for a specific slow request does not require prior knowledge of which deployment caused the issue. It identifies the issue directly, within the transaction in which it occurred, whether that turns out to be an unindexed query, a retry loop against a failing dependency, or a serialization step that grew more expensive as payload sizes increased.

    This changes the starting point of an investigation. Rather than beginning with an assessment of which among several recent deployments caused a given issue, an engineer can begin with a direct account of where a specific request spent its time, and work backward toward the change that introduced it, informed by observed behavior rather than elimination alone.

    Dependency mapping serves a similar function at a structural level. As services are deployed and redeployed independently of one another, understanding which services actually call which, based on current behavior rather than the architecture as documented at the last major review, becomes part of maintaining visibility that keeps pace with the system itself.

    Delivery Speed and Diagnostic Speed Are Separate Measures

    It is worth being precise about what deployment frequency actually measures. It measures how quickly a team can move a change into production, a genuinely useful indicator of process maturity. It does not measure how quickly that same team can diagnose a performance issue once one appears in production.

    These two measures can move independently of one another. An organization may improve deployment frequency substantially while diagnostic time remains unchanged, or even increases, if the practices used to investigate performance issues have not kept pace with how frequently the system now changes. Improving one without corresponding attention to the other tends to produce a team that ships quickly and then spends a disproportionate share of that gained time identifying what went wrong afterward, which is a cost that rarely shows up in delivery metrics themselves.

    Keeping both measures aligned generally requires treating runtime visibility as something that keeps pace with deployment frequency itself, present for every service from the point of deployment, rather than something introduced after a service has already accumulated a performance issue worth investigating.

    Where This Leads

    The practices that enable faster software delivery and the practices that make performance issues easier to diagnose are not inherently aligned. The two require deliberate coordination. This typically involves treating transaction level tracing as part of how a service is deployed, rather than as a separate concern addressed later, so that the same velocity built into shipping code remains available when investigating what that code actually does once it is running. OpManager Nexus provides a 30-day free trial for teams that want to see this kind of transaction level visibility applied to their own environment.