devopsy.kinsta.cloud

Category: Features

  • Codenotary Launches Cloud Service to Generate SBOMs

    Codenotary Launches Cloud Service to Generate SBOMs

    Codenotary has launched a Codenotary Cloud platform that can automatically generate a software bill of materials (SBOM) and make it easier to discover what components have been included in an application.

    Moshe Bar, Codenotary CEO, said that capability can also play a key role in identifying which components in an application might contain, for example, the Log4jShell vulnerabilities that were recently discovered in Java applications.

    That capability can reduce the time required to remove insecure artifacts by as much as 80% simply because organizations are not dependent on scanning tools to search for vulnerable components, added Bar.

    Codenotary Cloud is based on an immutable open source immudb database that cryptographically attaches an identity to each software artifact. In the wake of a series of high-profile breaches, there’s now a lot more focus on the integrity of software supply chains. In fact, the Biden administration recently issued an executive order requiring all federal agencies to, among other things, make sure an SBOM is available for all the software they use.

    Codenotary claimed Codenotary Cloud can scale to millions of integrity verifications per second across source code, builds, repositories, Docker container images and Kubernetes deployments in a way that doesn’t require DevOps teams to upload data to a centralized platform, noted Bar. That makes it possible to notarize and verify the provenance of all the code being employed, he added.

    Codenotary Cloud can also be fully integrated with most vulnerability scanners and popular cloud-native continuous integration/continuous delivery (CI/CD) systems running on any cloud or on-premises host via a managed service. Pricing starts at $5,500 for a workgroup of 10 developers.

    It’s not clear to what degree the Biden administration’s executive order will improve overall software security. There have been multiple vulnerability issues over the years that have not resulted in any material change in how organizations manage their application development processes. However, the executive order issued by the Biden administration, coupled with a recent summit on the state of open source software security, means more senior business and IT executives are at least aware of growing concerns.

    The one thing that is certain is there will be more zero-day vulnerabilities discovered. Developers today routinely reuse open source software and free components maintained by a small number of volunteer programmers. Like any other developer, the amount of security expertise those individuals have is limited. Many organizations reuse that code without contributing anything meaningful back to the project—either in terms of financing or vulnerability identification and remediation support. Contributors to these projects freely donate their time and expertise to build these components. Many of those contributors feel the onus for securing the software they created is on the organizations that decide to deploy that software.

    Regardless of who is responsible for security, it’s apparent cybersecurity teams are going to be reviewing application development processes. Theoretically, that should benefit all concerned and lead to DevSecOps best practices being more widely adopted.

  • WhiteSource Tightens Code Scanning Tool Integration with Azure DevOps

    WhiteSource Tightens Code Scanning Tool Integration with Azure DevOps

    WhiteSource has added the Microsoft Azure DevOps platform to the list of continuous integration/continuous delivery (CI/CD) platforms its open source vulnerability scanning tools natively supports.

    Susan St. Clair, director of product management for WhiteSource, said while developers are always encouraged to scan for vulnerabilities, it’s more effective if organizations implement scanning by default every time there is a merge request. That approach reduces friction because organizations become much less dependent on developers to scan for vulnerabilities within the context of a larger DevSecOps workflow, she added.

    WhiteSource also provides a merge confidence feature that uses crowdsourced data to show how likely it is that an open source component can be updated without breaking the build. Merge confidence includes data on upgrade age, adoption and compatibility to create a confidence score.

    The WhiteSource integrations make it possible for DevOps teams to detect all open source components being used and automatically enforce security policies directly from their repository. DevOps teams are provided with vulnerability and misconfiguration alerts and license violations along with detailed remediation guidance, including suggested fixes and prioritization advice, within an existing workflow versus being required to switch to a tool that has a separate user interface (UI) they need to learn.

    Should a merge request introduce a new error, the developer is given immediate feedback to resolve any newly introduced vulnerabilities before the request is completed. That approach to separating feature branches and mainline branches prevents interruptions to workflows. The enterprise edition of the WhiteSource tool also automatically generates pull requests in the repository to update vulnerable open source components to the lowest non-vulnerable version.

    WhiteSource also supports code repositories such as GitHub, GitHub Packages, JFrog, Bitbucket and GitLab. The Azure DevOps platform is gaining traction as more application development projects are being managed via the cloud following the onset of the COVID-19 pandemic, noted St. Clair.

    As more organizations begin to embrace DevSecOps workflows each of them will need to decide how far left they want to shift responsibility for application security. In theory, each developer is now being held more accountable for every one of their applications that gets deployed in a production environment. In practice, most developers lack the expertise required to ensure applications are secure.

    There are, of course, more concerns being raised about the security of software supply chains that include open source software in the wake of the recent disclosure of zero-day vulnerabilities in the widely-used Log4j logging tool. Many of the maintainers of smaller open source projects lack the resources required to ensure there are no inadvertent vulnerabilities that could be exploited by cybercriminals. More challenging still, many developers may have used an older version of that software that has known vulnerabilities.

    It’s not clear how open source software will ultimately be made more secure. In the meantime, however, it’s clear the onus for ensuring the security of that software is on the DevOps teams that employ it.

  • Trends in the API Industry

    Trends in the API Industry

    The application programming interface (API) economy is chugging along full steam ahead. The API management market alone is expected to expand 35% by 2025, supported by the sheer number of web APIs coming to market. APIs have become ubiquitous across microservices architectures, public product initiatives, SaaS platform offerings, IoT and partner-partner integrations.

    The industry has proliferated and continues to change, introducing new API use cases across all industries. This ubiquity creates a heightened need for an API program to maintain a quality developer experience and remain competitive. There are also different styles and specification options on the market, meaning designing the right API strategy is a moving target. And, amid peaking cyberattacks, developers now have a strong imperative to retain high security and reliability for these integration points.

    I recently met with the CEO at Stoplight, Steve Rodda, to discuss the above trends and other forces pushing the API industry forward in 2022. Below, we’ll dive into these trends to see how they affect API strategies and what developers need to know to stay on top of their applications.

    Non-Software Companies Embrace APIs

    As software eats the world, more companies are becoming software companies. And, an API strategy is part and parcel of this digital transformation. A big trend that Rodda recognizes is increased API strategies among traditionally non-software companies.

    For example, Rodda explained how a large beverage manufacturer evolved to adopt APIs company-wide to better use and scale their data. Standardizing the API development and design process helped avoid the “rat’s nest” of custom code, said Rodda. “APIs are no longer a byproduct; they’re a design artifact,” he said.

    APIs are no longer reserved for startup cloud-native unicorns like Stripe or Twilio, either. We now see many industries and sectors like supply chain management, health care, shipping, built environments and mainframe modernization adopting API approaches. The financial services sector is especially keen to open up APIs as open banking is being driven by regional regulation or market pressures.

    A Rise in Internal API-First Adoption

    ProgrammableWeb, the most comprehensive API directory, lists over 24,000 APIs at the time of writing. There’s no doubt that public-facing APIs are very well documented. But this is only a sliver of total API adoption.

    The 2021 Postman State of API report found that only 15% of APIs are publicly available. Most APIs are either partner-facing (27%) or private (58%), according to the report. In fact, the most popular use case for APIs is integration between internal applications, programs or systems. Along with the growth of internal API use, API-first thinking is gaining mind share. Postman defined API-first as “defining and designing APIs and underlying schema before developing dependent APIs, applications or integrations.”

    Internal use cases are less frequently discussed but are pervasive for large enterprises, said Rodda. Whereas in the past, development teams paid less attention to style guides and documentation for internal services, he now notices that these practices are shifting. The zero-trust approach is influencing teams to take more care in defining and standardizing internal APIs as if they’re external-facing. This also eases consumption. “You need to take care of the folks next door to you and treat them with just as much respect,” said Rodda.

    The Growing Need for Robust API Security

    APIs have a security problem. Many don’t handle authorization correctly and expose far too much information. A hacker can often escalate their privileges or simply swap a different user ID into an API call to return loads of sensitive data or even make changes to the data. Many HTTP API endpoints that are intended to be private really aren’t. As a result, OWASP lists broken object-level authorization as a top API vulnerability.

    In recent years, we’ve seen what can happen when APIs are improperly configured. For example, a Facebook API lacked an authorization check for unlisted posts, allowing a client to post on any user’s behalf. A similar authorization hiccup occurred with Peleton that allowed hackers to alter any user’s back-end account. APIs constantly work with sensitive data and must carefully navigate the various data privacy regulations around the globe.

    According to Rodda, a design-first mindset is vital to ward off security woes early in the API life cycle. This means deciding on a structure with a common design and choosing appropriate style guides well before coding. “Good documentation, good design guides and good discipline around building something with a cross-functional nature will increase security and scalability,” said Rodda. When you know what’s going on, you have more control and things are inherently more secure, he added.

    OpenAPI Carries The Day

    The OpenAPI specification, formerly known as Swagger, is an industry-standard specification for describing REST web APIs. OpenAPI can help direct your API’s design and development. OpenAPI tooling can also help generate useful documentation, sandboxes and SDKs, making it a valuable specification for creating interoperability between partners.

    “OpenAPI is going to carry the day for a while,” said Rodda. The OpenAPI Initiative has gotten the support of big names in the tech industry. Yet, Rodda estimated only 40% of companies have adopted OpenAPI in production. Rodda said he believes tooling will make it easier for more groups to maintain OpenAPI adoption across their organization, reducing the redundancy of writing “yet another YAML file.”

    REST is still by far the most-adopted API design style—59.7% of developers use REST for production APIs, according to RapidAPI’s State of APIs Developer Survey 2021 report. Yet, asynchronous event-driven communication protocols are gaining traction, and those protocols tend to prefer alternative description formats like AsyncAPI. Websockets, gRPC and GraphQL are other options consistently used by a significant percentage of API developers.

    Developer Experience Matches User Experience

    Another major trend is the rising importance of developer experience (DX). DX is akin to user experience but is all about increasing usability for developer consumers and improving their ongoing relationship with software-as-a-service. “DX is as big a deal as UI/UX these days, if not bigger,” explained Rodda. “Developer experience directly translates into efficiency and reusability.”

    In the context of APIs, increased consideration of developer experience means reducing the onboarding effort and maintaining more reliable connections. For example, users will likely look to other solutions if a third-party API has poor uptime and routinely introduces a breaking change. Better DX likely will also equate to increased abstraction layers and more code generation. Rodda pointed to GitHub’s CoPilot as an example of the use of AI and automation in the developer-of-tomorrow’s workflow.

    “We’ve evolved as a developer society,” said Rodda. Just as consumers expect high-quality real-time applications, developers expect highly performant APIs. To help get there, one increasingly popular philosophy is the API-as-a-product perspective. “If you treat it all as a product, you’re building it with the same standards and quality that you would share externally,” he explains. “Then, there’s no attention to detail that goes missing.”

    Final Thoughts: The Design-First Mentality

    More industries are utilizing APIs than ever before, and APIs are seeping into traditionally non-technical companies to aid their internal integration efforts. But data privacy is a pressing concern when opening up data, requiring careful measures. Taking a design-first approach with standards like OpenAPI could help organizations stay alert and ensure consistency across their portfolio of services.

    There are other trends at work in the API economy, too. For example, one interesting Web3 initiative is an attempt to combine the world of blockchain and APIs by enabling on-chain smart contracts to interact with traditional HTTP APIs. There is also a lot of development activity around GraphQL, which could act as a command line for consuming multiple APIs, thus making integration easier.

    Rodda said the biggest takeaway is that APIs should no longer be treated as byproducts. He compared it to a construction project: When building a house, you must start with a blueprint before installing the foundation, wall, roof or electrical system. Similarly, APIs require solid forethought to ensure stability and scalability.

  • It is Time to Secure Git

    It is Time to Secure Git

    At this point, we’ve got a ton of experience with the bits of Git that we use. And locking down Git is well-documented. Okay, it is documented; we can say that, at least. Interestingly, much of the ‘how to secure Git’ information out there is actually ‘how to keep critical information out of Git,’ and that is the problem. ‘Critical information’ always includes warnings to “not put configuration information into Git. Ever.” And that has been the default way to lock down Git for nearly its entire existence.

    Then along comes GitOps. What is its purpose, in a nutshell? To put that critical information into Git. So we have been waltzing along; only a fraction of us actually locking down our implementation because we were making sure the data in Git, while valuable, was not full of bits of information that would be useful in compromising systems. But now it will be. In fact, in GitOps, nearly everything is one of those bits of information useful to attackers.

    All of which means that it is time to get serious about Git security. Not content, but actual Git security. I won’t go crazy with links to lockdown documents here—it is a vastly different process to lock down a local Git repository versus a remote one and it is drastically different when you’re locking down a service like GitHub or GitLab (actually, some of the work is done for you with a SaaS vendor) … so, you’ll have to look it up yourself, based on your Git implementation. But there are documents out there that walk you through it; you’ll just have to make sure you find the ones that say, “How to lock down Git repositories” and not “How to keep privileged data out of Git repositories.”

    But whatever you do, stop putting it off. Now, if a neer-do-well gets into your repository, it won’t just be source code for various apps that are leaked—and that is certainly bad enough, even if your organization is not a software organization—it will be infrastructure information that can be used and abused. So make certain that information is protected in every possible way. Point security at Git and tell them, “We know you are insanely busy, but this is the most important thing to protect if we are going to implement GitOps.” Because it quite literally is. If database configuration, network configs and possibly even login info are to be stored in Git, locking it down (both local and remote copies) is imperative. You wouldn’t leave that info in plain text on a centralized data store and count on existing protections. So don’t do the equivalent with Git.

    If GitOps isn’t in your immediate future, that’s still your source code full of vulnerability advertisements out there, so at least ask your security team to give your Git install/policies/config a review. Even as a developer, I am less worked up about source code repositories than configuration repositories. There are several reasons for that, but the big one is you all. The bulk of organizations just don’t seem that worked up about source code repository security, but that changes when operations is asked about the list of holes in the firewall being moved into Git—and being configurable from Git (as just one example).

    So, keep kicking it! You all are making, delivering and securing a metric ton of software, and the complexity of our environments did not decrease after the remote work wave hit. Yet, you are still rocking it. May you have enough staff to do the job and applicants that come looking to work with you over competitors. And keep showing the world that software is manageable. But secure your Git.

  • App Store Antitrust Bill | GDPR vs. Google Fonts | Wordle Worth $1M+

    App Store Antitrust Bill | GDPR vs. Google Fonts | Wordle Worth $1M+

    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: The Open App Markets Act polls well among devs, Germany fines a website for using Google Fonts, and the New York Times buys Wordle for an unfeasible sum.

    1. Antitrust Bill Would Open Up App Stores

    First up this week: The Open App Markets Act seems like a big hit with developers. In a survey, more then 80% wanted lawmakers to pass this bipartisan Senate bill.

    Analysis: But 30% of nothing is nothing

    One of devs’ biggest complaints is Apple’s 30% cut of all revenue—including in-app purchases. Many devs have also experienced random rejections of submissions to the stores. And these seem to be the main driving forces behind devs’ calls to tear down any walls around the gardens. But they should be careful what they wish for—users might not see it the same way.

    Karl Evers-Hillstrom: 8 in 10 app developers back measure to rein in Google, Apple

    The Coalition for App Fairness, [an] industry group for app developers, is pushing Congress to pass the Open App Markets Act. [The] bipartisan Senate bill … would block app stores from favoring their own in-house apps in searches, requiring developers to use their payment systems and preventing users from downloading apps from third-party stores.
    …
    Developers surveyed … complained about exorbitant fees … and expressed how they’d experienced difficulty getting their apps featured or accepted by app stores. Just 13 percent of app developers surveyed oppose the bill. … The margin of error is plus or minus 7.11 percentage points.
    …
    The proposal, co-sponsored by Sens. Amy Klobuchar (D-Minn.), Richard Blumenthal (D-Conn.) and Marsha Blackburn (R-Tenn.), is scheduled for a committee markup this week. The CEOs of Apple and Google have personally lobbied lawmakers to abandon [such] antitrust legislation.


    Wouldn’t that just kill the proverbial golden goose? No, says this Anonymous Coward:

    The only reason Apple has any success with the iPhone is because developers write apps for it, it’s no different to Windows in that regard. … If Apple’s app store is so good then everybody from developers to end users will continue to use it and nobody will use third party app stores.
    …
    Obviously there is a clear profit motive to exclude any competition in the app store space. But I don’t understand how people can claim that Apple makes great products and simultaneously argue that they couldn’t possibly survive competition on the platform.


    But Dr. Edith Müdyk—@BabyHueby—doesn’t sound hopeful this will go anywhere:

    Too bad policy isn’t dictated by public opinion.

    2. German Court Fines Site for Using Google Fonts Without Consent

    Did you know you need to get permission from a European user before you remote-load a Google Font? You do now.

    Analysis: Schrems II comes home to roost

    More GDPR popups ahoy! A German court has “clarified” that websites and apps should obtain informed consent before loading content—if loading it would reveal a user’s IP address to a third party. Luckily, the fine was only $110—this time, but if the perp was to do it again, the court threatened 2500× that amount.

    Thomas Claburn: Website fined by German court for leaking visitor’s IP address via Google Fonts

    A German court fined an unidentified website €100 ($110) … for violating EU privacy law by importing a Google-hosted web font. [It] passed the unidentified plaintiff’s IP address to Google without authorization and without a legitimate reason for doing so. And that violates … GDPR.
    …
    The website could have avoided this drama by self-hosting the font. … The ruling explicitly cites this possibility to assert that relying on Google-hosted Google Fonts is not defensible under the law.
    …
    The ruling directs the website to stop providing IP addresses to Google and threatens … a fine of €250,000 for each violation, or up to six months in prison, for continued improper use of Google Fonts. … These data privacy judgments … reflect the consequences of the EU Court of Justice’s 2020 decision to strike down the Privacy Shield data protection arrangements that had previously allowed US companies to exchange data with European partners under “Standard Contract Clauses.”


    Isn’t that ridiculous? And surely not the intention of GDPR? Aristos Mazer very much disagrees:

    This is very much the intended consequence, with a lot of analysis going into this regulation. … Even if that means redesigning foundations of the network.
    …
    Forcing sites to stop transferring data in any way shape or form to Google, Apple, Microsoft, Facebook, etc. … is exactly the goal. [It’s been] repeatedly validated by polls of EU citizens.


    And indeed, the point is to get “informed consent.” Here’s Hans Neeson-Bumpsadese:

    “To proceed beyond this point … your IP address needs to be shared with a 3rd party.” Would they click on that? … I know at least one person who would read that as, “If I click that link then you will tell people where I live.” (I know because they got a pop-up like that once, and phoned me in a state of mild agitation.)

    3. Wordle Sold to NYT for Over $1M

    Josh Wardle, a Welsh developer living in New York, has sold this winter’s social gaming hit to his state’s namesake newspaper of record. The New York Times thinks it’ll be a useful addition to its Games section. But the price tag is incredible.

    Analysis: Nice payday for Josh

    How much? Hard to see how the Times is going to make money out of this. Tomorrow’s word must be: NOROI.

    Alexis Benveniste: The Sudden Rise of Wordle

    In less than six months, Wordle has gone from a gift to a viral sensation, to … part of The New York Times. … Josh Wardle, a software engineer in Brooklyn, created the game as a gift for his partner … and it exploded in popularity.
    …
    Nearly two months later, 300,000 people played it. … The buzz around the game can be attributed to the spoiler-free scoring grid that allows players to share their Wordle wins across social media.
    …
    Wordle was acquired for an undisclosed price in the low seven figures.


    In other words, north of $1 million. Not bad for a quick, one-dev hack by Josh Wardle:

    The game has gotten bigger than I ever imagined (which I suppose isn’t that much of a feat, given I made the game for an audience of one). … I feel so grateful for the personal stories some of you have shared with me.
    …
    [But] I’d be lying if I said this hasn’t been a little overwhelming. [So] I am incredibly pleased to announce that I’ve reached an agreement with The New York Times. … I’m thrilled they will be stewards of the game.


    But “RIP Wordle,” mourns _xeno_, seemingly speaking for many:

    It’s about to be bogged down with trackers, and then later, ads. … A paywall is almost certainly on its way—The New York Times very carefully said it would “initially remain free.” … Not surprisingly, there are already plenty of clones. … There’s no way for the New York Times to make money off this.

    The Moral of the Story: No disguise will hide one’s true character.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Masahiro Miyagi (via Unsplash; leveled and cropped)

  • Linux Foundation Survey Sees Rise in SBOM Use

    Linux Foundation Survey Sees Rise in SBOM Use

    A global survey of 412 organizations published today by the Linux Foundation found nearly half of respondents (47%) producing or consuming software bills of material (SBOMs), and more than three-quarters said they expected to produce or consume them in 2022.

    SBOMs have become a bigger area of focus in the wake of a series of high-profile software supply chain-related breaches. The breaches involved application components compromised by malware that had been surreptitiously inserted during the application development life cycle. The Biden administration has gone so far as to issue an executive order requiring all agencies to provide SBOMs for all the commercial and custom software they use, but as of yet a deadline for compliance with that order hasn’t been set.

    In general, the Linux Foundation survey found that a large percentage of respondents (82%) are already familiar with the term SBOM. Respondents cited various benefits of having an SBOM, including making it easier for developers to understand dependencies across components in an application (51%), making it easier to monitor components for vulnerabilities (49%) and making it easier to manage license compliance (44%).

    However, the survey also makes it clear there is much SBOM work to be done. A full 62% of respondents, for example, are looking for better industry consensus on how to integrate the production/consumption of SBOMs into their DevOps practices. Respondents also cited a need for consensus on the integration of SBOMs into their risk and compliance processes (58%).

    More than half (53%) also said there is a need for better industry consensus concerning how SBOMs will evolve and improve.

    The survey also makes it apparent that organizations are more aware of the role SBOMs play in securing supply chains. A full 80% of organizations are aware of the White House’s executive order on improving cybersecurity, with more than three quarters (76%) considering making changes as a direct consequence of the order. Overall, the survey found the top consideration organizations focus on when evaluating open source software is security.

    Stephen Hendrick, vice president of research at the Linux Foundation, said 2022 is likely to be remembered as the year of the SBOM. There are several standards for building SBOMs, including an open source software package data exchange (SPDX) specification backed by The Linux Foundation and the Joint Development Foundation that is now recognized as the ISO/IEC 5962:2021 international standard. There is also CycloneDX, a lightweight SBOM standard based on an open source project that originated via the Open Web Application Security Project (OWASP) community and a software identification (SWID) standard for tags that some organizations use to create SBOMs.

    SBOMs are, essentially, a tool for listing the components that make up an application and are used inconsistently. However, when a critical vulnerability is discovered, they can sharply reduce the amount of time required to discover all the software components that need to be remediated. The challenge is, with the rise of containers, it has become much simpler to rip and replace software components in a way that may not always be reflected in the SBOM. Hendrick said in time, advances in technologies such as machine learning algorithms should make it easier to instantly reflect those changes in an SBOM.

    Regardless of approach, it’s apparent DevOps teams, like it or not, are about to be held more accountable for the provenance of every component employed across their entire application portfolio.

  • How Does IT Management Govern EverythingOps?

    How Does IT Management Govern EverythingOps?

    The number of tools engineers use to provision software architecture in the cloud is starting to get a little out of hand. There are many competing ways to do one thing. Most often, people simply adopt a new tool to solve a DevOps problem in the moment, not always considering the longevity of the solution or how other departments are handling it. This could result in fragmentation and technical debt, making it difficult to find consistency and increase speed simultaneously across all company divisions.

    I recently interviewed Jeff Kukowski, CEO, CloudBolt Software, to explore why these issues persist and how executives should approach cloud management within their organizations. According to Kukowski, many flavors of Ops now permeate large companies. Different approaches often exist per department or interdepartmental, with teams using various software stacks.

    According to Kukowski, a new frame of mind will be necessary to remain agile in the new cloud order and to address this state. Doing so will require organizations to erode false dichotomies around ownership and IT governance.

    Everything’s Going Ops

    At this point, most large suites of digital services have adopted a complex hybrid and multi-cloud modality. And many teams have embraced their own unique form of DevOps to get a handle on the management difficulties of delivering software and maintaining reliability for microservices architectures. Different groups pulling in various directions create an ongoing battle of EverythingOps, explained Kukowski.

    You can think of it as separate Ops approaches emerging around different business functions. For example, FinOps is emerging to control spending, ITOps is about delivering services, DevOps is improving release fluidity and DevSecOps aims to bring security to the forefront of the release process. Lastly, BizDevOps is about increasing observability for business outcomes.

    At a high level, CIOs have committed to digital transformation to move quicker. Yet the problem now is “battles between different Ops can easily lead to broken IT governance,” said Kukowski. This tension introduces several false dichotomies, he explained. In addition to slowing agility, a lack of DevOps unity eschews reusability, contributing to waste and increased IT expenses, said Kukowski.

    Solution: Shifting Governance Left

    There is a belief in IT that true innovation will come if you only give engineers the keys to use anything they want. While that may be true, without better leadership with regard to the basics in this new cloud order, some things can get out of control very quickly, Kukowski warned. Instead, he argued that built-in guardrails for provisioning tools are necessary. “We have too many tools—we need better frameworks to tie this together.”

    Not only would increased cloud governance help tie together disparate tooling decisions, but Kukowski argued it also can reduce the cognitive load necessary to onboard each tool. “Shifting left will increase speed—it won’t slow people down,” he said. Contrary to popular belief, he said that shifting guardrails left can have the effect of increasing speed, which may greatly outweigh the negatives of shackling developers to a single approach.

    CloudBolt predicted siloed management will shift to organizational governance around tools in the coming year. But it’s not only the tooling decisions that require forethought, “it’s the leadership and cultural approach,” said Kukowski. A common area where greater leadership is required is in tagging workloads for applications, he said. “It’s not being done well anywhere.”

    Or, consider containerization. Containers have become fundamental to most modern cloud technology stacks, yet, the cognitive load required to deploy, configure and run a contain remains quite high, explained Kukowski. Do you allow every developer to custom-code each container, or do you enable a self-service repeatable provisioning process? If standard code is not being reused, you’re not getting speed or governance, he explained. Furthermore, with green IT initiatives becoming a priority, companies should be looking at ways to reuse processes and reduce waste where they can.

    Final Thoughts: Shift Left, Automate and Reuse

    For a cloud-native company, the emphasis is constantly on speed and growth. And engineers are absolutely driving this focus and the resulting innovation. Yet, this innovation can’t come at the expense of bringing all departments onto the same level of innovation. “Innovative stuff in the cloud can’t be separated from governance, ESG and security,” said Kukowski.

    A big hurdle of tomorrow’s cloud management will be identifying and uniting these islands of automation, these pockets of tools and preferences that differ between departments. It will also require a different frame of mind across divisions. “There’s a difference between solving the problem for the task and solving the problem for reuse and speed,” explained Kukowski. Delivering on reuse and speed will require less bespoke DevOps automation and better foundations for solving future problems, he said.

    “Shift left, automate and reuse—people shouldn’t have to touch it. That’s the thinking that needs to be applied to this new cloud order,” said Kukowski.

  • A Pandemic Side Effect: Rampant Technical Debt

    A Pandemic Side Effect: Rampant Technical Debt

    On average, about a quarter of all IT budgets are allocated to handling technical debt each year. And this figure is set to rise, as 68% of organizations say their technical debt will increase in 2022. As digital acceleration continues to drive more IT investment across divisions, the technical burden almost seems like an inevitable outcome of delivering more software and amplifying end-user experiences.

    Unsurprisingly, IT budgets are set to increase this year. This has been a stable trend throughout the pandemic as even companies that are not traditionally technical increased their reliance on software. Most teams quickly moved to remote working arrangements and acquired additional software tools to keep internal operations afloat. Not to mention the new complexities and array of tools emerging to support the microservices design paradigm.

    Although new tech adoption is vital to enable key initiatives across a company, unbridled technical debt can also inhibit digital transformation initiatives. Software AG recently released its Situation Report 2022, a survey that analyzed the state of technical debt among IT professionals in 2021 and technology adoption forecasts for 2022. Below, I’ll review the key points from the report and consider how organizations can respond.

    Increasing Reliance on Tech

    The growth in this area is astounding—78% of companies say their technical debt rose in the last year. A full 38% of companies reported taking on a great deal more; at the same time, IT budgets are set to increase for most organizations in 2022. On average, this increase is expected to be 37.1% higher than 2021 spending. It’s easy to correlate increasing technical debt with these IT budget increases.

    A large portion of this increased spending is related to digital transformation. This checks out; modernizing existing technology is a top priority for 19% of tech leaders. Other top priorities include exploring new technologies (17%) and decreasing technical debt (15%). Though managing technical debt is not ranked as the highest priority for IT leaders, it still ranks as a pressing concern due to its ability to hurt innovation. The report found that 69% of companies admitted it has caused their digital transformation initiatives to slow.

    Perceptions of Technical Debt

    So, what are the leading causes of technical debt? It turns out that most stems from recent modernization and digital transformation efforts. In fact, 39% said new digital products were a major cause. This is followed by infrastructure modernization (34%), data analysis and integration (32%) and new customer-facing services (27%).

    Interestingly, not all technical debt is bad. Often, IT professionals say the benefits justify the expense. For example, 86% say that increasing product or service launches justifies taking on tech debt.

    Technical debt is also a result of the remote nature of today’s hybrid work environment. During the pandemic, businesses made many concessions to enable remote work and adopted new collaboration and development tools to enable productivity. As a result, 88% reported the pandemic increased their awareness of technical debt. The majority, 83%, also said the pandemic has increased acceptance of technical debt, a sign that many of these changes are here to stay in the new normal of working life.

    Responding to Technical Debt

    Not all investments lead to the same degree of technical debt; some platforms are bulkier than others. Or, specific software vendor lock-in schemes can prevent lift-and-shift which can swell a technology ecosystem. So, what areas are companies investing in and which are the leading causes of technical debt?

    In 2021, companies invested heavily in cloud computing (60%), integration (43%), IoT (39%) and 5G (39%). Investment strategies will change slightly in 2022, with 5G becoming the top most-invested area at 45%. Cloud computing drops to 42% and edge computing is rising to 35%. Mapping where new investments will occur can help organizations anticipate the repercussions. Of these investments, 60% of IT professionals ranked 5G as a leading cause of technical debt. Other high producers include cloud computing, IoT and blockchain.

    In 2021, companies spent 24.8% of their IT budget handling technical debt. Managing it presents some significant challenges—32% say siloed data and processes are a key challenge when addressing technical debt. Limited budgets, regulations and a lack of internal alignment also get in the way. Clearly, resolving the issue requires both inter-department collaboration and a hefty budget.

    Final Thoughts

    Technical debt is, arguably, unavoidable as companies adopt cutting-edge technologies to remain relevant. And, taking on more technical debt is often intentional; for example, new DevOps tools are helping increase deployment fluidity and manage complex cloud-native architectures. Or, new SRE platforms bring observability and monitoring capabilities to improve application reliability. A newer programming language may be more performant, while a low-code abstraction layer complements an engineer’s workflow. In all these scenarios, the benefits often outweigh the added debt.

    Yet, much of it is unintentional and is slowing innovation down. This could be shadow APIs or forgotten rotting legacy infrastructure. Sluggish code and un-optimized routing between applications can also be a drag on resources. The reason these situations sound murky is because technical debt, itself, is difficult to quantify. And, only those addressing it with adequate visibility into their stack will have a clear indication of how much debt there really is.

    Though the current pandemic has indeed amplified technical debt, things will always evolve and new trends will replace the old. In the digital era, some degree of tech debt is inevitable within a large organization. The key will be effectively managing it over time to maintain a healthy, lean codebase and progressively release features that meet the demands of new customer experiences.

    The Software AG Situation Report 2022 surveyed 700 IT professionals on their software usage and annual predictions at the end of 2021. For more insights, you can read the full report without an email gate or paywall here.

  • Google FLoC is Dead | Meta AI Supercomputer Lives | ARM Deal is Dead

    Google FLoC is Dead | Meta AI Supercomputer Lives | ARM Deal is Dead

    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: Google’s FLoC proposal is dead, Meta/Facebook is buying RSC—a huge AI supercomputer, and Arm “will IPO” instead of selling to Nvidia.

    1. Forget ‘Federated Learning of Cohorts’—Long Live ‘Topics’

    First up this week: Google bows to the inevitable. Third-party cookies will soon go away, because people are fed up with being tracked. But Google’s FLoC proposal wasn’t the answer.

    Analysis: FLoC is a flop

    Google doesn’t want to invade your privacy. But Google does want to sell well-targeted ads. The key difference between FLoC and Topics is that FLoC buckets were automatically generated—and hence opaque, risking overlap with “protected categories”—e.g., race or gender. But the topic classifications in the Topics API are curated and have user-visible, descriptive names.

    Frederic Lardinois: Google kills off FLoC, replaces it with Topics

    Google’s controversial project for replacing cookies for interest-based advertising … is dead. In its place, Google today announced a new proposal. … Your browser will learn about your interests as you move around the web.
    …
    When you hit upon a site that supports the Topics API for ad purposes, the browser will share three topics you are interested in. … The site can then share this with its advertising partners to decide which ads to show you. … Users will be able to review and remove topics from their lists [or] turn off the entire Topics API.
    …
    It’ll remain to be seen if other browser vendors will be interested in adding the Topics API. [But] they all quickly turned a cold shoulder to FLoC. … The plan is to start trialing the Topics API at the end of this quarter.


    A minor tweak and rename? “Yes and no,” equivocates mananaysiempre:

    Yes, it still amounts to building user-tracking functionality into user agents. No, it’s not the same approach.
    …
    FLoC was doing unsupervised clustering of users, whereas Topics allocates users into predetermined clusters. This makes it potentially more transparent and also seems designed to work around the “protected categories” objection.


    But Google has a long way to go to convince garett_spencley:

    I’m glad FLoC is being ditched, but as an end-user I’m still not asking for this Topics nonsense. It doesn’t solve any problem that I have. It solves problems that the advertising industry has.
    …
    I’ll choose to use browsers that don’t support this.

    2. Machine Learning at Metaverse Scale is Expensive

    Zuckerberg’s new toy is RSC: A $400 million Nvidia-based AI supercomputer. And that’s just Phase One.

    Analysis: 3.8×1018 integer operations per second is … a lot

    If you rely on Open Compute Project systems for your DevOps, know that it’s no longer the bee’s knees over at Hacker Way. Meta/Facebook is investing eye-watering sums into a custom configuration of off-the-shelf hardware.

    Timothy Prickett Morgan: Meta Buys, Rather Than Builds And Opens, Its Massive AI Supercomputer

    If you thought it took a lot of compute and storage to build Facebook’s social network, you ain’t seen nothing yet. … To build the Metaverse … is going to take an absolutely enormous amount of supercomputing power.
    …
    But what is a surprise, given Facebook’s more than decade long focus on … opening up its hardware designs through the Open Compute Project, is that the … Research Super Computer [RSC] system is built from … commercially available … servers, storage, and switches. [It] probably comes down to … working a deal with some vendors who want the Facebook publicity and are willing to work the price and the parts availability.
    …
    [So Meta bought] 760 DGX A100 systems from Nvidia—which each … have a pair of AMD “Rome” 64-core Epyc 7742 processors … 1 TB of main memory … eight A100 GPU accelerators [and] eight 200 Gb/sec HDR InfiniBand controllers—all-flash storage from Pure Storage, and … caching servers from Penguin Computing. … At list price this machine would cost around $400 million … Phase one of the RSC machine is rated at 59 petaFLOPS … (FP64), and 118.6 petaFLOPS FP64 using the Tensor Core matrix engines. … With INT8 processing on the Tensor Cores, which is needed for AI inference, the phase one machine is rated at 3.79 exaOPS.


    How much??? It doesn’t seem like news to kleiba:

    I used to work at a university where my professor had been in automatic speech recognition for a long time, but basically gave up on that line of research about 10 years ago because he figured that universities simply cannot compete budget wise with the big industry players. I suppose the same will soon be true for most ML-related areas of research sooner or later.
    …
    Already, a substantial amount of research innovation in [Natural Language Processing] and [Computer Vision] has been coming from big companies in recent years. Of course there is a discussion to be had about what that means for society at large.


    But 3.79 exoOPS? That’s the way the wind is blowing, according to sungazer:

    Give it 15 or so years—this level of computation will be on your desktop. If desktops still exist.
    …
    Or desks.

    3. Arm Bid: No Legs

    Speaking of Nvidia, as I’ve said before, the Arm merger really shouldn’t go through. And it’s looking less and less likely. ARM chips are an increasing fixture in the data center—especially those that value “performance per Watt.”

    Analysis: ARM M&A DOA—IPO PDQ

    A veritable hornets’ nest of Bloomberg journalists have put their names to an anonymously-sourced report. The story argues that the proposed Nvidia buyout of Arm from SoftBank Group is dead. Next stop: IPO.

    Ian King, Giles Turner, Peter Elstrom, Dina Bass, David McLaughlin, Ruth David and Dinesh Nair: Nvidia Quietly Prepares to Abandon … Arm Bid

    According to people familiar with the matter … Nvidia … doesn’t expect the transaction to close. … SoftBank, meanwhile, is stepping up preparations for an Arm initial public offering.
    …
    If Nvidia manages to get the deal over the line, it would be a massive coup. … But it will be an uphill fight. … The world’s biggest tech companies rely on Arm technology, and they fear they could lose unfettered access under Nvidia.
    …
    Within SoftBank, there are factions. [And] the ordeal has created divisions within Nvidia. … “We remain hopeful that the transaction will be approved,” a SoftBank spokesperson said in an emailed statement.


    Post-Brexit Britain would no doubt like to keep Arm independent. Here’s simonh:

    Arm has I think ⅔ of its employees in the UK—mainly Cambridge—and they’re expanding the campus there. The Semiconductor Physics Group at the Cavendish Laboratory at the University is at the cutting edge globally with 18 PhD projects currently.
    …
    Guess where scads of Arm’s top scientists are recruited from? Arm and the University are joined at the hip. That company’s not going anywhere.


    More broadly, it’s good news, thinks hatchet:

    Hopefully this means NVIDIA will focus on RISC-V instead. This will be good for everyone.

    The Moral of the Story: Zeal should not outrun discretion.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Reed Geiger (via Unsplash)

  • AI: It’s What Staff Crave!

    AI: It’s What Staff Crave!

    If you’ve seen Idiocracy (Side note: I am not recommending the movie; I’m using a phrase from it we’ve all heard. The movie itself was a comedy not at all meant to be family-friendly when it was made, and changes in social mores since its 2006 release make it far less acceptable today), you are familiar with the title phrase I’ve used here. That’s what is repeated almost religiously to justify why they buy/use/drink Brawndo, an energy drink.

    One of the scenes involves people telling the star that plants need Brawndo—“It’s got electrolytes … That’s what plants crave!” This is repeated over and over until he asks, “What are electrolytes?” After some stuttering and failures to answer, someone says, “It’s what they make Brawndo out of.” Someone else inevitably tacks on, “It’s what plants crave.”

    Now, substitute “AI” for “Electrolytes”. That’s where we seem to be. Ask a vendor what algorithms they’re using, where their training data comes from, the difference in results between the test reservations and the real world. Most will end up saying a lot, not answering your questions and ending with, “It’s what staff crave!” or some such.

    A few companies will lay it all out there, assuming you can parse through the information and are familiar with the AI training algorithms they are using or the algorithms they’re using to classify inputs against the dataset. And these companies are grand because they (a) know what they’re actually doing beyond “It’s got AI/ML, it’s what staff crave,” and (b) Expect that you are knowledgeable about the data you’ve asked for or are capable of looking it up in this age of wonder that has boundless information at your fingertips.

    Don’t let your vendors get away with just repeating “It’s got electrolytes” over and over. AI and ML are a massive help in some areas, but they’re not yet a panacea and success rates vary wildly whether we’re talking problem domains, datasets, algorithms, training style, etc. Make them tell you the details. Where the data comes from and how big that dataset is. How much was reserved for testing and whether it was reserved randomly. Ask them what they hope AI will achieve, then ask them how that correlates to human interaction. Most AI today is still evaluating or replicating human interactions with something—most AI in IT particularly so. What algorithms were used to validate? And finally, make sure to ask for real-world results. I know people in data science and one has confidently said to me, “My models are 95% accurate.” When I finally dug into that claim (because my experience is that real-world use of AI/ML is almost never that accurate) it turned out that claim was true … for the reserved test data. So, the same dataset used to train got the same results on the reserved subset. That’s a good thing, but it is no indication of how said algorithm will do in the wild with unfiltered data. The big problem really is the switch from test data to real-world data.

    In fact, in IT, we are a little better off than most spaces wrestling with AI/ML, because very often there is no difference between test and training data in IT. A network security vendor will test against actual traffic—because they have access to massive volumes of it and it shortens the iterations to use what’s at hand and what the system is being trained for.

    And keep rocking it. The current iteration of IT is the opposite of the dark comedy future depicted in Idiocracy. You all are putting up systems and keeping them running at increasingly fast cadences; sometimes remotely because of COVID-19 or other work-related issues. Don’t stop turning out success for your coworkers and customers and take a moment to force vendors to explain what they’re doing with AI. If you’re a generalist like me, ask over email, though, so you can go look up the answers and make sure you understand the details.