Category: Doin’ DevOps

  • How to Supercharge Your Engineering Teams

    How to Supercharge Your Engineering Teams

    With the economy still bleak, data and engineering teams that were already struggling to keep pace with business needs are now facing a potential hiring freeze or worse in 2023. That’s why there’s never been a more important time to maximize the productivity and impact of your teams, but the question is how to identify the big changes that move the needle in performance. Incremental adjustments that save a sliver of time here and there are not hard to come by, but what teams need are the breakthroughs that yield giant leaps in productivity and efficiency. Rather than a 10% improvement, it’s the 10x improvements that drive lasting gains.

    As an engineer and CEO of a software company, I’m constantly looking for ways to boost the productivity of our teams. Our guiding principle is simple: Maximize the impact per hour invested for every individual. To do that, we must ensure that individuals maximize the time spent flexing their superpowers, minimize busy work and reduce dependencies on others that delay work or tie them up in meetings. While counterintuitive at first, we consistently find that collections of well-aligned, independently executing individuals produce a far greater impact than a large team swarming on a project. Put another way; the individual impact goes up when the number of people you depend on to deliver the result goes down.

    I’ve developed an approach over the years that has allowed me to identify several opportunities for step-change advancements in productivity and efficiency, and I’d like to share it here, along with two concrete examples. I will also share an exercise we run with our teams to help identify and execute these opportunities.

    First, here are my two main criteria for identifying the projects and tasks where we can effect changes that will have an outsized impact on the company:

    ● Big resource-consumers: Work that’s essential to the business but consumes a large amount of engineering and other resources is a top candidate for optimization.
    ● Big impact, easy win: Areas that will have a significant impact on company performance if we can do them faster and with higher frequency are also great candidates—even if they’re not consuming a ton of resources.

    Here are two examples that illustrate each of those criteria and where we were able to see massive gains in productivity, quality of service, or both.

    Tackling Big Resource-Consumers

    At Ascend.io, we provide a platform for building and automating data pipelines, which requires us to build connectors into a huge variety of data sources. At one time, building a new connector required multiple engineers to spend two to three weeks writing more than 5,000 lines of code that spanned four microservices in three different languages. As we added more customers and needed to support more data sources, this quickly became unsustainable.

    When we looked at this process, we saw two issues: Engineers were writing custom code for each connector in a way that would be better served by a common framework. Moreover, the process required engineers from multiple teams and disciplines to work together and coordinate their priorities. As soon as you get dependencies that require engineers to coordinate with others and wait on the outcomes of other people’s work, you’re wasting time.

    We addressed this by designing a new development framework that exploits commonalities across the connectors we build. This now requires far less unique code and removes the need for multiple engineers to work together. In most cases, one person can build a new connector in days with 100 lines of code. This made us far more nimble and freed up engineering time to do other valuable work.

    Achieving High Impact

    Like most companies building software, we need to convey the capabilities of our product to new and existing users to ensure they receive maximum benefit from their use of Ascend. With new features and enhancements being released on a weekly basis, there is a lot to keep up with. This is high-impact work, however, and if we can do it in a vastly better way, it drives an outsized impact for Ascend and our customers.

    For us, building these automated product tours typically required a product marketer or product manager to design the customer journey, and one or more engineers on a sustained basis to build the actions into the product. This again creates dependencies that slow progress and require significant manual coding.

    The breakthrough for us was a tool called Intercom, which allows you to build sophisticated product tours without needing to write code. Our product team can now build more interesting and complex product tours for customers, and our engineers can stay focused on building new features instead of the code needed to showcase them. What’s more, they are able to design, test and deploy these tours independent of our product and code deployment cycle, further freeing them to iterate as fast as possible.

    A Thought Experiment

    So how do you actually find these opportunities for 10x improvement? I run the following thought experiment with our teams several times a year to uncover these opportunities:

    Imagine your workload scales 10x overnight and you absolutely must meet this increased need, but without hiring more engineers or working more hours. How do you do it?

    It’s amazing what this exercise can uncover—but there are ground rules and it can take time to see results. Coming up with these big ideas is a skill like any other, and most people are not great at it the first time they try it. Your first iteration may produce no options to pursue—some may have high-impact ideas but with even higher investment requirements, while others may reject the premise outright. That’s normal. So, don’t insist they sit in a room until they dream up that 10x breakthrough, because it will be demoralizing. Instead, plant the seeds by establishing the above framework and then let the ideas start to grow.

    More likely, a few days later, they’ll be out for a hike or chatting with an old co-worker and they’ll suddenly have the germ of an idea. That may still not be the winning solution, but someone else will build on it, and then someone else and, finally, you iterate your way to a breakthrough. Pulling the team back together and embracing the “yes, and” approach can be both energizing and highly productive.

    Brainstorming like this is fast and free, and you only need one great idea to have a material impact. We run this exercise a few times a year and have come up with several big ideas that were game-changers for the company. Besides the examples above, we also moved key parts of our software development from Scala and Go to Python a few years ago, which is a much more efficient language (as measured by developer time) and allows our engineers to build things much faster.

    Software engineering is a complex beast that often spans many teams working on multiple processes in parallel. But that complexity is also your opportunity: Every complex system has room for optimization, especially at companies that moved fast in the beginning to build a product and find market fit. Now is the time to lift your gaze, look around and ask where significant gains can be made. They almost certainly exist, and a 10x improvement could be what allows you to not only survive the turbulent year ahead but emerge with a thriving team and business on the other side.

  • 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:

    LinkedIn

    M-Logic
    Dallas, Texas/Chicago, Illinois
    Security Engineering – DevOps
    $150,000 to $160,000

    SimplyHired

    Cisco Systems
    Waltham, Massachusetts
    DevOps Engineer
    $134,200 to $197,700

    Indeed.com

    AT&T
    McLean, Virginia
    DevOps/Python Specialist
    $111,000 to $140,000

    Monster.com

    Capgemini FS
    Charlotte, North Carolina
    AEM Full Stack Developer
    $110,000 to $130,000

    Dice.com

    Booz Allen Hamilton
    McLean, Virginia
    Lead DevOps Engineer
    $99,300 to $212,000

  • Bug Bounty Vs. Crowdtesting Programs

    Bug Bounty Vs. Crowdtesting Programs

    Digital quality and excellent user experiences are more important today than ever. When a digital experience doesn’t work as expected or is rife with friction points or glitches, customers are quick to give up and move on to a better, easier solution. Bugs and defects often come with high stakes and can result in loss of revenue, dissatisfied customers and potential damage to a brand’s reputation.

    With this in mind, software testing is tasked with the important role of catching and fixing bugs and defects before they hit production. There are several approaches to finding bugs in software, two of which are bug bounty programs and crowdtesting. In this article, we’ll examine the values of each.

    Bug Bounty Programs

    A bug bounty program typically involves people outside an organization with software testing experience, leveraging their expertise to hunt down product defects in exchange for money. Bug bounty programs can be a cost-effective way to find defects that otherwise go unnoticed. They provide an outside perspective and a sanity check for digital products to find vulnerabilities and defects.

    From a security perspective, bug bounty programs are also valuable. Today’s security teams have trouble managing the sheer volume of software vulnerabilities found in software. That’s part of the reason behind the growing number of cyberattacks and breaches that continue to be a topic of discussion. Bug bounty programs leverage white-hat hackers to find and report vulnerabilities in an effort to improve overall security posture and support the organization’s own cybersecurity team.

    Bug Bounty Benefits

    Bug bounty programs offer a variety of benefits to organizations, including:

    ● Helping with blind spots: It doesn’t matter how well your software is designed and coded. Defects and bugs, whether minor or major, will find their way into applications. The developers themselves and internal testing teams may only test certain paths based on organizational norms. Bug bounty testers offer a fresh perspective that can help reduce overall blind spots in application testing.
    ● Resource flexibility: Most organizations don’t have the flexibility to scale internal resources on short notice. Bug bounty programs offer outsourced help and are flexible. They can be scaled up if needed to help with finding defects before a major launch. Or, if a business needs to save money, it can be scaled down by either reducing payouts or limiting testers to high-value defects.
    ● Continuous evaluation: Whether an application is in use by customers or is just a prototype, a bug bounty program can go to work finding and revealing bugs and vulnerabilities. Bug bounty programs can continuously search for bugs that help improve the quality of an application.

    Bug Bounty Challenges

    While there are some great benefits to using bug bounty programs, there are challenges, as well, including:

    ● Money focus: As the name suggests, this is a bounty program. High-severity defects come with a higher payout. If a large percentage of bug bounty hunters are focused on high-severity bugs and vulnerabilities because of the higher earning potential, they may miss the smaller defects. This can add up and result in a less-than-ideal user experience, with smaller issues going unfixed.
    ● The perspective of the tester: No matter how experienced and skilled a tester is, everyone is limited by their own blind spots and perspective. A diverse group of testers can help offset this, but there is still no guarantee that they will test the product in the same way that customers will use them. This challenge is multiplied when we add in different devices, operating systems, languages, and locations. Bug bounty hunters may be more focused on finding high-value issues to earn more, while an internal tester may be more invested in a specific product or feature and making sure it works as it should.
    ● Communication: Many have gotten used to working from home or from anywhere and collaborating remotely. Bug hunters work like this too, but they are outsourced assistance from an organization, which requires a bit of extra thought for communication, project scope and qualifications to make sure misunderstandings or lags in progress are kept to a minimum.

    Crowdtesting

    A crowdtesting model leverages skilled testers and testing teams that can be sourced from a globally dispersed community of independent digital experts. Depending on the size and diversity of the community, testers can apply a nearly limitless variety of demographic characteristics, locations, skill levels, spoken languages, abilities, devices, browsers and operating systems into a testing scenario. This breadth of feedback provides valuable insights into how real users will interact with an app, device or digital experience—which may not necessarily be the “typical” way it is intended to be used. This real-world interaction can unearth bugs, friction points and localization issues that may otherwise go unnoticed before the experience is released to actual customers.

    The remote and on-demand nature of crowdtesting provides scalability and timely results in comparison to more traditional testing methods, like offshoring or lab-based testing, which are typically more limited in scope and flexibility. Plus, the crowdtesting model inherently provides the ability to scale testing services up or down as needed to meet the project-based requirements of a company’s internal teams.

    Crowdtesting Vs. Bug Bounty Programs

    Both bug bounty and crowdtesting programs involve digital experts looking for app defects and vulnerabilities with the goal of improving digital quality. These programs can be aligned in this goal and even work in tandem, but there are some notable differences between them worth mentioning.

    ● Scope: Bug bounty program scopes will always be somewhat limited. Defects can be found outside of the payment scope and go unflagged. Crowdtesting allows for either a broader or more specific scope, depending on needs. Organizations can give specific instructions, like making sure UX considerations are taken into account.
    ● Volume: Both crowdtesting and bug bounties rely on skilled professionals who know how to root out bugs and defects. Crowdtesting, however, allows for as many or as few testers as needed. Instead of gathering a moderate amount of defects from a more technical audience, crowdtesting enables testing for any amount of defects from a diverse and vast pool of testers. As a result, crowdtesting finds a larger variety of defects, and across more devices, locations, and OS versions. This can also be a challenge, as internal staff can become overwhelmed by so many bug reports to look through and address. Therefore, prioritization is key.
    ● Flexibility: Digital quality is a multi-faceted process. It’s not just about functional and security bugs but also accessibility assessment, making sure to test using specific devices and use cases, and more. Bug bounties fall short here, while crowdtesting delivers the flexibility to test and address situations your potential customers may face when an application is live.
    ● Specificity: Most bug bounty programs are not tailored. They can be application- or region-specific, but that doesn’t always reflect a target customer use case. Crowdtesting enables an organization to focus on specific demographics in terms of user experience. An organization can specify testers in certain locations with a certain device or devices and who speak specific languages. Crowdtesting isn’t always just about technical ability; it’s about finding the correct group of people needed for the task at hand.

    Both bug bounty and crowdtesting programs provide unique benefits that help organizations improve overall digital quality. Bug bounty programs offer help with organizational blind spots while leveraging testing professionals in a flexible way. Crowdtesting enables businesses to harness the power of real people using actual devices out in the world to test for use cases. It delivers the power to augment internal testing initiatives, helping to improve overall quality, usability, accessibility and more. When improving digital quality and user experience are the goal and end result, bug bounty and crowdtesting programs can each be impactful and helpful for today’s businesses and for improving the user experience.

  • Neural Hashing: The Future of AI-Powered Search

    Neural Hashing: The Future of AI-Powered Search

    In recent years, vector embeddings have emerged as a promising technology to power information retrieval projects. Vectors use mathematics to represent words and encapsulate meaning. Combined with deep learning algorithms, you can build powerful AI search applications. However, recent advances have shown that another kind of technology – neural hashes – can outperform vectors while avoiding the tradeoffs that people experience with vector search.

    Neural hashing’s superiority over vectors will soon make it accessible, affordable and the primary method for delivering AI-powered search for e-commerce, enterprise search and other areas where search data is constantly growing and changing. Even as early as 2023, neural hashing will be the primary method for delivering AI-powered search.

    First Came Keyword Search

    Most of us are familiar with the basics of keyword search technology, which most search engines still use. When someone submits a query, the keyword search engine will perform a simple lookup and display results by relevance. Keyword algorithms employ techniques such as natural language processing (NLP), lemmatization, typo tolerance, synonym libraries and more to perform the lookups.

    Keyword search engines work well for the most part but can fall short when it comes to long-tail queries, i.e., those longer and more specific queries which represent half or more of search queries. Despite its powerful keyword technology, you can never write enough rules or stuff your site with enough keywords to cover every edge case. Being able to improve long-tail query results, however, can be a huge benefit to an organization, which is why more companies are beginning to look for new technologies to complement their keyword search engines.

    Then Came Semantics

    Semantic, or AI-powered search, can understand concepts. Semantic search goes beyond matching to understanding. For example, if you searched “something for a headache” on a website, a keyword search engine would look for items tagged with those specific words, turning up results only if they can match some or all of the text. But a semantic search engine would understand the concepts being described and offer solutions—such as pain medications.

    Semantic search has traditionally been employed using vector embeddings. You can use vectors for all kinds of objects, too—images, videos, audio, etc. Vector-powered search engines can be incredibly smart, but processing and maintenance make them too expensive to run in production for most enterprise use cases. This is true, especially for certain industries where data is dynamic. In retail and e-commerce, for example, that inability to pivot and scale quickly is a real detriment, as brands need to update data that is unpredictable (e.g., user-generated content) and constantly in flux (many online sellers update their search databases hourly).

    The solution is neural hashing, which refers to the process of compressing vectors with neural networks (deep learning algorithms which mimic the human brain) into hashes or binary vectors. These hashes retain 96% or more of the vector information while using a fraction of the storage space. A semantic search engine built using neural hashing is nearly or just as accurate as vector search but about 500 times faster.

    Better Results With Hybrid Search

    When it comes to AI-powered search, neural hashing will eliminate the tradeoffs between speed, accuracy and costs. It can deliver results in single-digit milliseconds with no additional overhead. As good as it is, it’s even better when combined with a keyword search. We can use hybrid search—both technologies—simultaneously; most queries are a combination of keywords and concepts.

    For example, what if rather than looking for a type of product, a shopper is searching for help with getting rid of a pesky symptom? Or, has a question-style query? As search data indicates, people are often myopically focused on a problem that they desperately want to solve, such as:

    ● Leaky faucet
    ● Stress headache
    ● Stained carpet

    They only know they have an urgent problem. Of course, they’re looking for a solution, but they typically have no idea what particular product they need in order to get relief. They’re still using some keywords, however, like “faucet,” “stained” or “carpet.”

    Each query can be scored by both the hashing and keyword engines to deliver a superior result for every query. Hybrid search can be combined with traditional search engine features like natural language processing (NLP), autocomplete, learning-to-rank algorithms, filters and more to optimize the end-user experience.

    When it comes to search, speedy, accurate results are the name of the game. In order to make searches as intuitive, fast, and scalable as possible while still remaining cost-effective, search and discovery platforms should explore what hybrid search powered by neural hashing has to offer.

    It has been shown that neural hashing can make highly intelligent AI fast and cost-effective at scale and without the need to bring on highly specialized engineers for every project. We appear to be at another turning point in the world of artificial intelligence, and neural hashing is going to be the driving force behind many future innovations.

  • What NetOps Teams Should Know Before Starting Automation Journeys

    What NetOps Teams Should Know Before Starting Automation Journeys

    Automation has captured the human imagination since the earliest days of recorded history. A fanciful example of this comes from Homer’s classic “The Iliad” in the form of a bronze robot called Talos, which was designed to automatically monitor and defend the island of Crete from marauding intruders. The appeal of automation for IT organizations, including network operations (NetOps) teams, may not be so life-and-death but it’s undeniable, nonetheless. More and more NetOps teams are turning to automation to achieve higher network uptime (by reducing manual errors), increase efficiency and reduce costs and help deliver a better and more consistent operational experience for all users.

    Due to the allure of these promised benefits, the temptation for NetOps teams to integrate automation as soon as possible may be strong. However, it is important for these teams to remind themselves that automation is a tool, not the destination itself. Indeed, simply overcoming the technical challenges of deploying automation may not result in the successful outcome teams want, without identifying and defining the intended outcome of what their automation journeys should be.

    This article will explore some practical steps and best practices that NetOps teams should use throughout their own automation journeys.

    Getting the Journey Started on the Right Step

    A well-known maxim in business is that you should visualize success and start with the end in mind when embarking on a major project or initiative. This is a good reminder for NetOps teams as they begin their automation journey. That is, these teams should be able to answer the question, “What is our desired end state when it comes to automation?” before they even evaluate what tools or technologies they may want to consider.

    Teams who have this mindset will have a clearer understanding of their overall mission as well as an enhanced view of the various projects, processes and products they can improve through automation. It is critical for NetOps teams to take the time to put in the work of defining the desired IT experience at the end of the automation journey, even if the task itself may be difficult. For example, this experience may help define how NetOps engineers will interact with an automation tool through its code, its dedicated user interface, or even its generic service portal. As the saying goes, “no pain, no gain.” The teams who invest in the time and effort to plan ahead will be far more likely to maximize the benefits of automation.

    What to Automate?

    In addition to visualizing what success looks like, it is important for NetOps teams to identify what tasks or processes they should be automating. This is important because there is a vast universe of NetOps tasks that can be automated. Taking the time to identify tasks to be automated will generate huge benefits for the NetOps team as it will help them select the correct automation strategy and toolset that will deliver them the results in an efficient way. And while specific projects may be unique to each NetOps team, in general, there are two broad categories of tasks that are ideal for automation:

    1. Highly repetitive tasks. These are manual or semi-automated tasks that are not necessarily hard but can be cumbersome for NetOps teams. Examples of repetitive tasks that can be automated include assigning an interface into a specific VLAN or perhaps updating network security policies or rules.

    2. Highly complex tasks. These can be more strategic and difficult tasks that can be prone to human error due to their scope, scale, and complexity. Automating these tasks may require additional planning and steps to ensure success. Examples of complex tasks that are ideal for automation include service redirection from one device to another or BGP peering with third parties.

    Think Big, Start Small With NetOps

    Like all people, NetOps professionals enjoy the results of a job well done. So, while the vision of their automation journey may be big, it’s important to start with a small, short-term project that can be completed quickly. There are a couple of benefits to this approach:

    1. Quick automation wins will give NetOps teams confidence for future projects.
    2. Projects like this can generate data and feedback that NetOps teams can convert into learnings and insights for the next project.

    This approach can also be applied to bigger, more complex automation projects. Instead of taking on the entire scale of the project at once, NetOps teams can break it down into smaller components. For example, infrastructure-as-code (IaC) is a broad category of automation entailing the managing and provisioning of systems through machine-readable definition files. There are many considerations to large-scale IaC projects such as identifying the use case, e.g., Day 0 or Day 2 operations. The advantages of this approach are the same as with the quick-win scenario: There is a better likeliness of success and more immediate feedback and data to guide the NetOps teams through this entire process.

    Finally, as talented as most NetOps teams are, they are not likely to have all of the automation expertise in-house at any given time. So, it is important that they address skills gaps (automation, programming) through strategic vendor partnerships, internal/external recruitment and additional training for their teams. Again, instead of recruiting or investing en masse, NetOps teams are well-advised to take the time to plan, execute, learn and modify as they go along.

    Summary

    The human fascination with automation is stronger than ever. The industry buzz around one particular form of automation—especially artificial intelligence and machine learning—is indicative of this. NetOps teams have much to gain from investing in the tools and skills required to do automation right.

    Automation of data center network pods, self-contained zones that represent a section of the overall data center, is a good example of a strategic project requiring forethought and planning to execute well. A logical first step in this process might be to anticipate how to manage future changes when automation is in place. Options for this may include code manipulation, Git (open source code management) or CI/CD pipelines, all elements of infrastructure-as-code automation. Or it may involve improving user experience through a specific UI interface or through a self-service portal. The next step then might be to decompose this large configuration into smaller bits starting with the registration of the new switches into the controller. Once this is done, we can now go into port configurations and then eventually move toward larger and more sophisticated elements such as the automation of VLAN assignments and L3 peering.

    For long-term and large-scale automation projects like this, it is especially important to follow the recommended key steps outlined in this article, which are:

    1. Start with the end in mind. It’s critical that the teams take the time and effort to define what success looks like, especially in the form of the IT experience they want to achieve.
    2. Know what you want to automate. There is an endless supply of tasks and processes that can or should be automated. Prioritizing automation projects that NetOps wants to take on is a major milestone in any automation journey.
    3. Think big, start small, learn as you go: Quick automation project wins are key to building confidence and “muscle memory” for future projects. For bigger projects, the best approach is to break them down into more manageable projects that can provide vital data and insights during the journey.

  • How Bazel and GitHub Can Fix the Dependency Availability Problem

    How Bazel and GitHub Can Fix the Dependency Availability Problem

    Recently, GitHub upgraded the internal version of Git they use to produce repository archives. You’ve probably used these archives before if you’ve downloaded a .zip or .tar.gz file from a repository at a particular version. GitHub produces those archives on demand using Git archive and caches them for a short time.

    Upgrading Git regularly is a generally good idea, but this change regrettably broke a huge number of Bazel projects. Bazel is a widely used, free, open source tool for building and testing software, so this breaking change is a big deal. What happened? Most Bazel projects fetch at least some of their dependencies using rules in their WORKSPACE files like this:

    http_archive(

    name = “com_github_bazelbuild_buildtools”, sha256 =

    “05eff86c1d444dde18d55ac890f766bce5e4db56c180ee86b5aacd6704a5feb9”, strip_prefix = “buildtools-6.0.0”,

    urls =

    [“https://github.com/bazelbuild/buildtools/archive/refs/tags/6.0.0.ta

    r.gz”],

    )

    See that /archive/refs/tags/ part of the path? That’s the endpoint I’m talking about.

    This is bare-bones dependency management: Bazel attempts to download an archive from the first URL in the list; it tries the next URL if the first is not available and so on. Bazel then checks the file’s SHA-256 sum against the known value and, if it’s correct, extracts the archive and proceeds with the build.

    The Git upgrade caused a change in archives’ SHA-256 sums. I think there was a small change in zip compression, but it doesn’t really matter—any variation in file ordering, alignment or compression causes the archives’ SHA-256 sums to change even though the extracted contents are the same.

    This is at least the third time Bazel builds have broken that I can remember. This has also been discussed extensively before. I’m writing this in the hope that we can make our systems more resilient and avoid these kinds of problems in the future.

    Since GitHub made the change that triggered this, they naturally get the immediate blame from the community, though I think it’s mostly undeserved. Upgrading dependencies (especially Git and especially if you’re GitHub) is a reasonable thing to do. To my knowledge, GitHub has not documented a guarantee that files returned by the archive endpoints have stable SHA-256 sums. It’s a mistake for users to rely on a guarantee that was never made. It’s tempting, of course, because it’s easy, but it’s a mistake nonetheless.

    This is a classic example of Hyrum’s Law:

    “With a sufficient number of users of an API, it does not matter what you promise in the contract: All observable behaviors of your system will be depended on by somebody.”

    Since these updates have broken Bazel (and presumably others) a few times now, I’d really like to see GitHub clarify in documentation whether users should or should not depend on stable archive SHA-256 sums. A GitHub engineer commented that this is not stable, but product managers and support engineers have commented at other times that is stable. I don’t really think discussion comments count since they’re not discoverable. Only official documentation is authoritative.

    I haven’t actually found any documentation for these release archive URLs, so I’m not sure where this clarification should go. It’s not part of the REST API. Linking to releases is pretty close.

    If archive SHA-256 sums are guaranteed to be stable (now or in the future), I think documenting and testing that would let us all sleep easier at night.

    If archive SHA-256 sums are not guaranteed to be stable, it wouldn’t be a terrible idea to inject a little chaos to prevent people from depending on them. For example, in Go, the iteration order of elements in a map is undefined. To prevent developers from depending on iteration order (and tests from breaking when the hashing algorithm is tweaked), the Go runtime adds a random factor into the hashing algorithm, so the iteration order is different every time a program runs. Something similar could be done here with archive file order or alignment. I wouldn’t suggest gratuitously breaking this API, but if it needs to change anyway for some reason in the future, it would be a good idea to add something like this.

    What Could the Bazel Community do Better?

    Bazel developers should not rely on stable archive SHA-256 sums unless that stability is guaranteed and documented by GitHub. More importantly, developers should not rely on dependency artifacts being available on GitHub at all: A library author could delete their project at any time.

    I’ll point to Go modules as a model of a great dependency management system designed to solve this exact problem. The Go team operates proxy.golang.org, a mirror for all publicly available Go modules. Internally, the proxy stores actual files for each module and does not need to regenerate them. The proxy protocol is open and easy to implement as an HTTP file server, so you can run your own proxy service for better availability. I’d love to see something like this happen for Bazel, especially if it’s operated by Google. It is not technically difficult to build a service like this, but there are a lot of thorny issues around handling abuse and legally distributing software with unrecognized licenses, and Google has already figured out those issues for Go.

    Until such a service exists, developers can protect themselves by copying their dependencies to their own mirror. A GCS or S3 bucket works fine.

    Library authors can and should protect their users by providing static release artifacts (not dynamically generated archives), and mirroring those. For example, check out the http_archive boilerplate for rules_go:

    http_archive(

    name = “io_bazel_rules_go”,

    sha256 =

    “dd926a88a564a9246713a9c00b35315f54cbd46b31a26d5d8fb264c07045f05d”, urls = [

    “https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/d ownload/v0.38.1/rules_go-v0.38.1.zip”,

    “https://github.com/bazelbuild/rules_go/releases/download/v0.38.1/rul es_go-v0.38.1.zip”,

    ],

    )

    The file rules_go-v0.38.1.zip is created by the rule authors and attached to the release; it’s not dynamically generated.

    It’s also copied to mirror.bazel.build, which is a thin frontend on a GCS bucket shared by many rule authors in the Bazelbuild organization.

    One other tip: If you’re feeling adventurous enough to use an experimental, undocumented feature (to make your build more stable! Really!), you can configure Bazel’s downloader to rewrite those GitHub URLs to point to your own mirror.

    Aside: SHA-256 of archives or contents?

    It’s unfortunate that a change to the Git archive that does not affect extracted contents of an archive can still change its SHA-256 sum. Bazel absolutely does the right thing by checking the sum of the downloaded file before extracting its contents.

    This is the (delightfully named) Cryptographic Doom Principle. If Bazel only authenticated the contents of an archive, it might be possible for an attacker to exploit a vulnerability in Bazel’s zip parser before the archive is authenticated. Since Bazel authenticates the archive before extracting it, the pre-authentication attack surface is very small.

    Closing Thoughts

    When you’re designing software, think carefully about how it’s going to be used. If there’s a right way and a wrong way to do something, make sure the right way is easier and more obvious. Better yet, make the right way the only way.

    I think this is a case where Bazel’s dependency management is too limited: To use http_archive safely, you need to set up an HTTP mirror with copies of your dependencies. That’s too much work for users, especially new users who aren’t aware of the hazards. A more complete dependency management system should include an artifact registry or a read-through caching system with at least one public implementation. I was hoping Bazel modules and the Bazel central registry would provide that, but the central registry only includes module metadata: Module content is separate, specified in URLs that still frequently refer to the unstable GitHub endpoint.

  • Addressing Software Supply Chain Security

    Addressing Software Supply Chain Security

    It’s essential for organizations to learn more about the software supply chains they rely on and the steps needed to secure them. In just the past few years, we have seen a major uptick in malicious actors exploiting vulnerabilities in software supply chains to facilitate attacks on organizations. However, it’s important to remember that these attacks are not a new phenomenon. In fact, they’ve been around for decades. Therefore, the need to secure the software we rely on is not new, though the industry turning its attention to this problem is.

    Software supply chain attacks are also far from simple. Given the fact that software supply chains are highly complex and made up of a number of constantly changing components, the avenues that malicious actors can take to pull off an attack are plentiful. For example, software artifacts are partially made up of components downloaded from open source software repositories. These platforms have become a favored attack avenue, given how frequently they are used by developers and the trust extended to them by development organizations. According to GitHub, anywhere from 85-97% of enterprise codebases come from open source repositories. Two of these repositories, npm and PyPI, have seen a nearly 300% spike in the number of attacks on their platforms in the past four years, impacting thousands of software supply chains globally.

    One example of the kinds of software supply chain attacks that are now common is IconBurst, a major attack from last year where more than two dozen typosquatted packages were discovered on npm. As with other recent attacks, the IconBurst attackers used typosquatting – uploading malicious packages to repositories with names that closely resemble popular and legitimate packages on the same platform. Developers, in a rush to complete their work, are often tricked into downloading these typosquatted packages. In the case of the IconBurst campaign, for example, one of the malicious packages discovered was downloaded over 17,000 times!

    Given the significant increase in the number of software supply chain attacks, organizations must make more of an effort to understand how these attacks work and then take steps to secure their software supply chains from compromise.

    Say Goodbye to “Shift Left”

    To begin with, development organizations need to reevaluate the mantra to “shift left.”

    For years, industry leaders promoted the notion of “shifting left” as a call to marry application security with application development: Embedding secure development tools and practices into the continuous integration/continuous delivery (CI/CD) process. But times are changing and the industry is beginning to understand that while shifting left is necessary, it is not sufficient to secure software supply chains.

    “Don’t shift left; shift everywhere!” said Tanya Janca, founder and CEO of WeHackPurple. Janca was speaking as a member of a recent Techstrong panel, “Software Supply Chain: It’s All About The Code” at the Predict 2023 virtual event. Janca pointed out the industry’s past fixation on “shift left” and the gaps in security that this caused since threats to the software supply chain not only happen during development but also throughout the entire software release process.

    In fact, the notion of shifting left may do development organizations and developers a disservice: Leaving the work of securing applications entirely to them. “It’s unfair to expect developers to write perfect code,” said Jeff Williams, co-founder and CTO of Contrast Security, another member of the panel.

    Software engineers are already under pressure to develop software quickly to meet development and project milestones. That makes it difficult for them to implement perfect security measures, like vetting every single line of third-party code they use while also watching out for social engineering attacks.

    A New Approach to Secure the Software Supply Chain

    For organizations looking to secure the software supply chains they rely on, they must choose the right tools. But much of the secure development and application security testing (AST) technology out there won’t cut it. For instance, tools such as dynamic or static application security testing (DAST/SAST) are critical components of the secure development life cycle (SDLC). However, they don’t provide holistic coverage of all of the supply chain threats out there, including software tampering and the risk posed by compromised open source and third-party libraries. On the other hand, tools such as software composition analysis (SCA) can help vet open source components but often fail to detect malicious modules or provide total security coverage of software supply chains. Knowing that your application depends on a malicious open source package after the fact is of little consolation when you release code at the speed of DevOps.

    This is why modern tools that go beyond these capabilities should be considered. “It’s about giving developers the tools they need to be successful,” said GitLab’s CPO David DeSanto at the event. Experts in the space agree that change is needed but that developers and development teams aren’t set up for success as it stands.

    According to Mat Matthews, an experienced practitioner in the DevOps space: “While developers are responsible for ensuring clean code, it takes a cross-functional team with a specific focus on security to reduce the attack surface against supply chain attacks.”

    To accomplish that, organizations need to look to their security operations centers (SOCs) to take on a greater role in helping to secure software supply chains. Close collaboration between development and SOC teams is the surest way to provide end-to-end security for an organization’s software supply chains. And, supplied with the right tooling, SOCs and development teams working together will be better positioned to scan software packages; achieve greater visibility into development processes; detect deviations from a set baseline; and pursue possible supply chain compromises before they can cause real harm to software publishers and their customers.

    As threats and attacks on software supply chains evolve, so must protections. A modern software supply chain security program should aim to protect the entire software development process, from the developer IDEs and their plugins to the open source components, CI/CD workflows and the release pipelines, while also being equipped to spot and pursue compromises at any point in the development life cycle. Only then will development teams be able to prevent harmful attacks like SUNBURST, IconBurst and countless others that have happened since.

  • SVB: When Silly Valley Sneezes, DevOps Catches a Cold

    SVB: When Silly Valley Sneezes, DevOps Catches a Cold

    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: Silicon Valley Bank and what it means for DevOps. After the débâcle of Wednesday’s fire sale, Thursday’s bank run and Friday’s FDIC seizure, came Saturday’s impotent panic, Sunday’s “not a bailout” federal guarantee and Monday’s tentative restart of “bridge” bank operation. (more…)

  • Low-Code Should be Worried About ChatGPT

    Low-Code Should be Worried About ChatGPT

    Is ChatGPT the technology revolution that will save the world, or the Pandora’s Box that will eventually destroy it? How about neither? Putting these two extremes aside, a more rational concern is whether ChatGPT will steal your job, especially if you work in software development.

    Is this a fair concern? Conversations like this are nothing new. New technologies always go through this cycle; starting with intrigue then moving onto fear and resentment until eventually being accepted and embraced as the new normal.
    ChatGPT and other natural language AIs are undoubtedly exciting new trends with huge potential. One area of ChatGPT’s potential that has largely been overlooked is how it can democratize software development. Should low-code/no-code providers be worried about this?

    Delivering the Low-Code Promise

    Low code has long promised to democratize software development by providing a way for non-coders to develop applications themselves. This “democratization of IT” promises a new wave of innovation by enabling organizations to create new processes without the new to engage with IT. While low-code has already achieved some great things when and where it has been implemented, the amount of change it can deliver is fundamentally limited by the developer’s choices. The developer still chooses which aspects of the application can be configured by the user, so the user still has no fundamental access to the code. While this has been low-code’s strength (since users cannot damage the underlying code if they can’t access it), users are still beholden to developers to do anything significant. ChatGPT could allow users to make more significant changes to applications, potentially enabling organizations to achieve far more than with low-code and in half the time.

    Software Development is Just the Start

    ChatGPT can achieve more than helping non-developers build the applications they need. If you think about the most common reason for an IT project failure, it is rarely down to poor delivery or mismanagement alone. Most IT projects fail because they do not deliver the outcomes that users want. This happens because of a communication breakdown between IT and end users. On one hand, users fail to convey exactly what they want and IT fails to ask the right questions to find out. The requirements (i.e., the intended outcomes) get lost in translation because technical and non-technical people simply speak different languages.

    In a scenario where the message is too often lost in translation, ChatGPT can serve as the interpreter between those who build and maintain IT and the wider staff who use it day-to-day. ChatGPT can bridge the gap because users won’t need technical skills to realize the changes they want.

    Always Start with the Business Case

    Delivering change in an organization is fraught with challenges and uncertainty. Like any project, it is important to start with the fundamentals of what you’re trying to achieve, not the technology you want to use. No matter how much you want to use ChatGPT, you must start by defining the outcomes you want to achieve and working backward from there. How you achieve these outcomes is a technical decision that comes much later. If one of your questions is to enable change to happen faster and to be more adaptive to the company’s needs, then ChatGPT may well form part of the answer. Just remember to define the problem first, build the business case and then evaluate the various solutions to achieve those objectives. Don’t get carried away by the hype.

    ChatGPT Needs Room to Flourish Outside of IT

    ChatGPT has the potential to be the bridge between technical and non-technical users in every organization. It can reduce the gulf between these radically different types of people to speed up change in the organization and deliver better outcomes for all. But it is crucial for technologies like ChatGPT to sit within the domains where they will have the best chance to flourish. In what might sound like a controversial statement from someone in the IT sector, I believe that, like low-code, ChatGPT must sit outside of the technical domain. ChatGPT needs to move out of the IT sector where it was born to reach its full potential. The question is, is IT ready to let it go?

    Image via Unsplash

  • Understanding Cloud APIs

    Understanding Cloud APIs

    Six out of every 10 businesses had moved their workloads to the cloud as of last year. More steady traffic in the cloud and more direct cloud instances mean more to juggle–and the need for greater customization and integration. That’s where APIs come in. APIs are doing for the cloud what they did for on-premises resources: Segregating, simplifying, specializing and integrating services across a network–only this time, it’s future-proofing the architecture by building it in the cloud. As one cybersecurity researcher quipped, “Everyone wants to use APIs to build innovative solutions, but no one wants to invest in building them.” Cloud APIs will soon spell the difference between companies that can keep up with digitization and those that can’t.

    Ultimately, it will come down to which organizations take the time to understand them and use them to their best benefit.

    What is a Cloud API?

    Simply put, “a cloud API is a software interface that allows developers to link cloud computing services together.” APIs allow services to share functionality and information for other programs to use, and nowhere is this more important than in the interconnected ecosystem of the cloud.

    Because APIs act as a waiter in a restaurant, the better the waiter, the simpler ordering will be for you and for your customers. The best cloud API connects backend cloud components, services and platforms and does all the busy work so all your users see on the front end is a seamless customer experience. Since most of the work of tomorrow will be in the cloud (and is moving there in ever-increasing numbers), to not build up this functionality now is to take a deliberate risk.

    Types of Cloud APIs

    There are several types of cloud APIs based on the four major areas where cloud computing will require integration–either with another platform or another cloud provider.

    ● PaaS APIs (Service level): These platform-as-a-service APIs are designed to integrate with databases, portals, storage components and messaging systems, providing access and functionality in the cloud.
    ● SaaS APIs (Service level): Referred to as software-as-a-service APIs, these connect application layer resources with the cloud and underlying IT infrastructure. A CRM is a good example of where these types of APIs can be used to create a “cloud application extension” for your ecosystem.
    ● IaaS APIs (Service level): Infrastructure-as-a-service APIs control the distribution and deployment of specific cloud resources, performing such tasks as rapid provisioning and de-provisioning, network configurations and workload (VM) management in the cloud.
    ● Cross-platform APIs: Because many environments use multiple cloud providers and platforms, cross-platform compatibility is required. Cross-platform APIs streamline data management by allowing tenants to access their cloud-based resources and workloads from any of their cloud providers, not just their primary one. They provide a higher level of abstraction by translating a specific provider’s API calls into a more generic form, making accessibility, manageability and interoperability in the cloud easier.

    Cloud API Security

    In many respects, the security threats faced by cloud APIs are the same that any cloud-based resource would encounter and present the same challenges. That being said, malicious API traffic surged over 117% last year, from an average of 12 million to over 26 million calls, according to one industry report. The same study revealed that over a third of respondents experienced authentication and data exposure-related incidents with their APIs, and 54% delayed rolling out a new application because of API security concerns.

    Unguarded, a cloud API could present the keys to the kingdom and allow an attacker to access the hub of not just one but several cloud providers and their workloads, resources and assets. Protecting cloud-based APIs with standard authentication and authorization practices such as OAuth2.0 and OpenID Connect can reduce the chance of a lateral attack.

    Why Cloud APIs

    Cloud usage is not set to slow down and will soon become ubiquitous. Companies that aren’t on it are migrating their workloads in greater numbers and entrepreneurial ventures are spinning up as cloud-native. Cloud APIs are simply the logical response to the complexities that come with the terrain. Without cloud APIs, the user experience will be negatively impacted and will only become more apparent when compared with companies that do use cloud APIs.

    For companies looking to innovate in 2023 and release new applications, APIs are the way to cut-and-paste the process safely. Similarly, as more cloud-based services become API-reliant, application reusability is another factor requiring cloud APIs. And lastly, the complexity of cloud products, platforms and ecosystems (even within one organization) makes cloud APIs a necessity for smooth interoperability. And they help with scalability–multiple components of a cloud-based service can be parsed out, updated and patched individually and refined separately so that one area can develop without being dragged down by the whole. Cloud APIs allow for that granular level of customization that can help an organization refine its edge.

    Simply put, organizations will need these APIs to not only compete but stay relevant as businesses continue to take their fight to the cloud.