devopsy.kinsta.cloud

Category: Enterprise DevOps

  • SCA, SBOMs and Floodgates

    SCA, SBOMs and Floodgates

    Two criteria are used to determine pervasiveness of a new idea. Availability of an easy-to-understand solution and customer need. Given both of these items, what might be a market-differentiating feature available in a single IT/DevOps market becomes a wave of options in multiple markets that an organization can (and should) choose from.

    What started this off? Well, I’ve been working in areas that involve expansive use of open source. This is pretty much to say, “I’ve been working in IT,” at this point, but that’s a different blog. The thing is, today, working with open source implies a complex software infrastructure that, traditionally, no one actually had a handle on. What is directly included in that project? What is indirectly included in that project?

    But then we had some pretty stellar security issues related to commonly-used open source. And we had commonly-used programming language modules pulled out from under hundreds of thousands of applications. Then we started paying attention. Or, more accurately, then we finally set out to fix a problem we’d been ignoring.

    This market is a bit confused by different use cases and the fact that there are two toolsets to achieve what IT sees as one job. So let’s talk about the complexities, just for clarity. First off, a software bill of materials (SBOM) is the list of what is included in a software project. The complexities here are twofold. From a programming perspective—meaning tools designed to be used by programmers during development—“included” means libraries, modules, etc. that the application calls on to do what the organization needs. These are “included” in the build process. From a systems perspective, “included” means everything installed on the image when it goes to production. These are similar but very different lists. The developer list is a subset of the production list because all of the items in the development list are included in production, but the production list will have other software that is used to support the developed application. Think of the application having all of its libraries and modules, but assuming SSL termination will be there. Because it will. In the image. That’s the difference. Many products have had an internalized version of SBOM for years now—developer security tools and release scanning tools pretty much require a list of everything they need to scan. But few made these lists public, and many tools did not have them.

    Software composition analysis (SCA) takes the SBOM and adds value. While a list of everything included is useful, a subset that lists everything that’s actually used is more to the point, for example. So is a list of flaws found in included libraries/packages and suggestions on how to address them. This can be done from either the source or production SBoM side, depending upon implementation.

    Once the value of both tools was made clear—and implementations existed that showed both how to implement them and what the benefits were—the floodgates opened. Now there are few DevOps or security tools that do not offer one or both of these features. That gives us an embarrassment of riches. Which tool(s) do we use for compliance and security review? As we do with data, I’m going to suggest that a single product is chosen as the “source of truth” and run with. At this time, I do not have suggestions on which ones are better for this purpose, just a suggestion that if you use different ones for different purposes you are likely to get different results, and that isn’t going to help simplify things at all. So, look at the ones you already have access to—they’re in enough products that you likely have more than one available in your existing infrastructure—and make it your standard.

    Then, use that standard to help monitor use of open source. Monitoring can help with open source licensing, with application and infrastructure security, with image simplification and with compliance. So strip unused packages out of images and clean libraries that are no longer called out of your build process. Respond to issues faster, and keep that application infrastructure you’ve been nursing along humming. And keep kicking it; your users should appreciate it, even if they do not.

  • EvolveWare Further Automates App Modernization Tasks

    EvolveWare Further Automates App Modernization Tasks

    EvolveWare today announced it has added an Agile Business Rules Extraction capability to its Intellisys application modernization platform.

    EvolveWare CEO Miten Marfatia said the Agile Business Rules Extraction capability eliminates the need to freeze code development while applications are either being shifted to the cloud or refactored. Instead, the Intellisys platform will now keep track of updates to code and apply them once the application has been modernized, he said.

    Code updates can now be transferred automatically into the extracted business rules repository without affecting the rules that are not impacted by the updates. For rules impacted by the updates, a report is generated that highlights the changes. IT teams can now also update business policies and modernize applications concurrently via the repository that also keeps track of documentation such as diagrams, logic, database details and critical dependencies, said Marfatia.

    In addition to presenting logic in multiple formats, including pseudo-code, flowcharts, decision tables and business analyst language, it enables consolidation and optimization actions to be reverted to their original state if required.

    In general, IT teams have been struggling with application modernization efforts that require them to either lift and shift a monolithic application running in an on-premises IT environment into the cloud or refactor it into a set of microservices that run natively in the cloud. Eventually, most organizations will refactor monolithic applications, so the debate becomes to what degree to undertake those efforts before lifting and shifting an application into the cloud. Most monolithic applications were not designed to run in the cloud, so when the app is shifted it’s not uncommon for any number of performance issues to be encountered.

    EvolveWare claims that its Intellisys platform reduces the cost of application modernization by as much as 60% by eliminating much of the manual effort that would otherwise be required. Modernization efforts, in general, are hindered by manual processes that should be automated, said Marfatia.

    The issue that most DevOps teams encounter when modernizing an application is that it is not a task they regularly perform. As such, many of the processes required have not been automated with the same level of zeal they’ve applied to more routine manual tasks. The Intellisys platform is designed to enable IT teams to automate the most common tasks associated with migrating an application to another platform.

    The biggest driver of those migrations these days has been digital business transformation efforts that have accelerated since the start of the COVID-19 pandemic. Organizations of all sizes are moving applications to the cloud to ensure greater availability and resiliency to limit the amount of disruption that might be encountered should the pandemic worsen, or in case some other unexpected event makes accessing IT services difficult.

    The challenge, of course, is moving applications—and the database they depend on—from one platform to another is not easy. It can take some organizations months, sometimes even years, to make the transition. Given the backlog of applications that many organizations are looking to migrate to another platform, it’s clear there is a need for much higher levels of automation to accelerate a transition that, on its present trajectory, might take years to complete.

  • Dynatrace Adds Grail Data Lakehouse to Observability Platform

    Dynatrace Adds Grail Data Lakehouse to Observability Platform

    Dynatrace today announced it has added a data lakehouse, dubbed Grail, to the Dynatrace Software Intelligence Platform to make it simpler to aggregate all the observability data an IT team collects.

    Bob Wambach, vice president of product marketing for Dynatrace, said Grail will initially drive analytics of log data but in time will also be applied to additional types of application development, security and business intelligence data.

    The goal is to streamline processes such as data indexing and rehydration across a unified observability platform that eliminates the need to maintain multiple disparate repositories, he added.

    Grail, at its core, is a causational data lakehouse based on a massively parallel processing (MPP) analytics engine that will initially be made available on the Amazon Web Services (AWS) cloud. IT teams can use the Dynatrace Query Language (DQL) to query data stored in the data lakehouse. Additionally, the Davis artificial intelligence (AI) engine that is already embedded within the Dynatrace Software Intelligence Platform will be able to apply machine learning algorithms to the data stored in Grail.

    Data lakehouses have recently emerged as an approach to enable organizations to apply the structure of a data warehouse platform to massive amounts of data that previously would have been stored in a data lake. In effect, a data lakehouse combines the attributes of both types of platforms for centralizing the management of data. One of the biggest issues with any approach to observability is the massive amount of data that winds up being stored to allow DevOps teams to track issues over time.

    Of course, it’s up to each individual IT team to determine how much data they want to save to drive analytics, but the more data they save the more cloud storage costs will naturally increase. Grail provides a purpose-built means of consolidating data silos in a way that reduces the total cost of observability, noted Wambach.

    In general, because of the need to embed a data lakehouse capability, most observability platforms will be consumed as a software-as-a-service (SaaS) application. That means the number of IT teams that will likely build and maintain their own observability platform will be limited. IT teams are also now struggling to manage increasingly complex IT environments made up of both cloud-native applications built using microservices and legacy monolithic applications. In fact, a global survey of 1,303 CIOs and senior IT practitioners commissioned by Dynatrace found 71% of respondents believed the explosion of data produced by cloud-native technology stacks is beyond the ability of IT staffs to manage without help from an AI platform.

    It’s not clear how quickly IT teams will be migrating from legacy monitoring tools that are designed to track specific metrics to observability platforms that promise to make it easier to identify the root cause of an issue by simplifying the launch of queries against a massive pool of data. However, as organizations continue to become more dependent on software, it’s apparent that the level of tolerance for any kind of disruption is steadily declining; it’s now more a question of when rather than if a different approach to managing IT will be required.

  • Five Great DevOps Jobs Opportunities

    Five Great DevOps Jobs Opportunities

    devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort 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 creates 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 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

    Level Home
    Redwood City, California
    DevOps/SRE Manager
    $175,000 to $275,000

    Monster.com

    Jobot
    Houston, Texas
    Senior DevOps Engineer
    $150,000 to $180,000

    LinkedIn

    Lenovo
    Colorado, New York City, Nevada and Washington
    Software DevOps
    $125,000 to $145,000

    SimplyHired

    Spring Health
    New York, New York
    DevOps Engineer
    $110,000 to $150,000

    Dice.com

    Black Knight, Inc.
    Remote
    DevOps Engineer III
    $91,000 to $125,000

  • CloudBees Acquires ReleaseIQ to Advance DevOps Orchestration

    CloudBees Acquires ReleaseIQ to Advance DevOps Orchestration

    CloudBees announced today it has acquired ReleaseIQ, a provider of an orchestration platform for automating software delivery via a software-as-a-service (SaaS) platform.

    Sacha Labourey, chief strategy officer for CloudBees, said the addition of ReleaseIQ to the CloudBees platform will provide more visibility into and control over software delivery on an end-to-end basis.

    CloudBees already provides a Flow orchestration engine within its continuous delivery platform. However, ReleaseIQ provides a similar capability across multiple continuous integration/continuous delivery (CI/CD) platforms using a SaaS platform that is more accessible.

    The ReleaseIQ platform is designed to enable DevOps teams to both create and maintain pipelines using a no-code tool. That enables greater transparency into workflows via dashboards that also provide optimization recommendations. That capability makes it much simpler to troubleshoot software deployments.

    Labourey said that while ReleaseIQ can be integrated with multiple platforms including CloudBees CI, Jenkins, CircleCI, GitLab, Bamboo, ArgoCD and others, the primary focus will remain on the open source Jenkins platform that still owns the lion’s share of the DevOps market. The overall CloudBees goal remains to employ automation and remove as much friction as possible from DevOps workflows as part of an ongoing effort to improve developer productivity, he noted. CloudBees, however, regardless of the level of DevOps maturity within any organization, is committed to meeting customers where they are versus requiring them to rip and replace existing investments, Labourey added.

    The overall level of DevOps maturity may vary widely both within and between organizations. However, as more organizations realize the extent to which they depend on software to drive digital business transformation processes, the need to further automate application development and delivery becomes more apparent. While CI is widely used today, the number of organizations that have consistently implemented CD is fairly limited. The underlying infrastructure that software is deployed on typically has a unique set of application programming interfaces (APIs) that each CD platform needs to support. Platforms such as ReleaseIQ provide a higher level of abstraction through which managing the pipelines that deliver software becomes simpler.

    In general, most organizations are trying to strike some level of balance between centralizing the management of DevOps workflows and enabling development tools to adopt whatever tools they prefer. It’s not uncommon for application development teams to independently adopt any number of tools that ultimately need to be integrated with a DevOps toolchain. Each of those tools, however, contains metadata that needs to be shared with a centralized orchestration engine that automates a range of tasks across multiple pipelines based on the metadata collected from each tool.

    There are, of course, still a lot of manual DevOps processes that should be automated. CloudBees is positioning ReleaseIQ as the orchestration engine for both unifying the management of pipelines and, ultimately. enabling value stream management across increasingly complex application development environments. It may take a while to fully realize that ambition, but with the acquisition of ReleaseIQ, a new foundation is being laid.

  • This Has Been a Test

    This Has Been a Test

    For nearly the entire history of application development—certainly since application development became available to a larger market with the adoption of the personal computer for expansive business use—testing has taken a back seat across most of the industry. This is not because we don’t care about code quality but because it takes resources away from developing cool new tools—or even products—and slows down release cycles. Historically, both of these issues have been huge. Manual testing staff grows quickly from a few people to a massive department and waiting for that process to complete could take forever.

    So, we’ve not done a lot of it. Oh, when executives or someone in leadership demanded more thorough testing, IT management would promise to do so and then—to fit within budget and time constraints—would tell developers to test their own code. There are several areas where you don’t ask the person responsible for creating the final product to review that final product—because if they knew they were doing something wrong, they’d fix it. Writing is one such area—that’s why good editors are worth their weight in gold, even in the age of the internet where anyone can (and too many do) spew onto the digital page whatever they like without the benefit of an editor. Another is testing application code. I test as I write my code, and like every person who has spent time as a professional developer, I have made a couple of stupendous errors. If I’d known that the particular weakness I left in the system was there, I would not have said it was done.

    When DevOps came along, I expected things to change—until I understood that DevOps (and Agile, in lockstep) was all about delivering faster, not better. Anything that slowed down the process—testing, security, even compliance, to an extent, that cannot be avoided—was frowned upon. When test-driven development (TDD) came along, I instantly developed a love/hate relationship with it. We used it for a project I was on and, frankly, it shifted quality concerns to the tests—the code could be forced to pass all of the tests, but how thorough and accurate the tests themselves were—particularly as the project grew and changed—became the question. Done right, TDD would solve a lot of our testing problems. Heck, even done wrong it would have taken care of most problems that simple unit testing could cover.

    But after decades, I think we are finally at the point where we can demand and require thorough testing with acceptable and growing coverage numbers. And you need to consider it. Test automation has come a long way and far too many of you haven’t come along with it. If you struggle to justify investing in test suites, I get it. I’ve been the manager that had to choose between improving DB performance and testing. But the modern iteration includes security testing. So if, out-of-the-box, you could get a  tool that checked for valid inputs and alerted to places where invalid data might break the application, that might help. And that’s just the simplest case. I’m currently working in an adjacent space, so I don’t want to get too crazy selling you here. I’ll just say, “Testing isn’t what it was even a couple of years ago. Check it out.” Both application and security testing. And the changes will continue to come as claims of using AI/ML turn into applying actual algorithms that your AI or data science people can compare to help choose a high-quality product.

    We could debate all day whether DevOps made apps more or less stable and secure, but we don’t need to. Finally, continuous testing is real. Check out the vendors doing this, compare them and see how easy it is to fit them into your environment. More stable, more secure, not the hold-up you have stuck in your head. What’s not to like? You are already rocking it; automated testing could make you look even better.

  • Wipro Fires 2-Job Staff | Python Bug from 2007 | Lite Layoffs

    Wipro Fires 2-Job Staff | Python Bug from 2007 | Lite Layoffs

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Wipro fires 300 for moonlighting at competitors, Python has a nasty 15-year-old bug, and companies are finding new ways to lay people off without calling it a “layoff.” (more…)

  • The Real Pipeline

    The Real Pipeline

    I’ve made no secret of the fact that DevOps was a game-changing advance in how the business of IT was done. But people tend to get religious about the methodology and forget the point. That’s okay, DevOps has its roots in that mentality. After years of thinking bad things about the authors of The Phoenix Project for portraying anything that slows the process–you know, like code quality or security–as bad, I have come to accept that absolutes were required to drive forward motion in the market. “We’ve always done it this way!” was king in IT, but the rest of the business was fed up. That book got the ball rolling and we’ve slowly but surely pushed back against the mentality that adding milliseconds (or even a week) to build times in the average enterprise has any impact worth mentioning. Oh, some people still claim it does, but we can convincingly make the code quality/security argument.

    It is funny to me that the first few years of DevOps were focused on “We’re gonna change your religion!”—wanting to force upheaval of the entire IT org chart without a thought to the fact that you still needed specialists in storage, ops, etc. to keep the lights on. The mentality was that development issues were a people problem. To a large extent, they were right; they just missed one people problem in the set of equations. Let’s look at the real pipeline that we all don’t talk about, but really should:

    Notice there aren’t tools in this chain; instead, there are groups of people. It is sad but true that the last two–representing acceptance testing and customer rollout–are almost always merged these days in all but a few organizations.

    This isn’t controversial; we still do the dev bit largely before the ops bit; the business has to decide what we want to offer the customer and customers are at the end of the line. And that is the key. Customers are at the end of the line. Now, I get to make you uncomfortable. Nothing in the above diagram matters except the first and last arrows. Think of it like this:

    What’s important in what we do comes down to two questions: “What does the business unit want to offer customers?” and “What do the customers expect of the business unit?” In this sense, “business unit” might be IT and “customers” might be co-workers. That changes nothing. What the business unit offers and what customers want is all that matters. The rest is implementation detail.

    Don’t believe me? It is an easy case to prove. Let’s try this one, with or without IT involvement, depending upon the problem being solved and the organization:

    The business unit determines what they want to offer, customers let their demands be known (one way or another) and the business offers the solution they think fits for the customers. As I said above, the rest is implementation details.

    What is your point?

    This leads me to the inevitable observation. Testing and security are:

    • Completely expected by users. They don’t want buggy software, and they don’t want to enter information assuming it will get nicked by hackers. There is no compromise here; users don’t “kind of want a product that works” nor do they want a product that “might be secure, but we’re not sure.”
    • Desired by the business. They have constraints on what is reasonable–the old meme of a server with the network cable cut is only funny because it shows extremes. But they absolutely do want the product or service they are offering customers to be stable and secure. “We can just spin out a new version” only works so often and for so long.

    So, your toolchains need to include stability and security tools—I would argue at every step of the process, but where and how much is really a business call. My security peeps will get upset that I called security a business call, but it is. You can choose to be non-compliant and insecure; the impact of those decisions on your organization is all on you. OTOH, of all the things that the organization (both the business generally and IT specifically) are focused on, you can afford to drop a few and get security and stability right the first time.

    Meanwhile, you’re keeping things running while we debate things like this. While I repeatedly refer to a large portion of my target audience as “implementation detail,” I’m sure you all know how much I (and many others) appreciate the rockstar job you’re doing keeping the IT org supporting the greater org.

  • To Build a Durable SaaS Business, Rethink Your Product Roadmap

    To Build a Durable SaaS Business, Rethink Your Product Roadmap

    During a tech downturn, with enterprises cutting their subscription software budgets and VC funding drying up, SaaS businesses are increasingly shifting their strategic focus from growth to resilience. 

    The standard startup playbook—hunker down, cut burn rate and hope the market improves before you run out of runway—isn’t the right path forward for SaaS businesses. Instead, the key to durability is to lean into efficient growth. By revamping their product strategy, companies can lower the cost of customer acquisition with low-touch onboarding strategies and also increase revenue retention with stickier products, helping to unlock new ways to scale up and sustainably grow revenues. 

    Implementing this approach requires a fresh approach to your product roadmap—because when you scale through retention and expansion, the primary goal is maximizing utility for existing customers so they’ll increase usage and be willing to spend more over time. That means prioritizing core features and usability and not tacking on new features in a bid to draw in new customers with adjacent use cases.

    Getting that right, in turn, requires SaaS leaders to leverage the product itself as a key to understanding which features need attention, as well as a messaging channel and conduit for two-way communication with end users so you can influence user behavior and collect user feedback. Here are four steps that product managers can take to drive durable, resilient growth for their companies:

    Get Serious About Analytics

    Every business wants to use data to drive better decision-making—but many organizations fail to realize that their own product is their most potent source of data. Unlike web analytics which show only the behavior of random web users, product data has the power to help you understand the user journey, what they’re finding useful, what they’re struggling with—and how you can create value to keep them coming back for more.

    That makes product analytics—data showing how your product is being used, along with user surveys, messaging and other more qualitative measures—a powerful resource as you seek to anchor your development roadmap in the things your customers actually need. Armed with user feedback, it’s possible to learn how your customers feel, understand what’s missing—and invest in improvements that align with your users’ evolving needs.

    Stay Focused on Stickiness 

    Your analytics dashboard should have a strong focus on your stickiest features—the ones that keep users coming back for more. Those will include your product’s key value drivers during the early evaluation stage when you’re looking to hook new customers and turn their curiosity into a compelling use case for your product. But they will also include outcome-related features that enable established customers to measure and increase ROI as they scale up. Finally, they will include features that directly drive organic expansion, such as collaboration functionality that drives users to invite colleagues to use your product.

    Product managers (and their bosses) naturally get excited about new features—but by taking a data-driven look at stickiness across the whole customer life cycle, it becomes easier to identify opportunities to innovate around your core functionality and make it more integrated, scalable and productive. Customers won’t renew or expand their contracts because you rolled out a shiny new feature—but they will keep renewing if your team keeps investing in making their outcome-driven features the best they can possibly be so they can be successful at their job.

    Make Space for Quick Wins to Drive Advocacy

    If you view your roadmap as a waitlist for dev resources, it’s tempting to simply add newly identified usability bugs or hiccups to the bottom of the list, and circle back to them months later once your team is done working on building out new features. But in the end-user era, users control the renewal decision, so customer satisfaction isn’t a nice-to-have—it’s something you have to make time for to build and grow a durable business. That means pre-allocating time and resources for quick fixes and small enhancements that reduce friction, eliminate pain points with core features and drive stickiness for existing users. 

    As you track user experience across your stickiest features, you’ll find errors and pain points that need to be remedied promptly to keep your users happy. These are hard to plan for because they’ll emerge on a daily basis based on usage data and user feedback—so the key is to proactively assign resources to address these unplanned issues and turn them into quick wins, enabling you to iterate quickly rather than risking user frustration by adding core-feature fixes to your standard product roadmap.

    Influence User Behavior 

    User enablement is sometimes underestimated by product teams, but the shocking truth is that most customers won’t carefully read through your release notes in search of new features. In fact, they may not even notice your newly released functionality—and those that do might still struggle to understand how that feature supports their core use cases or to intuit the best practices for using it effectively. 

    To increase visibility into new features, you need to leverage in-app messaging, enabling your core users to unlock new functionality in an optimal way so you can capitalize on your product investments. As part of every release process, invest in user enablement by creating effective in-app communication with links to articles and videos that can help users adopt features successfully. 

    Invest in Revenue Drivers

    Of course, focusing on stickiness doesn’t mean slamming the brakes on all new features. The key is to use product data to ensure that innovations aren’t coming at the expense of core-feature usability. Before signing off on a new feature, make sure you have a hypothesis on how it will drive revenues—and remember: Innovative new capabilities might attract a subset of early adopters, but during a down economy your customers care more about must-have features than about nice-to-have add-ons. 

    Be sure to weigh a feature’s projected value—for your users and also in terms of revenues—against the cost of maintaining that feature over time. Every company has a finite amount of dev-hours to dedicate to perfecting its product, so even revenue-positive features can prove a drain on resources. Be realistic about what you can manage and don’t sacrifice long-term stickiness for short-term innovation.

    Remember Your North Star

    To make the right decisions during tough times, every SaaS business needs to focus on its North Star. For product managers, that means taking the time to understand—in a granular, data-driven way—exactly what makes their SaaS product worth paying for. Real resilience comes from leaning into those things and scaling by optimizing the user experience to make the product as sticky as it can be.

    Building durable and resilient SaaS businesses isn’t just about belt-tightening. It requires a commitment to scaling through the product and using it as a vehicle to drive retention and expansion by increasing value across your core features in ways that keep customers coming back for more. That, in turn, requires a fresh approach to your roadmap—because more than anything else, the way you understand and invest in your product will determine your company’s success or failure during the tough times that lie ahead.

  • DevOps World 2022: DevOps is Not Just CI/CD

    DevOps World 2022: DevOps is Not Just CI/CD

    There was a time when pundits said that DevOps was the symptom and CI/CD the cure. While that may or may not be true, there is no denying that CI/CD is the very heart of DevOps. While that might still be true, DevOps today is so much more than CI/CD; it has evolved, far beyond just its core of CI/CD.

    In my preparations for the upcoming DevOps World 2022, held in Orlando, Florida, September 27 to 29, I’ve been briefed on upcoming product announcements by the CloudBees product team. I find it fascinating to see where the CloudBees product line is going. In many ways, CloudBees product evolution mirrors the evolution of DevOps itself.

    Today, DevOps includes areas such as observability, security and compliance, GitOps, cloud-native and more. Developing, integrating, testing and deploying software is only one aspect of today’s DevOps. Without divulging any specific product announcements that CloudBees will be making at DevOps World, I can tell you that CloudBees is on a journey that closely mirrors that of DevOps itself.

    In my opinion, this is as it should be. CloudBees was one of the pioneers of the DevOps movement. By harnessing Jenkins—the original DevOps killer app—CloudBees helped move DevOps into the mainstream. Of course, Kohsuke Kawaguchi (KK), the creator of Jenkins, has moved on from CloudBees and the Jenkins community was always independent of CloudBees. Nevertheless, many of us in the field see CloudBees and Jenkins as inextricably linked.

    While Jenkins is still widely deployed and used, it is no longer the epicenter of the DevOps universe. Over the last couple years, CloudBees has transitioned to become much more than just Jenkins or Enterprise Jenkins and remains at the center of DevOps innovation.

    This year‘s DevOps world will be a great opportunity for CloudBees to showcase just how far they’ve come from being solely the enterprise Jenkins company while remaining a preeminent end-to-end DevOps tools provider. If you want to know just how far, well, stay tuned for our coverage of DevOps World where we will be covering all of the product announcements as well as speaking to CloudBees executives and customers about the new products and product lines and capabilities that will be announced.

    I have written before that the theme for DevOps World this year is DevOps Remix. Our own DevOps Experience virtual event, coming in November, has a theme of DevOps Everywhere. I think both of these themes speak to the same general idea: DevOps is going where it’s never gone before. It has evolved beyond CI/CD to a new way of developing, delivering and managing software that includes securing it and testing it. Over the next few years, I think we’ll see we’re entering a new golden age of DevOps.

    If you can, join us in Orlando for DevOps World. Techstrong.TV will be broadcasting live from the event; if you can’t make it, we’ll keep you updated on all of the developments announced there. Also, join us in November for our own DevOps Experience virtual event, which will highlight DevOps Everywhere: The Edge and Beyond. Hope to see you soon!