Tag: devops

  • Red Hat Woos Corporate Developers with Free Instances of RHEL

    Red Hat Woos Corporate Developers with Free Instances of RHEL

    Red Hat today launched an initiative intended to make a free distribution of Red Hat Enterprise Linux (RHEL) available to individual developers working within a corporate environment.

    Chris Wells, senior director of product marketing for RHEL, said the Red Hat Enterprise Linux for Business Developers program will reduce the level of friction that developers of corporate applications might otherwise encounter.

    Red Hat already has a long-standing developer program that is structured around organizations rather than individual developers. Rather than needing to become part of a program set up by an internal IT organization in collaboration with Red Hat, the Red Hat Enterprise Linux for Business Developers program provides application developers with direct access to a repository through which they can download up to 25 physical, virtual or cloud-based instances of RHEL. Previously, Red Hat also made available a free personal RHEL license option to application developers.

    The overall goal is to not only encourage developers to build applications using RHEL but also reduce the level of friction that might occur when applications are deployed in production environments that are based on RHEL, said Wells. Otherwise, a DevOps team would have to migrate an application developed on another distribution of Linux to RHEL, he added.

    Red Hat now provides access to instances of RHEL that can be deployed using traditional package management tools or as an immutable container. That latter approach tends to especially appeal to individual developers who would rather rip and replace a set of containers versus trying to apply a patch each time a new RHEL update is made available, noted Wells.

    There are, of course, any number of additional commercial services that application developers can also subscribe to if needed, he added.

    As always, there is an ongoing battle for the hearts and minds of application developers. In the wake of changes made to how Red Hat makes its offerings available to organizations, Red Hat is now clearly trying to make sure that application developers are able to build applications on top of its operating system without incurring any cost.

    It’s not clear how many application developers are building software on top of RHEL, but should application developers opt for a different operating system, Red Hat is concerned those platforms might one day supplant RHEL in production environments. Red Hat is also hoping that DevOps teams will encourage developers to build applications on top of RHEL to streamline application deployments.

    Regardless of motivation, making it possible for application developers to self-service their own for building applications is generally a good thing as long as it complies with existing corporate standards. The challenge is that many application developers when it comes to tooling have a lot of personal preferences that often fall outside the scope of those standards.

    Each organization will, naturally, need to determine how much freedom of choice they want to provide application developers, realizing, of course, that most of them have the resources and skills required to set up their own application development environments. Fortunately, it’s also not too long before most of those developers also conclude they would prefer to have somebody else manage those environments on their behalf.

  • The Hidden Threat of API Sprawl Beyond the Gateway

    The Hidden Threat of API Sprawl Beyond the Gateway

    APIs power everything beyond just carrying data, from allowing higher-order software applications and improving customer experiences to engineering efforts and internal operations. But beneath this surface of innovation lies a growing, often unacknowledged challenge—API sprawl.

    This phenomenon describes an ever-expanding collection of APIs that outpaces an organization’s ability to effectively track, manage, and secure them, leading to a tangled digital infrastructure where visibility is lost and control becomes elusive.

    At the heart of API sprawl are shadow APIs and zombie APIs. Shadow APIs operate completely off the radar, often undocumented and unknown to security teams, meaning no security reviews or vetting ever take place. Zombie APIs are those that should have been decommissioned but remain active, often forgotten after a new version or service replaces them. In both scenarios, these endpoints exist outside normal oversight, making them prime targets for exploitation. But the implications of this sprawl extend far beyond mere operational untidiness, posing significant and often underestimated security risks.

    One common misunderstanding among tech leaders when talking about API sprawl is failing to grasp its deeper, strategic liability. It’s more than just a “messy” IT landscape; it’s a fundamental obstacle that can block critical strategic initiatives like AI transformation. Leaders might overlook that their extensive API investments could be effectively invisible to AI systems due to inconsistent documentation, inaccessible specifications, and incompatible implementation patterns—a phenomenon some call the “AI accessibility paradox.”

    And this reliance on tribal knowledge rather than clear visibility can also lead to skyrocketing infrastructure costs and an unknown security posture that keeps leadership awake at night.

    The Limits of Traditional Visibility (Gateways & Catalogs)

    Many organizations believe they have a handle on their API landscape by relying on API gateways and manually maintained spec catalogs. While these tools are undoubtedly valuable and serve crucial functions, they often present an incomplete picture, missing a substantial portion of an organization’s actual API estate. These traditional methods typically only capture APIs that are actively managed, documented, and exposed through the gateway, leaving significant blind spots.

    The reality is that a considerable percentage of an organization’s API landscape—including internal, legacy, and in-development APIs—is typically missed if visibility relies solely on conventional tools. Because these overlooked APIs often reside in code repositories, operating completely off the radar, unseen by security teams, and often undocumented.

    And this gap means that even well-intentioned efforts to secure and manage APIs fall short, as a significant portion of the attack surface remains unknown and unmonitored. For instance, nearly a third of API publishers today use multiple gateways, which further fragments visibility and makes comprehensive API discovery and observability even harder. Effective API security, therefore, transcends mere management; it begins with deep discovery, moving beyond the superficial view offered by standard gateways and catalogs.

    Danger Lurking in the Code

    A significant portion of an organization’s API landscape often lives hidden within code repositories, never seeing the light of formal management or security review. These are the APIs that developers may spin up for internal use and then forget, or older APIs that are never properly decommissioned. These endpoints, including shadow APIs and duplicated internal services, pose critical risks.

    One of the most significant dangers is the creation of security vulnerabilities. APIs lurking in code repositories are often completely off the radar, meaning they are never tested, monitored, or patched. Because this leads to wildly inconsistent security postures, where critical controls like proper authentication, authorization, and input validation are easily missed.

    An unvalidated input, for instance, can lead directly to severe vulnerabilities like SQL injection. These hidden APIs can become conduits for exposing sensitive data, even if not explicitly “vulnerable” in the traditional sense, simply by virtue of being accessible and unmonitored. They can be exploited using stolen credentials, leading to data leakage or injection attacks, or may bypass newer security measures implemented elsewhere.

    Without a complete and up-to-date API inventory, security teams operate with blind spots, undermining threat modeling, weakening incident response preparedness, and leading to ineffective controls.

    Beyond security, these hidden APIs contribute to operational instability and wasted resources. Developers spend a surprising amount of time simply trying to figure out what APIs exist, which ones are safe to use, and whether the documentation is up to date – if it even exists. And this lack of clarity leads directly to duplicated work, brittle integrations, and excessive firefighting, killing momentum and slowing development velocity. Teams might spend half their time just discovering and understanding existing APIs before beginning new development.

    The frustration is palpable, turning regular development into “detective work.” For example, building a seemingly simple third-party integration can mean bouncing between multiple code repositories and numerous outdated or undocumented API files, just to start writing tests. This overhead pushes feature delivery late and drags hotfixes into future sprints.

    This environment also fuels “dependency hell,” where unchecked API sprawl creates a cascade of interrelated challenges like circular and nested dependencies, versioning inconsistencies, and authentication conflicts. Such complications have a quantifiable impact on development cycles, resulting in absurd local environment setup times, crushing machine resource requirements, and agonizing build and testing times.

    A single build issue can lead to hours or days of troubleshooting, sometimes even a complete rollback, which then requires starting from scratch. This severely damages project timelines and morale, creating an unproductive environment. The “if it works, don’t touch it” mentality often prevails, making it easier to implement new functionality than to modify existing, tangled APIs. This continuous toiling over sprawl creates an unseen cost that drags down an organization’s ability to innovate.

    The True Cost of Ignorance

    The technical friction and security vulnerabilities flaring up from API sprawl don’t remain confined to development teams; they swiftly translate into significant business consequences that impact the bottom line, reputation, and long-term innovation capabilities.

    Financially, the hidden costs are substantial. Organizations face skyrocketing infrastructure costs and hundreds of thousands of dollars in maintenance for unmanaged APIs. Developer inefficiency, due to wasted time on discovery and rework, directly impacts the bottom line, as slower development teams negatively affect output. Furthermore, excessive services running on developer machines or in remote development environments can bloat infrastructure costs. But beyond these ongoing drains, a single security breach stemming from an unknown or forgotten API can result in millions in losses and significant reputational damage.

    The inability to manage API sprawl hampers innovation speed and market responsiveness. Lack of visibility means leaders are constantly guessing about existing systems, dependencies, or stability, delaying everything from capacity planning to delivery forecasts. What might appear to be a two-week feature can easily turn into a month-long delay because an underlying API is undocumented, broken, or lacks clear ownership. This friction directly translates into slower time-to-market for new features and products, and a diminished capacity to respond quickly to evolving business needs. The overall impact on efficiency ultimately slows down innovation and prevents teams from delivering true business value.

    Moreover, the lack of API visibility creates significant compliance challenges. If an API is not properly documented or secured, fundamental principles of accountability, often enshrined in regulations like GDPR, are violated. Without knowing what APIs exist and what data they handle, companies cannot secure or comply with what they don’t know exists, leading to severe compliance breaches, especially if shadow or zombie APIs handle sensitive data without oversight.

    When a security incident does occur, perhaps exploiting one of these hidden APIs, the response is often doomed from the start. Lack of proper documentation means understanding what APIs have access to critical databases becomes a frantic, time-consuming effort. This drastically increases the time to mitigation, allowing attackers to continue causing damage and exacerbating the business impact. The inability to quickly respond to a high-impact API risk directly impairs an organization’s ability to deliver and maintain code in production.

    This confluence of API sprawl and the urgent pressure to leverage AI capabilities has revealed a critical bottleneck, escalating from a technical debt issue to an existential business challenge. Organizations that cannot consolidate and structure their APIs risk falling behind, as AI systems demand precision, discoverability, and composability to operate effectively. Without control over their API surface, businesses will struggle to enable automation, build copilots, or participate in AI-native ecosystems, putting both innovation and competitiveness at stake.

    Seeing is Believing

    The grim picture of hidden API sprawl—with its attendant security vulnerabilities, productivity drains, and escalating costs—underscores a fundamental truth: you cannot manage or secure what you cannot see. While traditional tools like API gateways and manually maintained catalogs offer a partial view, they inherently miss a significant portion of an organization’s true API landscape. A comprehensive understanding requires going deeper, directly into the source code repositories where APIs often live, undiscovered by conventional methods.

    For organizations looking to get a true handle on API sprawl, discovering APIs directly from source code repositories offers transformative benefits compared to relying solely on runtime observation or declared specifications. This deeper discovery enables the creation of a living, centralized inventory that combines documentation, real-time discovery, and regular validation, allowing teams to see what exists, what’s being used, and what’s safe to build on. This clarity immediately translates into improved efficiency and productivity. It frees developers from the endless cycles of rediscovery and reinvention, accelerating time-to-market by as much as four to ten times when APIs are properly cataloged and discoverable. Engineers can feel more confident and make faster decisions, no longer wasting valuable time hunting down information or rebuilding existing functionality.

    Beyond efficiency, this comprehensive visibility significantly enhances an organization’s security posture and helps enforce compliance by reducing the attack surface. It allows for the enforcement of security policies and API design best practices across the organization. When you know exactly which APIs are exposed, what data they handle, and who owns them, you’re not scrambling when a security or regulatory question arises. This transparency can even unlock the budget needed to tackle API sprawl effectively, as security becomes a key driver.

    Perhaps most pressingly, addressing API sprawl by achieving this deep visibility creates the foundational layer for successful AI integration by making business capabilities programmatically available. Developers can immediately use existing assets for new AI initiatives, eliminating the need to build integrations from scratch and significantly accelerating the development and deployment of AI agents. This builds up an environment where innovative technologies can be seamlessly integrated and scaled, giving organizations the precision, discoverability, and composability that AI systems truly require. This approach also leads to improved ownership and accountability, naturally reducing “shadow IT” by making APIs centrally tracked and accessible.

    From Hidden Threat to Managed Asset

    The journey to reclaiming control over your API landscape, transforming hidden threats into managed assets, begins with a fundamental commitment to comprehensive visibility. Understanding the “hidden” sprawl—those APIs living unseen in code repositories, beyond the reach of traditional gateways—is the indispensable first step to mitigating risks and significantly improving efficiency.

    For a CTO or Head of Engineering who suspects their organization is grappling with a significant, hidden API sprawl problem but isn’t sure where to begin, the advice is clear: start with discovery. An API’s security issue is fundamentally a discovery issue; once identified, it can be addressed. Begin by striving to document all APIs, gathering as much information as possible about every available API. A simple litmus test can reveal initial insights: how many APIs do you have, and how many are truly “well-documented” with up-to-date specifications in a usable developer catalog?

    To delve deeper, a thorough assessment of development operations, broken down by production, output, and infrastructure, can be highly revealing. Metrics like overall cycle time (including coding, review, build, and deploy phases) offer a window into efficiency and the likelihood of a sprawl problem. Furthermore, observing a team’s ability to rapidly scope, plan, and deliver new features, along with consistently hitting timelines for low-point agile stories, can clearly indicate the presence or absence of API sprawl.

    Beyond initial assessment, it’s crucial to “stop the bleeding.” This means pausing the creation of new APIs until clear policies are defined and consistently enforced. Each new API should be rigorously questioned: Is it truly necessary? Are there no existing APIs that can serve the same use case? By adopting this strategic pause and proactive questioning, organizations can begin to stabilize their API ecosystem before embarking on further growth. Ultimately, transforming hidden liabilities into strategic assets requires this commitment to seeing, understanding, and then managing every API.

    Consolidating Your AI Strategy

    The chaotic, unmanaged tangle of unknown and forgotten APIs creates a fertile ground for attackers, complicates compliance efforts, and can paralyze an organization’s response when security incidents do occur. This challenge, though significant, is not insurmountable.

    The path to reclaiming control hinges on a fundamental commitment to comprehensive visibility into your entire API landscape. This means moving beyond reactive measures to a strategic, proactive approach that identifies and manages every API, whether it’s exposed through a gateway or lurking unseen in a code repository. The organizations that successfully address API sprawl will gain a decisive competitive advantage in their AI transformation efforts, while those that do not will find themselves struggling with increasingly expensive and ineffective technology investments.

    By embracing the principles of deep discovery, strong governance, and embedding security proactively throughout the entire API lifecycle, organizations can begin to transform these essential connectors. APIs that were once hidden liabilities can become secure, strategic assets crucial for driving innovation, achieving operational efficiency, and fueling your company’s AI-powered future.

  • Bitrise to Invest $3M in DevOps Cloud for Mobile Apps in EU

    Bitrise to Invest $3M in DevOps Cloud for Mobile Apps in EU

    Bitrise, a provider of a DevOps platform for building mobile applications, plans to invest $3 million to create data centers in the European Union (EU) that meet sovereign cloud requirements.

    Company CEO Barnabás Birmacher said Bitrise has spent much of the past year integrating its stack and consolidating the infrastructure it needs to support its platform in the U.S. Now, Bitrise is taking the next step toward ensuring that any data used to build a mobile application doesn’t leave the EU at a time when many organizations are either voluntarily deciding to depend less on IT infrastructure in the U.S. or are being required to use IT infrastructure in a specific geographic region.

    To satisfy those requirements, Bitrise is acquiring the server and storage infrastructure it requires, which is then housed in a data center facility in Amsterdam that is owned by a third-party provider. That approach ensures that at any point necessary those servers and storage systems can be moved to another data center, noted Birmacher.

    Regardless of location, the data centers will be based on the same Apple M4 and Linux-based infrastructure that Bitrise has built a DevOps platform on top of to streamline the building and deployment of mobile applications.

    It’s not clear how fragmented software engineering is about to become as teams are required to ensure that application development projects only access data located in specific regions. Many DevOps teams have been relying on software-as-a-service (SaaS) application platforms that are designed to scale out across multiple geographic regions as additional compute resources have been needed. With the rise of sovereign cloud requirements, however, providers of those platforms need to ensure that any data being accessed never leaves a specific region.

    That issue can be especially challenging for organizations that may have relied on highly distributed teams of developers that may reside in multiple countries.

    In fact, one of the reasons more organizations are relying on the managed DevOps services that Bitrise provides is to help minimize that complexity, said Birmacher.

    As the pace of mobile application development continues to accelerate, more organizations are looking to rely on managed DevOps services, added Birmacher. They simply can’t afford to not only only build a DevOps platform, but also maintain, update and secure it, he noted. That’s especially the case when it comes to building mobile applications simply because there isn’t a lot of forgiveness when it comes to, for example, having to rollback an application once it’s been made available in an app store, so ensuring that every test has been properly conducted is crucial, said Birmacher.

    Regardless of who actually manages a DevOps environment, the need to continuously update mobile applications created additional challenges. End users expect that new features and capabilities will be added at a regular cadence. The number of organizations that can afford to invest in their own DevOps environment, as a percentage of those building mobile applications, remains comparatively small. So for the bulk of them, the only way to ensure best software engineering practices are being consistently followed is, after all, to rely on a service.

  • Automation Evolution: Is Your DevOps Ready for Tomorrow’s Innovations?

    Automation Evolution: Is Your DevOps Ready for Tomorrow’s Innovations?

    Let’s dive into a topic that’s constantly buzzing in our industry: DevOps pipelines. We’ve all experienced the incredible transformation DevOps brought, dismantling silos and accelerating software delivery. But here’s a critical question for 2025 and beyond: Is your pipeline evolving?

    This is critical to understand because, without you realizing it, your DevOps pipeline might be stuck in the paradigms of its early successes. In a world continually upping the game in agility and continuous innovation, even “traditional” DevOps workflows are starting to reveal strains. The underlying challenge? Often, it’s the need for a more profound, intelligent, and integrated approach to automation.

    Many organizations, despite their DevOps use, still wrestle with nagging inefficiencies. Think about siloed teams creating friction; manual processes, in critical stages like testing and deployment, inviting errors; or overly cautious approaches to release due to stated or unconscious fears of instability. These can lead to slower cycles than the business demands, and mounting pressure on development teams. Add in the common scenario of “tool sprawl,” a patchwork of disconnected tools that have naturally grown over time and that complicates workflows rather than simplifying them.

    Sound familiar? The truth is that the goalposts for software delivery haven’t just moved; they’re in constant motion. Digital transformation isn’t a project; it’s the new baseline. Businesses are compelled to harness cutting-edge technologies, with AI-driven automation becoming less of a futuristic vision and more of a present-day necessity to achieve speed, efficiency, and a sharper competitive edge. Security, too, can no longer be a checkpoint; it must be woven into the very fabric of the development lifecycle from the first line of code. To navigate this complex, high-stakes environment, traditional pipeline thinking—while revolutionary in its time—needs to evolve.  

    The Next Leap: Intelligent Automation for a Modern Pipeline

    So, how do we bridge the gap? The answer lies in a new generation of intelligent automation that’s holistic, adaptive, and deeply integrated. This isn’t merely about scripting. It’s about reimagining the entire software delivery value stream using a new source of power: smarter, more connected automation.

    Imagine a world where your development and operations teams aren’t just collaborating but are empowered by a unified platform that provides shared visibility, streamlines handoffs, and automates the mundane. This is where the true power of modern DevOps comes to life. By intelligently automating testing suites, build processes, and deployment strategies (think canary, blue-green), you not only accelerate delivery but also drastically reduce human error and mitigate release risks.  

    One of the biggest game-changers is the ability to gain end-to-end visibility and actionable insights. Modern automation platforms can offer real-time analytics across the entire delivery lifecycle. This means identifying bottlenecks before they become major roadblocks, optimizing resource allocation, and making data-driven decisions to continuously improve performance. When AI is layered on top, teams can even leverage predictive insights or query project states using natural language, making complex data accessible and actionable for everyone.  

    Finally, let’s get back to that dreaded tool sprawl. The right automation strategy doesn’t necessarily mean throwing out everything you have. Instead, it’s about integrating and orchestrating your existing toolchain—Jira, Jenkins, Git, Kubernetes, and more—into a cohesive ecosystem to create a single source of truth and control, simplify management, and get the most out of your current investments.  

    Automation as the Engine of Innovation

    The profound impact of evolving your DevOps pipeline with intelligent automation goes far beyond just “doing things faster.” When you liberate your talented teams from toolchain complexities and repetitive manual labor, you unlock more of their potential to innovate and create value.  

    This shift translates directly into compelling business outcomes:

    • Accelerated Innovation Cycles: Respond to market changes with greater speed, roll out new features more frequently, and consistently delight your customers.  
    • Optimized Resource Utilization: Reduce costly rework, minimize unplanned downtime, and empower your teams to focus on strategic initiatives that drive growth rather than just keeping the lights on.  
    • Enhanced Quality and Reduced Risk: Embed security and compliance throughout the lifecycle. Proactive governance and consistent, auditable processes significantly reduce the risk of production failures and ensure you meet regulatory demands.  
    • Improved Developer Experience: High-friction, piecemeal internal platforms can frustrate engineers. A well-architected automation approach provides a smoother, more productive experience, boosting satisfaction and retention. An advanced DevOps platform can even serve as the core foundation for organizations building their Internal Developer Platforms (IDPs), providing a robust “starter kit” that accelerates IDP initiatives while allowing for tailored expansion.  

    Are You Ready to Evolve?

    The DevOps landscape is in a perpetual state of change. The pipelines that served us well yesterday may become the bottlenecks of tomorrow if they don’t evolve. Embracing intelligent, AI-driven automation isn’t just a trend; it’s a strategic imperative for any organization looking to thrive in the Digital+ Economy. It’s about building a resilient, adaptive, and innovative software delivery capability that’s ready for whatever comes next.

    Perhaps it’s time for a candid look under the hood. The question isn’t just if DevOps pipelines need to evolve with automation, but how quickly and intelligently your organization will lead that charge. Consider this an invitation to critically evaluate your DevOps pipeline. Where are the bottlenecks? Are your automation strategies keeping pace with what’s possible? A thorough self-assessment can illuminate the path to unlocking new levels of productivity and innovation.