Category: Enterprise DevOps

  • Heterogeneous Hardware Needs Universal Software

    Heterogeneous Hardware Needs Universal Software

    As hardware advances and diversifies, we’re entering what many see as a new golden age of computer architecture. However, the idea of an ever-expanding hardware landscape can be daunting for software developers, because while hardware diversity is wonderful for price and innovation, it can lead to spiraling software complexity on the back end. So many software tools are specific to the hardware they run on that a world where CPUs, GPUs, FPGAs, ASICs, DSPs and more are freely intermingled feels overwhelming; an invitation to interoperability headaches and spiraling tech overhead. The question on the minds of developers is how to navigate this constantly changing ecosystem to take advantage of the new world of hardware acceleration without driving themselves crazy in the process. 

    The challenge for developers is that, if we look historically, every time a new piece of world-changing silicon shows up, it often comes with a new software stack of tools. With heterogeneous hardware innovation moving at a nearly untrackable pace already, keeping up with the software end is beginning to feel untenable. In response, a new philosophy is emerging: We should be able to have a common set of tools, libraries, frameworks and compilers that can address a wide variety of accelerators in a “silicon agnostic” way. 

    Anyone doing DevOps work today should be asking, “Are the tools we are adopting ready for the heterogeneous hardware future?” Rather than using proprietary stacks exclusive to individual vendors’ concepts of how acceleration should work, we should be thinking about abstraction layers that allow us to move to open software stacks that work across multiple vendors and architectures. 

    This philosophy is central to a number of movements—oneAPI being one example—of asking for libraries, compilers and analysis tools that are more versatile. It’s incumbent on any future-conscious developer to analyze the tools they’re using and ask if they are preparing for the future or locking them into a single solution that excludes you from other innovations. 

    When it comes to navigating the changing developer landscape, it’s particularly important to look at the multiple-vendor piece of the puzzle. One of the signature strengths of computing and electronics is its ability to interoperate. Without compatibility between platforms, we end up locked into single solutions that don’t take advantage of the diverse landscape of innovation available to us. If systems are built from the ground up with mixing and matching in mind, we don’t have to change our software tools to adapt to new technologies and we can use the same languages, libraries and analysis tools we are used to. 

    It’s important we take on this work now because hardware diversity is not just at an all-time high, its momentum is only growing. In the past when the hardware landscape was more limited, switching to different toolsets for different CPUs was a feasible, if inelegant solution. Today’s computers, however, have computational capabilities from multiple vendors. If my tools don’t stretch across all of its ecosystems, I end up in a complex mess very quickly.  

    A particularly relevant example can be found in supercomputing, one of the most exciting and fast-moving areas of innovation in the developer community. What is the most exciting thing about supercomputing? It’s heterogeneous, allowing multiple architectures to take on specialized hardware acceleration for the different tasks for which they are best suited. The Aurora supercomputer, for example, is planned to achieve up to 2 exaflops of performance—a staggering number (the first supercomputer I helped design had 1 teraflop—or 2 millionths of Aurora’s performance). The amazing capabilities of these machines are only possible because of advancements in heterogeneous memory technologies, storage capabilities, sophisticated CPUs and GPUs all working together seamlessly.  

    The advancements we’re seeing in supercomputers, as always, will ultimately filter down into lower-level systems. In the near future, regardless of the type of work you do, enormous computing power is coming online. We need to make sure that our libraries and tools can take full advantage of it when it arrives.

    Two great places to learn more about activities to help software be open, multi-vendor and multi-architecture for heterogeneous programming are:  https://sycl.tech/ and https://www.oneapi.io. There are numerous online tutorials, a link to the SYCL book (free PDF download) and much more.

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

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

  • Building a Reliable App Installation Experience With MSIX

    Building a Reliable App Installation Experience With MSIX

    Simple, safe, reliable software installs and uninstalls are always best, but getting there isn’t easy. Applications break each other—or even the operating system itself.

    MSIX, Microsoft’s packaging format, is the newest replacement for the decades-old Microsoft Software Installer (MSI) and setup exe installer technologies. MSIX is gaining acceptance and wider adoption because of the benefits it delivers: security, ease of use and reliability in application installations. 

    MSIX provides a new, modern runtime environment intended to protect both your application(s) and end user systems. Enterprise users prefer the MSIX format because it provides the most appropriate framework to modernize applications; simultaneously reducing IT departments’ workloads when preparing application package(s) for delivery to hundreds or thousands of end users.

    As developers who build Windows desktop applications embrace the concept of running code in an MSIX container, understanding certain key concepts can streamline and strengthen their application installation experience.

    Why MSIX?

    Running code in an MSIX container can solve common problems encountered by developers coming from non-containerized deployments. This includes products built and delivered as a Win32, .Net Framework or Universal Windows Platform (UWP) packages—or when starting a new project from scratch. 

    In addition to providing clean installation and uninstall processes, MSIX enables enterprise customization in independent packages via modification packages. It also supports the ability to deploy applications through enterprise tools (e.g., Microsoft Endpoint manager) or to the cloud (Azure Virtual Desktop, MSIX app attach).

    Value for Developers and IT Pros

    MSIX improves upon the more restrictive model of UWP while still running in a container. It allows developers to code in their preferred way (e.g., unmanaged code using Windows Forms, calling the Win32APIs or managed code using XAML and .NET framework versions of the APIs). 

    Some tactics must be changed to run inside the MSIX container, however. In addition to minimizing work, it facilitates building modern IT ecosystems, deploying apps and updates faster and more frequently and modernizing applications into the new world of containerized packages.

    MSIX also supports deploying applications via enterprise tools (e.g., Microsoft Endpoint Manager) or even to the cloud.

    Value for Users

    By delivering a more streamlined installation experience for users, MSIX offers benefits to customer and end users, including: 

    • Guaranteed clean installs: This prevents time wasted on installs, uninstalls, reinstalls or issues that occur with other installed applications.
    • Isolation between applications except when isolation isn’t desired.
    • Greater security to protect the customer and the application.
    • Improved features including automatic updates, differential updates and disk space optimization—without having to customize code or the packaging process.
    • Single-instance storage; automatic block-level deduplication for any file in any installed package.
    • Fewer support calls: This cuts down on annoyances, delays and expenses for all involved.

    Elements of a Successful MSIX Project

    MSIX projects require a different approach than what many developers are accustomed to. To provide customers with the best package file(s) possible, consider the following elements as part of the project. Doing so will strengthen additional project activities, project setup, testing and debugging and supported schemas.

    1. Digital signing: Secure installations of MSIX packages are provided by installing the application to the app container and enforcing the app packages with digital signatures (with a valid code signing certificate). Only trusted apps are installed, enforcing the integrity of the package and its container after deployment.
    2. Package components: An MSIX package includes files that are essentially a set of ingredients—some generated directly (e.g., image files for the start menu) and some created as part of the build process (e.g., output by other vendor tooling). Ingredient files—including root and virtual file system (VFS) folders—will be passed to the MakeAppX command to generate the package.
    3. An efficient MSIX build process: Custom modifications are sometimes needed for a package, such as when PSF is appropriate for handling a few unexpected scenarios; this requires repackaging extracted contents back into the MSIX package. Whether or not such modifications are required, an efficient build process is always necessary. Building an MSIX/APPX package manually is possible without any packaging tools, with documentation provided by Microsoft. Alternatively, tools such as InstallShield can automate the process.
    4. MSIX bundles: .msixbundle installation ensures that only packages applicable to a device’s architecture are installed. An MSIX bundle targets different system architectures, language-specific assets, varying image-scale assets or resources applicable to specific devices.
    5. Modification packages: MSIX supports the creation of modification packages intended to modify or extend existing packages. These allow customers to create customized configurations for your package or enclose a plug-in.
    6. Shared package containers: When working closely with two separate packages, each with its own start menu and other entry points, a shared package container may be appropriate. This additional XML file may be installed on the end user’s computer to tell the OS that the packages should share a single container rather than be isolated from one another.
    7. AppInstaller (XML) file: While MSIX and bundle files are generally directly installed into the operating system, the OS facilitates installation and management of updates automatically. Microsoft now makes this functionality available for packages delivered externally by using an AppInstaller XML file to perform the installation, telling the OS where to find the current msix file, where to look for updated AppInstaller files and the configuration of updated settings for the package.
    8. MSIX core: MSIX Core is built for older Windows versions that don’t natively support MSIX. This enables installation of MSIX apps on previous versions of Windows (as long as the apps are built to work on those versions of Windows).
    9. Basic AppXManifest structure: Last but not least, the most important file in an MSIX package is the AppXManifest file, an XML file that defines how the application will integrate with the OS for access by the end user, including the application model used that impacts runtime container features. Understanding the structure and element tags (package, properties, resources, dependency capabilities, applications/application element tags) of the AppXManifest early on will help ensure appropriate project setup.

    While MSIX continues to evolve, so can your projects. The end results will be application packages that not only streamline work for IT departments but also reduce headaches for end users.

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

  • Investing in Artificial Intelligence: How MLOps Drives Enterprise AI Wins

    Investing in Artificial Intelligence: How MLOps Drives Enterprise AI Wins

    Insight Partners had a banner year in 2021, with more than $50 billion in capital commitments across over 200 investments. While we invest in founders across a wide spectrum of businesses, this series focuses on outlining our theses on four verticals that we’re particularly excited about in 2022: Artificial intelligence (AI), fintech, cybersecurity and healthtech. 

    Artificial intelligence has remained a super-hot category for good reason: It has the potential to transform nearly every industry and business.

    At Insight, we’ve long been bullish on the many use cases for AI. In the past year, we’ve invested in image recognition software from Netherlands-based ScreenPoint Medical, which improves early detections of breast cancer, Covera Health, which provides a quality analytics platform to reduce medical errors in radiology, CARTO, which helps companies use and understand spatial analytics, and Laminar, a cloud data security platform to continuously monitor and protect against data leaks – among other game-changing companies.  

    In total, Insight invested in 49 different companies across a broad spectrum of artificial intelligence and machine learning use cases in 2021, which represents a 172% increase from the year prior.  

    As we look ahead into 2022, we expect artificial intelligence tools to continue to dominate. We see the ecosystem dividing into three primary categories:  

    • Layer 1 – Base platform companies: Algorithms; frameworks; infrastructure and workbenches for creating ML systems   
    • Layer 2 – Cross-industry capability companies: Turnkey machine learning-based systems that solve specific problems spanning multiple industries (e.g., cybersecurity)  
    • Layer 3 – Industry-specific companies: Applications powered by prediction or classification systems that target specific, niche use cases in one domain    

    Companies and investors will find valuable AI/ML software across all three layers. At Insight, we initially focused on layers two and three. We invested in startups creating robust ML systems that addressed specific problems, either vertically (like credit underwriting company Zest AI) or horizontally (like cybersecurity company SentinelOne). We thought that economic moats were hardest to build at layer one; in part as a result of robust open source ecosystems and because large public cloud vendors deliver many of these tools at low prices.

    Insight Partners’ three-layer framework of machine learning companies

    Throughout this year, however, we realized we were missing a piece of the puzzle. While there will always be market demand for cross-industry capabilities and industry-specific applications, 2021 taught us that as companies try to productize AI for the first time, base platforms will become increasingly important as well. 

    After all, more companies than ever are charging forward on artificial intelligence projects to try to guide business decisions and save time and money. A whopping 90% of enterprises are either actively running AI projects or plan to in the next 12 months, according to a recent survey.   

    But here’s the catch: Most of these projects will fail.  

    There are many reasons why including a lack of sufficient data or black-box models that spit out indecipherable results. Regardless of the reason, high failure rates can hurt the ecosystem if they result in corporations’ hesitation to move forward with future AI projects.  

    Accordingly, Insight is particularly excited about a subsection of AI tools that can significantly increase companies’ likelihood of succeeding at their project goals: Machine learning operations, or MLOps. 

    MLOps tools can improve a machine learning pipeline from start to finish by helping gather, manage and label data, experiment and test the model selection, deploy multiple models in production at once and protect against model and data drifts and attacks. 

    Holistically, the goal is to improve communication and collaboration between data scientists, data engineers and business analysts through the machine learning life cycle, similar to how DevOps tools help improve communication in the software development life cycle. Machine learning is an iterative process with constant feedback loops and the need for continuous monitoring, which makes MLOps tools to manage this process even more critical. 

    Overview of some of the key areas of an MLOps pipeline

    While every company rolling out AI projects can benefit from MLOps, the type of tools they require will depend on their needs, resources and strategies.   

    Companies should ask themselves: How sophisticated is our data science team? How mission-critical do we want our models to be? Are our data sources structured or unstructured? Do we want open source, commercial or homegrown tooling?   

    The answers to those questions will point companies to specific MLops tools that are best suited for their specific challenges. 

    For example, some platforms—like Dataiku or DataRobot—are end-to-end products with wide capabilities, which are typically easier to use and thus encourage model creation and experimentation from workers across job functions, regardless of technical knowledge. These so-called ‘citizen data scientists’ can boost analytic workflows for companies with fewer data science experts and create significant value, but there’s a risk that the deployed models are not as well understood or controlled. These types of tools are best for companies that want to use machine learning to drive business insights and analytics rather than as part of their core business function.  

    If a company has a sophisticated data science team, however, it may lean toward specific point solutions, or what Insight calls best-in-class MLOps solutions. While these products require greater technical knowledge to maintain and deploy, they allow for much more control, depth and sophistication in a system. One startup offered the apt analogy that using platforms versus best-in-class solutions is like driving an automatic car versus a stick shift. 

    There are multiple MLOps tools for each part of the pipeline, and we see a world where each tool has enough market space to support it becoming a large company. 

    At Insight, we spent 2021 learning about and investing in many of what we consider to be the best-in-class MLOps tools, as determined by highly satisfied customer feedback, clear market momentum and well-respected and knowledgeable teams. This perspective led to our investments in Explorium, Rasgo, Weights & Biases, Deci, Run AI, Fiddler, Tonic, Dataiku and Databricks, as well as several others that have yet to be announced. 

    Insight Partners’ MLOps market map 

     While Insight expects MLOps to continue to be an essential driver of AI success in the new year, we also expect to see several other trends take shape in 2022:  

    • First, we will see the emergence of two machine learning pipelines, one for structured and one for unstructured data. Unstructured data sources—like images, videos and audio—require specific data warehouses, data management, pipelines and model management tools that maximize productivity and accuracy. Given the nuances and complexities between the two data types, we expect to see more MLOps tools shift toward owning their category for one or the other. 
    • As enterprises scale from dozens of models to hundreds or even thousands of models, we expect the increased industrialization of AI. This will result in the rise of orchestration layers that sit on top of machine learning pipelines to help manage all the different tooling. These layers will integrate across multiple tools in the ML pipeline—whether open source, commercial or homegrown—and provide an integrated environment (or so-called “single pane of glass”) to better track and manage ML pipelines. Orchestration layers will help enterprises gain more control over their pipelines while still supporting best-in-class tools. 
    • Insight believes we are at an inflection point of moving from a model-centric to a data-centric world. In a model-centric approach, you ask how you can change a model’s code to improve the performance of the system, whereas, in a data-centric model, you ask how you can change the data to improve it [system performance]. We expect the most successful tools of 2022 to be focused on supporting the new tasks, workflows, and jobs spawned by the data-centric movement.
    • We will also see a new class of MLOps tools focused on closing the growing AI skills shortage and gap across businesses. These tools will focus on increasing the efficiency of the model production process and lower the bar for ML development.
    • Finally, we expect to see a significant increase in the overall enterprise adoption of ML, with a shift from experimentation to deploying models in full production. Last year, we saw many enterprises form AI research teams and hire data scientists to experiment with machine learning. In 2022, we believe these enterprises will start realizing the full capacity of their AI projects and driving significant business value. This increase in enterprise adoption will also be driven by the explosion of edge devices that will enable new use cases of ML adoption. 

    As active machine learning and artificial intelligence investors, we are excited to continue to watch the market and support new entrants in what will surely be another dynamic and exciting year. 


    George Mathew, Lonne Jaffe and Sophie Beshar co-authored this piece.

  • The Lego Approach to Overcoming the Developer Divide

    The Lego Approach to Overcoming the Developer Divide

    As end-user demand for new services continues to rise and businesses adapt to changing times, digitalization has never been more important. Pressure is increasing on organizations to deliver digital transformation initiatives more quickly as 55% of CIOs in 2021 said they were increasing staff to accelerate their digital programs. The cloud is essential for this. Because it can enable new opportunities for revenue and quicker delivery to market, the cloud is the way forward for companies that want digital success. That’s why 95% of those surveyed by Accenture say they’ve adopted advanced cloud services. 

    However, this is not without its challenges. For one, teams need the skills to match—individuals who know how cloud works and the expertise to unlock its potential. But this is proving difficult as talent remains hard to recruit (a recent Gartner report found that IT executives view the talent shortage as the most significant barrier to deploying cloud, edge computing, automation and other emerging technologies). In addition, as 92% of companies believe DevOps is crucial for revolutionizing their digital strategies, it’s worrying to see a new report from Boston Consulting Group that revealed up to three-quarters of developers are looking to change their jobs within two to three years. 

    This is something enterprises need to address if they wish to accelerate digital transformation programs and take advantage of the emerging cloud technologies that support the growing need for a distributed cloud architecture. Without the required developer expertise, organizations will fail to address end user expectations and fall behind their rivals. 

    A Concrete Problem

    While the shortage of developers was an issue even before the pandemic, the problem is only getting worse due to the increasing need for digital transformation. It is putting more pressure than ever on existing developers and making it difficult for organizations as they struggle to recruit more talent. In fact, research found that pressure on digital architects has more than doubled during the pandemic, with almost 50% saying they are currently under high or extremely high pressure to deliver digital projects.

    This skills shortage is an important issue for companies to consider. It is well-known that the expertise needed to deploy and maintain cloud services differs considerably from what’s needed for on-premises environments. Without those skills, it becomes difficult for IT teams to oversee and understand what is happening with regard to their cloud deployments, and it ultimately hinders organizations from generating new revenue opportunities through increased innovation. Cloud is a whole new world where control and insight are limited, there are new inflexible cost structures to get used to and other departments can easily procure new applications without the IT team’s involvement. However, we still see examples of organizations being tripped up by these differences. 

    Organizations take proactive steps to keep their developers engaged and happy to avoid digital transformation burnout and ensure they make the most out of their cloud deployments.

    One Brick at a Time

    One way enterprises can do this is by embracing a Lego approach to their digital transformation journey. By adopting a composable business strategy, organizations are in the best position possible to remove pressure from developers and drive increased innovation with less need for highly specific technical expertise. 

    When building things with Lego, even if you’re starting without instructions, you don’t need to completely start from scratch—and you can use the same bricks time and time again. Composability, or the notion of building and configuring infrastructure and applications from component parts with well-defined interfaces, means the same is true when developing new digital services. Instead of having to start from scratch each time or write specific code, developers and even business users can quickly innovate new experiences by composing and decomposing existing digital assets and reusing them—just like Lego bricks. In this way, the company is using its existing skillset to the fullest; maximizing the value of its resources and allowing it to concentrate on actually developing new experiences and services.  

    Perhaps most importantly—especially for developers—this means less pressure on development teams, not only because there’s less need to reskill but because composability means they no longer need to worry about managing underlying infrastructure or reconfiguring physical assets like servers, storage and connectivity. Instead, they can manage all assets through a single unified control plane that spans multiple clouds, right through to the edge. 

    Making use of Existing Resources

    As part of this composable approach, enterprises should also examine how they move away from legacy technology, making sure they invest in innovations that leverage their existing in-house developer expertise. For instance, using a database-as-a-service platform that has the same programming language and tools that developers are already used to will accelerate adoption and reduce training costs. 

    The move away from legacy technology won’t just increase value for the money at a time when developers are becoming harder to recruit and budgets are tight. It will, again, also make life easier for developers. Instead of having to struggle with the integration of older systems with newer innovations, next-generation technologies will make this process harmonious and easy, further reducing the pressure and speeding up digitalization.

    Creating a Solid Foundation

    The developer divide is an issue that organizations need to take seriously if they wish to drive forward their digital transformation initiatives. At a time when demand for improved end user experiences is high, the need for developers has never been greater.

    While recruitment and retention remain a challenge, the Lego approach of composability means enterprises do not need to lose out. Using the existing skills and resources of a company, composability propels faster innovation and greater agility. 

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

  • Site Reliability Engineering (SRE) Comes of Age in 2022

    Site Reliability Engineering (SRE) Comes of Age in 2022

    The site reliability engineer (SRE) role is still gathering steam across organizations. In January 2022, LinkedIn listed SRE as the 21st job with the highest global demand throughout the past five years. That’s pretty high for such a specific tech role. And, looking to the future, it appears the SRE practice will only continue to gain adoption as a method to support high availability, reliability and improved digital customer experiences. The SRE approach is also essential to meet service-level agreements (SLAs) and internal service-level objectives (SLOs).

    I recently met with Kurt Anderson, SRE architect, and Emily Arnott, content writer from Blameless to get their take on the top trends and predictions for the SRE practice in 2022. According to the Blameless team, 2022 will likely see increased adoption of the SRE role throughout companies and across internal departments.

    Just as manufacturing sets high standards for its quality assurance, digital applications now require the same high reliability to meet inflated user expectations. To address these new realities, SREs have their work cut out for them—they must confront how to unify disparate DevOps tools and must drill farther down to unearth specific user experience qualms—all without adding to alert fatigue.

    Increasing SRE Adoption

    As mentioned above, the SRE role has seen tremendous growth in recent years and doesn’t show signs of slowing. SRE as a practice was first popularized by Google in 2015. Today, they define it simply as “what happens when you ask a software engineer to solve an operational problem.” This equates to maintaining high levels of reliability for digital services by creating errors budgets, designing SLAs/SLOs and optimizing process automation over time.

    To Arnott, we’re still seeing SRE adoption take off at an exponential rate as more and more companies embrace Google’s SRE doctrine. “During the pandemic, more and more companies were forced to adopt a digital strategy. Reliability has to be fundamental to that strategy.” Arnott foresees SRE becoming a fruitful role at startups, which may initially have been intimidated by the prospect.

    “The practice of SRE is a scale issue,” Anderson explained. It can be difficult for time-pressed companies to enact an SRE program when their attention is already so divided. However, as new requirements force warp-speed innovation, we’re seeing greater DevOps adoption. And the SRE role, consequentially, is becoming more of an imperative.

    More Unification of Multi-Tool Condition

    Most DevOps professionals would agree—we live in a multi-tool world. For example, multi-cluster management concerns are bringing a plethora of new tools to the fold. And computing environments are just as diverse, often combining multiple clouds and composed of hybrid estates that house various clusters of microservices. Even within the same organizations, different teams may opt for differing DevOps tooling. Anderson believes that SREs can bring “more unification to a fractured DevOps adoption across a single company.”

    As companies adopt more software, there’s inevitably some degree of tool sprawl, Anderson said. For example, there may be competing methods to monitor the use of digital services. The platform team may be using Datadog, an app team may be using New Relic and another team may be using Prometheus. These tools don’t speak the same language and generate different logs, creating silos.

    For Arnott, the future involves accepting the innate complexity of the microservices era and using an agnostic layer that can receive data from anywhere to identify meaningful incidents.

    Observability Gets a Bigger UX Emphasis

    The SRE role is definitely a trend that has been growing and will continue to grow in importance, Anderson said. And as more organizations turn digital, it’s becoming necessary; with this shift comes enormous pressure to exceed user experience expectations. “Competition and people’s expectations are so high right now,” said Arnott. “If you are unreliable, it’s unacceptable these days.”

    Whereas DevOps focuses more on getting applications into production, SRE takes a more UX-focused approach. Take Netflix, for example, which has invested heavily in a core SRE team that ensures robust and reliable user-facing services. “A key underpinning to keeping our customers happy and streaming is a strong focus on reliability,” according to the Netflix Technology Blog.

    To cater to this new paradigm, teams will require a deeper understanding of observability based on particular cohorts of users, said Arnott. SREs require precise user experience contexts, such as an uptick of lags or increased error responses. But they also must discover the contributing factors behind these bugs. “SLOs and error budgets are like taking your temperature—they tell you if something is wrong. They don’t tell you why you have a fever.”

    SRE Takes Cues From Manufacturing

    As reliability becomes more and more central to a company’s brand presence, it’s only natural that something that important would be elevated into the executive suite, Anderson explained. As a reference example, he pointed to the fact that manufacturing industries often appoint a chief reliability officer. In traditional manufacturing, product lines undergo a statistical process control with rigorous testing to ensure quality. Analogous positions exist across industries, such as chief quality officers in financial services.

    The takeaway is that as reliability becomes more of defining competitive metric, tech companies may require a similarly high-level C-suite position to align on that idea and to direct teams to implement SRE practices. Of course, the necessity for such a title will entirely depend on organizational size and makeup.

    Greater Reliance on SLOs to Avoid Broken SLAs

    A service-level agreement (SLA) is typically a formal contract built around the reliability of a digital service with an external partner, which, if breached, may result in financial penalties or other forms of restitution. This agreement could exist between a software provider and an end user but is more strictly enforced in a B2B context.

    On the other hand, a service-level objective (SLO) is more of an internal target. SLOs are often set at a lower threshold than SLAs. For example, perhaps an SLA ensures a user login fails no more than 10 out of one million attempts, but the SLO is set at two out of one million.

    Setting internal SLOs helps keep engineers abreast of modest customer experience issues before they become a major incident that results in fines. “Some companies treat SLOs as just another alert; they should be representative of user experience,” said Anderson. It makes sense that as SRE initiatives begin to mature, companies will slowly start to adopt even more competitive goals to deliver superior user experiences and avoid unsatisfied partners.

    Final Thought: Don’t Play The Blame Game

    A big part of the SRE doctrine is the concept of blameless postmortems. Because when you’re in the middle of an incident, the worst thing to do is point fingers. “Blaming triggers a defense mechanism and when you’re in a defensive mode, you can’t respond well,” said Anderson.

    Instead, it’s better to keep an open mind when performing these retrospectives—accept that what occurred happened for a reason, and seek to discover that reason to make positive improvements. “What can we change at a systemic level to become more resilient?” inquires Arnott. “What is the origin of that mistake? What information was lacking? What communication should have happened to prevent this?”

    Typically, accidents don’t occur intentionally or due to incompetence but rather due to holes in the process. By not playing the blame game, companies are better positioned to fix issues as they progressively release new features. Then, hopefully, with the right SRE approach in place, teams can advance their digital services to meet the high stakes of today’s modern user experience expectations.

  • Survey Predicts Massive Migration to the Cloud

    Survey Predicts Massive Migration to the Cloud

    A global survey of 1,600 enterprise IT decision-makers found more than half are working for organizations that plan to eliminate the use of data centers over the next two years.

    The survey was conducted by Aryaka, a provider of a secure access service edge (SASE) platform, and found a quarter of the respondents have closed 25% to 50% of their office sites; 75% of respondents said at least a quarter of their employees will remain remote permanently post-pandemic. Just under a third (32%) expect at least half of their workforce would be permanently remote.

    Despite the apparent accelerated shift to the cloud, the report found a full three-quarters of respondents (75%) are projecting at least a 10% growth in IT spending, with a quarter expecting IT budgets to grow 25% or more. Nevertheless, more than a third (36%) report they have IT cost concerns.

    David Ginsburg, vice president of product and solutions for Aryaka, said the shift to the cloud in the wake of the COVID-19 pandemic is being driven mainly by digital business transformation initiatives that require applications be quickly built and managed by IT teams that are working from home themselves. With the pandemic entering the third year, a hybrid workforce that regularly shifts between home and the office is now permanent, he noted.

    Consequently, with more people working from home, nearly two-thirds of respondents (64%) said they will shift toward a SASE-based approach over the course of the coming year to provide secure access to cloud applications over a software-defined wide area network (SD-WAN). Over two-thirds of those respondents said they will opt for a managed SASE offering rather than build and maintain these platforms themselves.

    SASE was originally coined by Gartner to describe a cloud-delivered service that brought together networking and security offerings. Those offerings should include a firewall-as-a-service (FWaaS), secure web gateway (SWG), cloud access security broker (CASB) and zero-trust network access (ZTNA). In effect, it’s a secure software-defined wide-area network (SD-WAN). As organizations adopt SASE-based platforms and services, just under a third of respondents (61%) are recognizing that dynamic bandwidth reallocation will be a very important requirement as workers shift between the office and home.

    The transition to SASE involves setting a strategy (35%), phasing out of legacy virtual private networks (32%) and consolidating cloud security with zero-trust (29%). Top desired capabilities include SWG (47%), SD-WAN (36%) and FWaaS (28%). A full 41% reported that responsibility for networking and security decisions have now been consolidated into a single team. However, only slightly more than a third (34%) said security is a major priority.

    The implications of a shift to the cloud at this rate and level of scale are likely to have a profound impact on DevOps teams. While cloud infrastructure is designed to scale on demand, accessing applications across an SD-WAN can have a significant impact on application performance. The survey, however, finds only 29% of respondents are concerned about whether applications will perform properly. Nevertheless, well over two-thirds (69%) said there will be an increased focus on observability and control, while 42% noted identifying slow performance for remote and mobile users will be a key issue and 37% expected slow performance at the branch office to also be an issue. Lackluster application performance is a time sink, according to 42% of respondents.

    Naturally, many IT teams will add new tools and platforms to deploy and manage cloud applications. The Aryaka survey found that only slightly more than a quarter of respondents are concerned about the newness of the technology they might employ.

    The coming year is shaping up to be incredibly disruptive to the IT landscape. The challenge is making sure balance is maintained between cost, flexibility and application performance.