Tag: devops

  • Fortifying the Castle: A Quest to Secure the SDLC

    Fortifying the Castle: A Quest to Secure the SDLC

    Every business is a software business today. But as the pressure to churn out new applications and features grows, so do the chances of developers making mistakes. Tackling these challenges doesn’t just require more diligent developers, it requires continuous education across the software development life cycle (SDLC).

    To borrow a metaphor from Arthurian legend, it’s a never-ending battle against hidden risks and formidable adversaries. It will require security champions to share their wisdom and bring order to the kingdom.

    A Kingdom Under Siege

    These are dark times for those fighting the good fight. The threat landscape is a wild and unruly place where risk is everywhere, and adversaries often have the upper hand. They have the advantage of surprise and are masters at hiding in the shadows. But the threat is real. One vendor blocked over 146 billion threats last year alone.

    Many of these attacks take advantage of vulnerabilities in code. It’s a problem made more acute by the widespread use of open source components by today’s developer teams. One estimate suggested that last year alone, developers made 3.1 trillion requests for these components from the top four open source ecosystems. Yet many of these components contain vulnerabilities. According to the Linux Foundation, the average application development project features 49 vulnerabilities across 80 direct dependencies. Worse are the indirect dependencies that are far harder to track and, by some estimates, account for six in every seven project vulnerabilities.

    That makes software supply chain attacks and breaches far more likely, especially as threat actors are actively placing buggy components in upstream libraries with the hope they’ll be downloaded en masse. It’s also getting more likely because developers are coming under increasing pressure to deliver. It’s claimed that over half of developers handle a hundred times more code than they did a decade ago. And most are under pressure to write code faster. This increases the chance of mistakes happening, which in turn can cause significant financial and reputational damage.

    Fighting Back

    The answer to these mounting challenges has traditionally been to focus on “shifting left” or moving testing and scanning earlier in the SDLC. To ensure products are designed with security from the outset, it’s essential to follow “secure-by-design” principles. However, this is only half the picture. Scanning for vulnerabilities is certainly important, but even better is to ensure teams are building more robust code from the outset. Prevention is always cheaper and more effective than cure.

    This is where continuous secure coding education comes in. Continuous because technology and market demands are always changing. In this dynamic world full of risk, a one-and-done approach simply doesn’t cut it. Further, courses should be extended beyond the realm of the developer to every member of the SDLC team: From project management and UX specialists to QA, product management and beyond. All must share a common goal with a common responsibility to produce more secure code. Some will be security champions who share best practices with other stakeholders. But everyone must be pulling in the same direction.

    Time to Fortify the Castle

    So once the kingdom has assembled its diligent developers and security champions, what’s next? With the knowledge and skills imparted through continuous training, plus additional automated checks, real progress can be made to enhance security and resilience.

    If you’re familiar with the OWASP Top 10, you’ll recognize concerns such as server-side request forgery, misconfiguration, using vulnerable components and shortcomings in security logging, cryptography and software integrity. A stronger focus on foundational security practices like the principle of least privilege, separation of concerns and layered defense can mitigate these risks. Among the most prevalent threats are injection attacks, which include SQL injection and cross-site scripting. However, by using tools and having developers well-versed in strategies like input validation, parameterized queries, data cleansing and secure LDAP queries, these threats can be effectively addressed.

    Above all, it’s important to remember that everyone has a part to play in fortifying the castle, in protecting the kingdom from a mounting and formidable agglomeration of threats. That means, as a baseline, that everyone should be getting some form of continuous secure coding training. There’s no time to waste.

  • Why Data Silos Are Killing Your Developer Productivity

    Why Data Silos Are Killing Your Developer Productivity

    Every company is at risk of fostering data silos. In fact, a study conducted by Forrester Consulting for Airtable across employees in the U.S. and the UK revealed that, on average, knowledge workers spend 30% of their week looking for the information they require to do their job and the difficulty in finding and accessing data is the top reason why they feel disengaged from work. What causes essential data to be inaccessible in the workplace? We will explore the root of modern data silos, why they drain developers’ productivity and how to break away from these silos with better observability in your organization.

    What are Data Silos?

    A data silo is a collection of data held by a group that is not easily or fully accessible by other groups in the same organization.

    Data silos can be a byproduct of organizational structure. When different departments or business units in an organization operate independently, they develop their own way of collecting, storing and managing their data. The processes to access that data from other business units can be cumbersome or even nonexistent. Sometimes, the individuals responsible for the data will even be against sharing it for fear that it would be misused or misunderstood outside of their particular unit. The difficulty in accessing information then leads to independent data collection from other business units and ultimately creates other data silos and multiple sources of truth.

    Data silos can also happen during times of growth for an organization. New tools are necessary to support the growing needs of the business and are added to the list of tools already in use. Over time, this list grows, and systems that were designed to operate in isolation can create data silos by limiting the ability to integrate with other systems. A recent survey of marketing organizations by Emarsys showed that the surveyed organizations are using an average of 91 marketing cloud services. These 91 tools undoubtedly create data silos unless they are fully integrated together or into a central system.

    Why are Data Silos Killing Your Developer Productivity?

    Data silos aren’t only slowing your developers down by limiting their access to the data needed for development. They also put a lot of extra work on their plates. And it goes without saying that this additional time spent on data management reduces the time available for improving your product.

    Management of Redundant Data
    Multiple teams in the organization storing their data separately means increased workloads for developers, who need to update and maintain separate copies of the same data.

    Inconsistent Data Quality
    Data gaps or quality issues happen more frequently since different parts of the organization have their own standards for collecting, cleaning and validating data. This can lead to development delays or errors in the product.

    Time-Consuming Integrations
    Developers have to code a lot of integrations to connect all the different tools your organization uses and keep the data flowing between them.

    Inefficient Collaboration
    When different teams work in silos, the chances of misunderstanding are greater, leading to development delays and misaligned priorities.

    Difficulty in Data Governance
    Maintaining high standards of data privacy, security and compliance is time-consuming when the data is spread out in different silos and can create costly regulatory risks.

    Steps Leaders Can Take to Break Down Data Silos

    Fortunately, there are steps that you can take to break down the data silos in your organization, relieving your developers at the same time. Each step may have its own set of advantages and challenges, so the solutions you choose ultimately depend on your organization’s needs and objectives.

    Create a Unified Data Strategy
    Set clear goals and standards for data collection, storage, management and analysis at the company level. You should also implement data governance and security policies.

    Adjust the Culture
    Foster a culture of collaboration and data sharing across the company by encouraging teams to share data, insights, and best practices across different departments. You can achieve this through regular communication, training and incentives for cross-functional collaboration.

    Establish Cross-Functional Teams
    Bringing together members of different departments to collaborate on data-related projects can prove invaluable. These teams should have a shared understanding of the organization’s data strategy and should be empowered to make decisions about data collection, analysis and sharing.

    Invest in Data Integration and Interoperability
    Invest in tools and technologies that promote data integration and interoperability across different systems and departments. Adopt standard data formats, implement APIs and data connectors or use data integration platforms to make observability collaborative. Make sure that the tools you choose to add to your company have various native integration capabilities to avoid custom integrations as much as possible.

    Congrats, you now know all about data silos and how to break them down! The next step for you is to identify the data silos in your company and put a plan in place to get rid of them. Your employees and coworkers will thank you!

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

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

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

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

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

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

    Dice.com

    R&T Deposit Solutions
    New York, New York
    DevOps Engineer
    $145,000 to $175,000

    Indeed.com

    Caterpillar
    Chicago, Illinois
    DevOps Engineering Manager
    $141,000 to $178,000

    SimplyHired.com

    Takeda Pharmaceutical
    Boston
    Machine Learning Infrastructure/Platform Engineer
    $130,000 to $186,000

    LinkedIn

    M&T Bank
    Wilmington, Delaware
    DevOps Manager
    $123,000 to $206,000

    CareerBuilder.com

    Fidelity Investments
    Westlake, Texas
    DevOps Engineer
    $120,000 to $160,000

  • There’s No Value in Observability Bloat. Let’s Focus on the Essentials

    There’s No Value in Observability Bloat. Let’s Focus on the Essentials

    The observability market paired with cloud security has been predicted to reach $70B by 2026, but that market prediction is a myth, and I’ll tell you why.

    If observability was a grand buffet and every company needed a feast of features and capabilities of this proportion, maybe this prediction would be valid. But most companies don’t need an over-the-top feast. Legacy APM and observability solutions are serving up an all-you-can-eat buffet when the reality is that most companies only need the essential ingredients to satisfy their observability strategy. And the cost for that can be much more modest. The $70B observability market prediction is, therefore, suspect, considering the true needs of most organizations.

    Complex cloud ecosystems, the rise of applications built on microservices and Kubernetes, and the overall scale and complexity of applications have led to exponentially more data being created in the pursuit of observability. Storing and processing all that data is expensive, and as the volume of data balloons, so does the cost.

    And while the complexity of business-critical systems and the volume of data have scaled, so have the overall cost of those legacy tools—in direct proportion. Partially, this is driven by the features and instrumentation added that only contribute to the bloat and valueless telemetry.

    Customers aren’t seeing value in any of this bloat, and for the most part, all that’s been accomplished is increased complexity in deploying and operating the system, with a commensurate lengthening of time to value. Plus, pricing models haven’t significantly changed despite the advancements in the market. The fact is, organizations can’t really say that they have gotten more insight into the overall performance of their mission-critical systems. What they are saying, however, is that these tools are becoming overwhelming to manage and overwhelmingly expensive, and developer productivity is not increasing.

    What organizations need and want are real-time insights into the health and performance of their cloud infrastructure and applications–specifically the confluence of logs, metrics and traces within the context of modern observability. There is little tolerance for software bugs, slow web experiences, crashed apps and other service interruptions, and the responsibility lies on developers, engineers and ITOps teams to quickly resolve production issues before they impact customer experience.

    There is a call for observability, but rather than an explosion of features and noise, what’s being called for is a narrowing of focus.

    Observability Has an Efficiency Problem

    Telemetry data gathered from the distributed components of modern cloud architectures needs to be centralized and correlated for engineers to gain a complete picture of their environments.

    Engineers need a solution with critical capabilities such as dashboarding, querying and alerting, and AI-based analysis and response, and they need the operation and management of the solution to be streamlined.

    What’s important for them to know is that it’s not necessary to spend more to ensure peak performance and visibility as their environmental complexity grows.

    Legacy players experiencing some maturity in the market may have conditioned them to believe this is true—they have set a standard for higher costs correlating with incremental amounts of data, no matter the quality of that data. Companies are being fed the lie that all this data may be relevant and they’ll be doing themselves a disservice by neglecting even one byte of it.

    Data Does Not Inherently Equal Insights

    No doubt, more data is being generated, but most of it is not relevant or valuable to an organization. Observability can be optimized to bring greater value to customers, and that’s where the market is headed.

    Call it “essential observability.” It’s a disruptive vision to propose a re-architected approach to observability, but what engineers need is a new approach making it easier to surface insights from their telemetry data while deprioritizing low-value data. Costs can be reduced by consuming only the data that enables teams to maintain performance and drive smart business decisions.

    Essential observability is cutting out the fluff and only focusing on—and paying for—the impactful data. It’s about arming engineers with meaningful insights so they can quickly resolve production issues and business disruptions. Organizational performance increases without inflating data complexity and resource consumption.

    The Essential Observability Revolution

    Observability tools have evolved beyond the model of linear price increases as complexity and data scales. For companies (especially growth-stage organizations) that want a partner to help them make more informed decisions and keep their costs more reasonable (i.e., stop recklessly spending for useless data), they need to focus on tools offering them the essentials.

    Solutions are available, offering targeted features and automated capabilities out of the box, delivering the insights needed to understand and fine-tune data. These solutions provide continuous support, reduce complexity and accelerate time to value.

    The next revolution in observability isn’t features and functionality but providing insights to make data-driven decisions that keep essential observability cost-effective while not compromising the value derived.

  • DevOps Dozen² Awards 2023 Nominations Now Open

    DevOps Dozen² Awards 2023 Nominations Now Open

    We are excited to announce that the DevOps Dozen² 2023 nominations are now open. Now in its ninth year, the DevOps Dozen once again highlights the leading innovators in the DevOps world. 

    As we’ve done the last three years, there are actually 24 award categories. Twelve are aimed at the many great commercial DevOps solution categories in the market. The other twelve are aimed at the vibrant community and open source ecosystem which powers the DevOps movement. 

    As in years past, the selection process has two tiers. Nominations for finalists are open now and will close on October 20, 2023. We will announce the finalists on November 13, 2023. After the finalists are announced, open voting will be conducted to determine the winners in each category. Public voting accounts for 40% of the weighted final count, with 60% coming from the votes of this year’s panel of judges.

    This year’s judges are myself, Alan Shimel, CEO of Techstrong Group, Mitchell Ashley, CTO of Techstrong Group, Sharon Florentine, managing editor of DevOps.com, and John Willis, DevOps luminary and author. As we’ve done in past years, we are asking the 12 companies that receive commercial category nominations to pay a nominal fee to cut down on spam submissions and help cover the cost of tracking the nominations, trophies and other administrative expenses. Community awards remain free to nominate but spamming nominations will result in disqualification.

    We have not changed the categories from last year, though we did consider adding a category for AI in DevOps. Perhaps next year. Without further ado, here are the 24 categories for the DevOps Dozen awards:

    DevOps Dozen Tools and Services Awards

    • Best End-to-End DevOps Tool/Service
      Consolidation in the DevOps space has led to a greater selection of platforms offering end-to-end solutions. This award honors the platform with the most diverse and robust solution for DevOps teams.
    • Best DevOps Repo/GitOps Tool/Service
      GitOps has become an integral part of the DevOps toolbox. This award is presented to the most outstanding code repository/Git/GitOps tool.
    • Best CI/CD Tool
      This award recognizes the best CI/CD tool that helps teams to deliver quality code faster.
    • Best Value Stream Management Tool
      Value stream management has come into its own as an important tool for measuring the business value of DevOps and application development. This award recognizes the value stream management tool that most effectively helps organizations visualize the value stream, track metrics and measure improvement.
    • Best Observability Solution
      This award recognizes the best observability solution for understanding the performance of individual components, systems and entire applications.
    • Best DevSecOps Solution
      This award honors the best DevSecOps solution, which enables security to be included earlier in and continuously throughout the SDLC.
    • Best Testing Tool/Service
      Testing is a mainstay in the DevOps toolchain. This award recognizes the best testing tool for ensuring the quality of code.
    • Best Kubernetes Platform/Service
      The adoption of containers has paved the way for an entire solutions ecosystem. Kubernetes is perhaps the most widely recognized and utilized tool for container orchestration. There are many platforms and services that offer Kubernetes-based solutions. This award honors the best Kubernetes platform/service available.
    • Best Cloud-Native Security Solution/Service
      The cloud-native movement has taken the IT world by storm due to the depth and breadth of the solutions available and the benefits of building applications and services specifically for cloud-native environments. This award recognizes the best cloud-native tools, solutions and services.
    • Best DevOps for Mainframe Solution
      Despite their age, mainframes are a mainstay in the IT world, and a variety of solutions are available for enabling DevOps practices in mainframe and hybrid environments. This award recognizes the best of them.
    • Best DevOps for DataOps/Database Solution
      Databases often have been left out of the DevOps conversation, but that is changing  as the concept of DataOps is gaining greater traction. This award recognizes the best solution in the database and DataOps space.
    • Best New DevOps Tool/Service Provider
      This award recognizes the best new service provider or tool that has brought innovation to the DevOps space in the past year (must be less than 24 months old).

    DevOps Dozen Community Awards

    • Best DevOps Industry Implementation
      This award honors organizations that have successfully adopted and implemented DevOps principles and practices.
    • Best DevOps Survey/Analysis/Research
      This award recognizes research that has significantly and positively impacted the DevOps community.
    • Best DevOps-Related Video Series (video)
      This category highlights the most entertaining, educational and inspirational DevOps video series—those with the most engaging and highest-quality content.
    • Best DevOps-Related Audio Podcast Series
      Which is your favorite DevOps podcast from this year? This category celebrates the many great DevOps podcasts driving discussions about everything from CI/CD and testing to DevSecOps, Kubernetes, containers and more.
    • Best DevOps Book/eBook of the Year
      Each year sees a plethora of well-crafted DevOps-related books and ebooks. This category highlights the most popular and  most-read of the year.
    • Top DevOps Evangelist
      This category is one of our favorites! There are so many great evangelists who spread the DevOps gospel, but we want to know who does it best. Nominees can work within the DevOps space or outside of it.
    • Best DevOps Transformation (non-vendor)
      In a year marked by continued digital transformation, we want to know which organizations stood out in their efforts to transform their business through DevOps.
    • Best DevOps Event of the Year
      Virtual events became the norm throughout  the pandemic. But as more people crave face-to-face interaction, in-person events have slowly made a comeback. Which DevOps event stands out from the crowd?
    • Most Innovative DevOps Open Source Project
      Open source projects are meant to promote innovation and increase efficiency, velocity and quality. While there are many great open source projects out there, the best ones are those that create a community of people who work on and with the technology and support each other.
    • DevOps Executive of the Year (non-vendor)
      This category celebrates excellence among DevOps leaders at the C-suite (or equivalent) level.
    • Best DevOps Presentation of the Year
      This category recognizes the best DevOps-themed presentation from the many (virtual) conferences that took place this year.
    • Best DevOps.com Article of the Year
      This category celebrates excellence among DevOps leaders at the C-suite (or equivalent) level.

    Good luck to everyone nominating for the DevOps Dozen² Awards 2023. We will update finalists on November 13.

  • DevOps is Making Gains on Mainframe Platforms

    DevOps is Making Gains on Mainframe Platforms

    A survey of 800 executive and technical professionals conducted by BMC found close to two-thirds (62%) are employing DevOps workflows to build and deploy applications.

    In addition, the survey also finds that just under a third of respondents (32%) are applying artificial intelligence to IT operations (AIOps) across all platforms.

    John McKenny, senior vice president and general manager of intelligent Z optimization and transformation at BMC, said the survey shows that organizations continue to invest in mainframe applications alongside distributed computing environments.

    In fact, 61% of respondents noted that data volume on mainframes increased in the last year, with 56% reporting an increase in the number of databases running. Well over a third of respondents (35%) also reported increased interest in taking advantage of cloud technologies to handle, for example, storage and data protection.

    Overall, the survey found that 94% of respondents have a positive perception of the mainframe, with nearly two-thirds (63%) reporting increased mainframe investments over the past year.

    Compliance and security lead the list of priorities for mainframe organizations, with 61% of respondents citing these as top issues, followed by cost optimization (49%), enhancing automation (41%) and data recovery (40%).

    In general, organizations with mainframes are adopting modern application development tools such as VS Code to attract a younger generation of developers. It’s critical to continue to attract developers to mainframe platforms that continue to run the most mission-critical applications in the enterprise, said McKenny. Many of those applications are being modernized using DevOps tools and practices rather than being moved to another platform, he added.

    He added that the appetite for using generative artificial intelligence (AI) to write code for mainframe applications is less clear because of intellectual property concerns. Most organizations are not going to want to expose their mainframe code to a general-purpose large language model (LLM) that drives a public generative AI platform, but there will be a role for private LLMs that are trained using code that has been validated, noted McKenny.

    Regardless of how generative AI evolves, there’s still much work to be done to further the adoption of DevOps best practices in mainframe environments. Each organization will determine how stringently to apply those practices based on the frequency at which applications running on mainframes need to be updated. In most cases, organizations with mainframes will use a mix of waterfall and DevOps-based approaches to building and deploying applications for many years. The decision as to which approach to employ will, naturally, have as much to do with culture as it does the rate at which the application needs to be built and deployed to drive, for example, a digital business transformation initiative.

    The days when mainframes were managed in isolation from the rest of a distributed computing environment are slowly coming to an end. A mainframe is, arguably, just another node for deploying applications. The challenge and the opportunity now is getting the right DevOps tools in the hands of the IT team managing heterogeneous IT environments, including mainframes.

  • Why Enterprises Should Embrace Data-Driven Software Management

    Why Enterprises Should Embrace Data-Driven Software Management

    Many Fortune 500 companies have recently undergone extensive layoffs and now find themselves having to achieve more with fewer people—while grappling with how to integrate generative AI into their products. They must build while economizing, streamlining and increasing efficiency in every part of their company. Yet one of the most vital cogs of the machinery has struggled to evolve over the past 20 years.

    In fact, until now, managing high-tech engineering teams at the world’s biggest companies has not been all that high-tech.

    Back in the 1970s, the “waterfall” model was introduced: An inflexible process in which each phase of software development depended on the previous one’s completion. Then, around the 2000s, companies started moving towards “agile” models that tracked progress in two-week sprints.

    Now, a third era of software development management is emerging. It’s not waterfall or agile; it’s data-driven.

    Current management systems cannot give managers real-time, granular insights so they can make decisions on the spot and run projects in the most efficient way possible. However, data-driven models generate live data on how teams are progressing which has far-reaching effects on businesses’ productivity and future survival.

    The emergence of DORA, a framework for tracking development metrics makes this possible. For the first time, new tools enable us to capture the software development life cycle automatically, without any manual input from the engineer, leading to fewer roadblocks, a 20% faster cycle time and greater ROI.

    Despite this, only a handful of Fortune 500 companies have embraced data-driven metrics. Here are the reasons that shift should happen now.

    Real-time Insights are Game-Changers

    Until now, companies have been using inaccurate methods to track their software development teams. Project management reports on engineers’ output are reviewed every two weeks, monthly, or even quarterly. This means that impactful changes are made at a delayed point in time rather than when they can make the greatest difference to cycle time.

    In contrast, DORA measures specific real-time performance indicators: Deployment frequency (DF), lead time for changes (LT), mean time to recovery (MTTR) and change failure rate (CFR) (For more information, see here). These far more data-driven metrics measure efficiency and velocity at every key point of day-to-day software development, with feedback to management happening continually.

    Often, individual engineers won’t have enough capacity or oversight to inform managers of specific issues during a cycle. Using DORA metrics is like being able to detect that a team has an abnormally high BPM though they are in a rest phase. It’s a signal of illness; that more or different resources are needed. That then requires you to go in and inspect the micro factors that can be adapted.

    For any Fortune 500 company, this quick turnaround is vital. Any small issue in a product cycle can easily escalate and become a critical problem in a matter of days. Instead, using DORA can accelerate software development and, ultimately, time to market.

    DORA Gives you Internal Benchmarks

    But, how can you tell if something is wrong while using DORA? In the first few months of adoption, it’s likely that companies will compare their internal data to industry benchmarks. Unprecedented data has recently been published that offers general performance benchmarks for each DORA metric based on industry research.

    But the end game is to be able to compare your DORA metrics to your own internal benchmarks. With time, each company will develop its own personal baselines that better represent internal capabilities and limitations based on innumerable variables.

    The purpose of DORA benchmarks, however, is not to draw a fixed red line. Think of it more like a speed limit that ensures that people are working at a steady pace while allowing for flexibility.

    A clear sign that your team may be burnt out is a really low cycle time. At times it can be a technical bottleneck, but the beauty of DORA is that it can also point you towards well-being issues.

    DORA Needs to be Coupled With Granular Insights

    DORA is unparalleled when it comes to flagging managers that something is wrong. DORA metrics can flag that a team has a high cycle time – for example, an abnormally long deployment frequency suggests that engineers are working more slowly or that there may be a build-up of code that isn’t being uploaded to the repository quickly enough during the review process. At that point, you need to zoom in to get more information. There are multiple metrics that provide insights into the exact pain points in a team’s development, and you can develop these internally or via tools or engineering management software that provides more holistic oversight.

    In this particular case, you can use a granular metric called “time to merge from first review” to see how fast engineers incorporate feedback from their peers during code reviews. If it is taking a week for the first review to be carried out, integrated into the code and finally uploaded to the general platform, then perhaps there’s a bottleneck occurring during the review process.

    Perhaps the most important benefit of Engineering Leadership 3.0 is that it no longer has to be a guessing game. If they sense something’s wrong, they can check their DORA dashboard, receive confirmation of the problem, hone in with granular metrics, and take corrective actions immediately.

    Teams that adapt their behavior as a result of these data-driven metrics will add incredible ROI to the company. But these changes can’t happen overnight. It will start with getting buy-in from engineering managers and the executive team. For Fortune 500 companies, that often requires elaborating action plans, integrating external tools to operate the tracking process and training engineering managers (in our case, this takes up to five weeks). But once they’re a part of the business, they will become indispensable in running smoothly without stacking up issues.

  • There’s no One-Size-Fits-All Data Mobility Strategy

    There’s no One-Size-Fits-All Data Mobility Strategy

    Whether you’re a Fortune 500 enterprise or a fledgling startup, there’s one thing every business can expect to confront: Change. This is resoundingly true when it comes to data management. Even greenfield operations will, sooner rather than later, need to change how and where they leverage their data. After all, every business—including those launched with the most cutting-edge technology—is built on a series of choices and compromises. As technologies and business priorities change, so should your data mobility strategy.

    In a world of ever-changing variables, what’s the right data mobility strategy? There is no one-size-fits-all solution. It does, however, help to start with a solid foundation on which to build your strategy.

    With the right platform that allows for flexibility and change, it’s time to build the structural framework for your data mobility strategy. When creating the framework for your data mobility strategy, there are a few considerations to keep in mind, including your desired use of on-premise storage, your hybrid cloud strategy and “supercomputing” capabilities, and the storage area network (SAN) needed based on your organization’s needs. Let’s review what they might mean for you:

    Developing a Hybrid Cloud Strategy

    The reality is that the hybrid cloud is now achievable for most organizations. According to Flexera’s 2023 State of the Cloud Report, 72% of organizations have embraced a hybrid cloud strategy. Your data mobility strategy should reflect that.

    With a proper hybrid cloud environment, the user experience should be seamless regardless of where your data exists, whether that’s on-premise, in a private cloud, or in the public cloud. As the potential for more dynamic resource allocation grows, your data mobility strategy inherently becomes more critical. Data mobility, in effect, now equates to computing mobility.

    Leveraging the “Supercomputer” in the Cloud

    Data mobility becomes even more imperative as entities gain more opportunities to take advantage of “supercomputing” capabilities.

    The computing power that exists in the cloud now is tremendous, and thanks to modern dynamic cloud pricing, even smaller organizations can tap into it. According to one estimate, the cloud-based high-performance computing market should reach $55 billion by 2030, growing at a CAGR of 7% from 2023 to 2030.

    So for example, if you’re a FinTech startup, you could pay by the minute to leverage high-performance computing capabilities to test your trading algorithm. Previously, these powerful capabilities were only available to the biggest customers — think NASA — and came with astronomical costs.

    On-Premise Solutions Aren’t Going Away

    Even as cloud services and capabilities become more accessible and more valuable, on-premise operations aren’t going to disappear. Customers have all kinds of reasons for keeping data on-premise, whether it’s for compliance purposes, costs or the desire to leverage existing infrastructure. Certain workloads, meanwhile, simply don’t make as much sense on the cloud.

    The reality is that even the most compelling alternatives couldn’t eliminate on-premise operations, because business ecosystems and industries evolve organically. Think about it: Many businesses still use landlines, and workers still use desktop computers. Nearly half a century after marketers first coined the term the “paperless office,” it took a full-blown pandemic to push our collaboration tools to the point where we are finally, basically, paperless.

    Fiber Channel and iSCSI

    When it comes to data mobility, how does an organization decide whether to adopt fiber, iSCSI or both? As organizations manage workloads that require low latency and other networking capabilities, they’re going to be investing heavily in this area.

    Traditionally, a significant amount of data management is fiber-channel-based. With iSCSI, an organization doesn’t need to invest in separate physical infrastructure, such as switches or cables. Moreover, iSCSI has become more attractive to entities moving workloads to the cloud. A whole range of products, from Pure Storage, NetApp and even cloud platforms like Microsoft Azure, offer iSCSI-based storage in the cloud. Your data mobility strategy should consider how to move from fiber channel to iSCSI and back again.

    Change is the Only Constant

    Ultimately, no one can predict all of the major technological innovations that will impact their business down the road. To stay nimble, you need a data mobility strategy that you can execute with the team you have — whether their primary expertise is in storage, networking or elsewhere. This can be especially challenging in large organizations, with teams that have to meticulously plan their projects and stay accountable for their budgets. Now more than ever, it’s important to have a solid foundation on which to build a strategy that fits your needs.

  • Will ChatGPT Replace Human Software Developers? Probably Not

    Will ChatGPT Replace Human Software Developers? Probably Not

    Since the release of ChatGPT, there has been a great deal of hype around generative AI and how companies can leverage it to cut costs and democratize software and application development. Naturally, with discussions of cost-cutting and democratization come whispers about what will happen to software developers.

    This is a real and valid concern, but software developers’ skills, expertise and creativity are still very much needed.

    While generative AI and AI code generation tools like ChatGPT have shown some promise and potential benefits, they are still in their infancy—like many other innovative technological advancements. We also don’t know what scenarios they may present down the road or their true abilities when the technology matures. For instance, how will it integrate with other technologies? We don’t know what will happen when a ChatGPT-generated line of code breaks or needs to be changed. We don’t know if it can provide a novel solution to a unique problem or what security threats it will present.

    Given these unknowns, technology executives should think twice about replacing experienced and creative technology talent, such as software developers, with AI code generators.

    Will ChatGPT create novel code to solve a unique problem never encountered before? Probably not.

    A Tale as Old as Time (Or at Least a Decade)

    The technology industry has been searching for and developing new ways to make certain software development tasks much easier and more streamlined for years. One example of this is low-code/no-code.

    The notion of simplifying application development and replacing software developers with laypeople (citizen developers) has been around for more than a decade now, as low-code and no-code solutions have grown more popular. These solutions have promised that companies don’t need technical talent to get their software and app projects off the ground.

    However, if you look at the impact of these solutions today, their use can result in large amounts of technical debt and almost always require the skill of experienced software developers.

    The reason? Building complex software and applications is extremely difficult; it’s an art.

    Low-code and no-code solutions have their rightful place and can make things easier if a company is looking to launch a simple app or static web page. These solutions can increase the pace of development and time-to-market and enable everyday people without any development skills to facilitate them. However, they are not actually a complete solution and often overlook aspects of development that a human software developer would typically address. Without a skilled expert involved, low-code/no-code platforms often can’t solve a unique problem a company has.

    So, how does this relate to AI code generators like ChatGPT? Here’s how.

    A Similar Situation—With One Key Difference

    When thinking about their place in the development process, AI code generators are not that different from low-code or no-code solutions. The thinking is that they will also enable non-technical individuals to create software and applications with ease.

    Yet, there is one key difference—they promise expertise, too. But is the expertise coming from the AI code generator or the person piloting it? The answer is simple; it is not from the code generator.

    There have been examples of companies and individuals that have tried using ChatGPT to build code, and they have appeared to be successful. However, without the input of the individuals using it, it never would have been able to create the code on its own unprompted.

    This means that the expertise of skilled, human software developers is still very much needed, especially when building intricate software and apps that require complex functionality such as optical character recognition (OCR), internet-of-things (IoT) connectivity and more.

    A Future With Software Developers

    Because of the expertise still required to create elaborate and innovative software and applications, AI code generators will not replace software developers anytime soon, if ever.

    The technology used in these tools is still in its infancy, presenting many lingering questions and potential challenges. We will see this confirmed by the trials and tribulations experienced by the few companies and executives attempting to replace software development teams with tools such as ChatGPT.

    Knowing AI code generators follow a similar path as low-code and now-code solutions, companies and executives should use them as developer enablement tools. These tools should complement the work of software developers by empowering them to focus on the complex tasks software and apps today require.

  • Generative AI and Software Testing Tools to Manage Technical Debt

    Generative AI and Software Testing Tools to Manage Technical Debt

    It is easy to take a pessimistic view of generative AI and large language models (LLMs), especially when a growing list of AI experts and public figures have voiced concern about their potential to lead to dire consequences—even to human extinction. But we must also consider how these same technologies might mitigate these risks. There is no doubt that we are living in an accelerated cycle of technological progress and repercussions. However, the intelligence, speed and agility of AI—and particularly machine learning (ML)—may be just what we need to roll with the punches.

    As the speed of development outpaces our ability to mitigate potential risks posed by the systems we build, we are set on a path to accruing massive technical debt—the ever-increasing costs associated with modernizing code later rather than sooner. Too often, organizations in the private and public sectors are reluctant to pay off this debt, choosing an “if it ain’t broke, don’t fix it” mentality toward software maintenance and security. The problem is that as technology outgrows and outpaces our critical infrastructure systems, the potential for catastrophe escalates.

    Machine Learning: A Tool for the New “Space Race”

    Automated testing has proven superior in regression testing, especially in visually recognizing potential issues at the pixel level. If, for example, an important element of your interface is missing from the screen after an update, a visual test script can identify that faster than a human can. AI (and in particular, machine learning) generates test plans that provide more comprehensive coverage of the system under test and more practical coverage.

    Traditional testing methods usually begin with a broad and hypothetical analysis of user interactions. Test engineers begin by casting a wide net to cover the many possible user engagement scenarios they imagine. In contrast, AI-assisted systems learn from actual user interaction, building script libraries that focus on known points of weakness and vulnerability. It also does this at speed and scale. This technology is going to be essential to software test engineers as they inevitably find themselves unable to keep up with the abundance of code generated from LLMs using traditional testing methods.

    Technical Debt is Inevitable but not Unsolvable

    Every new iteration of software has the potential to introduce unforeseen problems ranging from glitchy bugs to catastrophic failures. The risks of releasing new software vary immensely between applications: It’s one thing if the latest release of your music streaming app crashes and quite another if the system that runs the regional power grid fails. One will result in unhappy customers; the other, the potential loss of life.

    The most critical systems (e.g., financial, transportation, safety, medical) are more likely to get frozen in time. Once a stable iteration is released, companies are generally not keen to make changes unless absolutely necessary—beginning the cycle of technical debt accumulation that grows until that debt is paid off by modernizing the code.

    Deciding when to pay off technical debt has always been a matter of weighing pros, cons, costs and benefits. But sometimes, such as in the case of an epic failure, that decision is forced. Both the risk of breaking the system and the cost of modernization compel developers to leave well enough alone. Meanwhile, the longer a system remains unchanged, the more isolated, outdated, and obsolete it becomes, setting the stage for failure.

    By introducing generative AI technology to the development stack along with other tools for authoring, compiling and testing software, developers will soon find themselves driving in the fast lane. With the security of knowing that code can be produced rapidly and released safely, owners of aging legacy systems will be more likely to modernize software sooner, helping them to pay off technical debt more quickly. That, in turn, could lead to increasingly rapid software development and release cycles, more work for developers, and more innovation. Such a workflow could very well become the embodiment of accelerating change, taking us from an “if it ain’t broke, don’t fix it” mentality to one where we anticipate the need for new code and avoid future catastrophic failures, or for that matter, human extinction.