devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

  • How Open Source Can Enhance Developer Experience

    How Open Source Can Enhance Developer Experience

    Developer experience (DX) is becoming more and more of a competitive advantage among developer-facing tools and platforms. A great developer experience that’s easy to follow and implement can truly help a software tool stand out from the crowd.

    Simultaneously, open source software is all the rage. In fact, a recent StackOverflow survey found open source software (OSS) to be, by far, the most revered and proven technology trend.

    With that in mind, what are the synergies between developer experience and open source? And how can building in an open source format aid the developer experience for your public-facing toolsets and internal development platforms?

    I recently met with Adam Frank, SVP of product and marketing at Armory, to explore the state of developer experience and open source adoption. According to Frank, open source can bring numerous DX benefits. Below, we’ll explore these areas and consider why organizations might benefit from adopting more open source within their developer-facing initiatives.

    The State of Developer Experience and Open Source

    So, what is the state of developer experience, and why is it important now? Well, DX is continually leveraged to help improve agility and competitiveness in the market. In addition to granting differentiation, DX also enables more flexibility, helping users switch from one tool to another if necessary.

    “Developer experience is at the forefront right now because technology and change are moving faster than ever before,” said Frank. “Companies need to focus on DX as a competitive advantage to survive and thrive.” At the same time, open source can help organizations move quickly and iterate more efficiently.

    Yet, historically, open source has not been associated with fantastic DX. Most of us have at least one horror story of an open source project simply going belly-up without warning. It’s common for an OSS tool to lack comprehensive documentationor suffer from a lack of funding for ongoing maintenance, zero customer support and deprecated modules. Some tools that developers directly download and contribute to may not possess a quality DX emphasis, says Frank.

    However, the status quo for OSS has undoubtedly evolved over the years, he adds. Nowadays, there are more established groups, like Linux Foundation’s Cloud Native Computing Foundation (CNCF), with specific Technical Oversight Committees (TOCs) to oversee individual projects. The maturity of OSS ownership now ensures core projects stay relevant and receive continual support—not to mention ongoing developer experience enhancements.

    On the other side, OSS is often absorbed by a platform team to enable their internal developers to move faster or ship more code, says Frank. From this perspective, open source communities give platform engineering the opportunity to contribute back to the project, helping them solve deeper-level problems that are more specific to their environments.

    How Open Source Can Enhance Developer Experience

    Not all IT leaders are sold on the idea of building in a transparent, open source model. Yet, this enhanced transparency can bring dividends in the long run, especially where developer experience is considered. Frank shared some of the benefits of adopting open source.

    Receiving Feedback From The Community

    “As a product manager, you want as much feedback from your users as you can gather,” said Frank. Receiving user feedback is a great way to fix DX issues, and OSS gives you that on a larger scale. By adopting open source, you benefit from collecting insights from your customer base and the developer community at large. This can translate into a broader range of use cases, which can significantly improve projects and overall experience.

    Increasing Ecosystem Transparency

    Building in a more transparent and open fashion so that everyone has the ability to submit pull requests can also help you work together with potential partners. This makes it easier to develop third-party integrations that ensure the broader ecosystem can work together. By decreasing the barrier to entry through OSS, you provide others with the ability to solve more problems around developer experience.

    Streamlining the Developer Toolchain

    “Developers want to innovate; they want to solve problems,” said Frank. Open source can also help expose inefficiencies in the developer toolchain and, notably, many open source CI/CD tools are often leveraged to automate deployment and increase efficiency. The end result is that developers can focus on innovating their own competitive advantage. “Making the deployment aspect of the developer lifecycle really seamless can significantly improve their experience,” he said. Therefore, any tools or extensions around CI/CD are an excellent area to consider open-sourcing.

    Increasing Flexibility

    Another benefit of the open source model is that you have far more flexibility than off-the-shelf proprietary software. As a customer, you don’t have to wait to submit enhancement requests. With OSS, you can fork a project or quickly collaborate with the maintainers. This equates to making fixes far quicker and providing the ability to customize developer experiences to the tasks at hand.

    Best Practices to Ensure Open Source Improves DX

    Open source provides many key benefits that can enhance software development and delivery. But, this should be taken with a grain of salt, as best practices still must be followed to ensure open source enhances, not hinders, developer experience.

    For example, Frank mentions that simplicity should be a guiding light. “Have simplicity for the user experience design in the forefront of everything you’re building and thinking about,” said Frank. Adopting simplicity should help ensure developer-facing materials are structured well and documented in an easy-to-comprehend manner.

    On that note, open source projects will require standards around areas like good documentation and well-written APIs that abide by contracts, said Frank. Anything less will hinder developers and confuse them with disparate data formats. On that note, he has witnessed OpenTelemetry emerge as a common way to unify data that systems produce with standard formatting, which increases the observability of these environments.

    Lastly, it’s critical to hire talent with experience in open source. Bringing in folks that have knowledge of how OSS communities operate will make onboarding easier and encourage safer open source security practices as well.

    What the Future of DX and OSS Holds

    Open source appears to aid developer experience in many ways, from driving more innovation, opening software up to feedback and developing a closer-nit developer community. But what does the future of developer experience and open source look like?

    According to Frank, we will likely see increased data standardization that makes it easy to work with various projects and data formats. OpenTelemetry, for example, makes aggregating logging easier. We’ve also seen standardization around OpenAPI Specification for describing web APIs. Another example is FinOps Foundation’s FOCUS specification to unify cost analysis.

    Open source tends to leverage open source. And as the industry continues to coalesce around open standards, we’ll likely see more robust, compatible layers of abstraction emerge throughout the market, Frank predicts.

  • HashiCorp Releases Slew of Updates to Improve DevSecOps

    HashiCorp Releases Slew of Updates to Improve DevSecOps

    At a HashiDays event this week, HashiCorp launched updates to its Terraform implementation and a software-as-a-service offering, dubbed HCP Vault Secrets, that promise to simplify infrastructure security and ensure that secrets are not leaked.

    In addition, HashiCorp has added a self-hosted edition of its remote access security tool, Boundary, that can now also record SSH sessions. The company is also announcing general availability of Vault Secrets Operator, which provides a high level of abstraction for managing secrets in a Kubernetes environment and which synchronizes with the secrets management interfaces defined by the Kubernetes Technical Oversight Committee.

    Finally, HashiCorp is making available in beta a 1.16 update to the Consul service mesh for containers and virtual machines that adds a Sameness Groups capability to improve the resiliency of microservices by redirecting requests to an identical service. HashiCorp has also added a transparent proxy mode to enable failover between services along with a permissive mutual TLS (mTLS) that enables a service to be configured to accept both mTLS traffic from mesh-enabled services and non-Consul mTLS traffic from external downstream applications.

    Chris Van Wesep, senior director of product marketing for HashiCorp, said Version 1.5 of HashiCorp Terraform adds config-driven import workflow and check blocks capabilities that make it possible to declaratively use code to add existing resources into a Terraform state. Previously, the only way to update a Terraform state was to use an import command that could only be applied to one resource at a time. Terraform 1.5 also adds automatic code-generation capabilities for imported resources.

    In addition, version 1.5 of Terraform also includes a tool to validate that provisioned infrastructure is behaving as intended. That latter capability makes it possible to reduce the number of misconfigurations created by developers that might one day be exploited by cybercriminals to breach an IT environment.

    HCP Vault Secrets, meanwhile, provides a beta release of a SaaS edition of the existing Vault offering specifically designed to enable organizations to better manage application secrets that might inadvertently be exposed to cybercriminals in a production environment, said Van Wesep.

    HashiCorp is moving toward providing a portfolio of tools that enable DevOps teams to securely provision and manage hybrid cloud computing environments using a common workflow, he noted. A Forrester Consulting survey found nearly three-quarters (73%) of respondents are reporting this strategy is helping them reach their business goals, with another 19% adding they expected this strategy to help them achieve their business goals in the next year.

    It’s not clear whether organizations are fully embracing multi-cloud computing, but each additional cloud added to an enterprise IT environment increases the total cost of IT. The only way to mitigate those costs is to define a set of best practices for building and deploying applications that can be applied to any cloud computing environment.

    Unfortunately, many organizations will discover that, as they attempt to define those best practices, they have inadvertently become dependent on a set of proprietary application programming interfaces (APIs) that thwart those efforts.

  • Grafana Labs Slashes Time to Create Observability Dashboards

    Grafana Labs Slashes Time to Create Observability Dashboards

    At its GrafanaCON 2023 event today, Grafana Labs updated its core platform for visualizing data which makes it simpler to set up dashboards in minutes. The updates are part of a celebration of the 10th anniversary of a tool that is now widely used by DevOps teams.

    Ryan McKinley, a distinguished engineer for Grafana Labs, said Grafana 10 should help make DevOps more accessible to a wider range of practitioners with limited experience working with observability tools. The latest release also makes it simpler to share knowledge with external stakeholders via public dashboards, he added.

    In addition, Grafana 10 adds expanded role-based access control (RBAC) capabilities and streamlined implementation of the secure access markup language (SAML) to ensure authentication.

    Grafana Cloud has also been updated to provide a secure way to connect to data residing in an on-premises IT environment or in a cloud with the observability platform the company provides via a software-as-a-service (SaaS) platform.

    Finally, Grafana Labs is also making the engine it created to visualize data more accessible to third-party developers that are embedding visualizations based on Grafana within their applications, noted McKinley.

    Grafana Labs

    There are now more than 150 plugins for various data sources that have been made available to more than 20 million users of the Grafana visualization framework. Not all those users are working in DevOps environments, but Grafana is widely used to enable observability across increasingly complex IT environments. The Grafana Cloud seeks to capitalize on that popularity by adding a service that uses an instance of open source Grafana Mimir software to store data collected in a format originally defined for the open source Prometheus monitoring tool.

    It’s still early days as far as adoption of observability is concerned, but it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. Observability platforms promise to unify logs, metrics and traces to simplify launching queries to identify the root cause of an issue.

    The rate at which DevOps teams will embrace observability will naturally vary, but the biggest obstacle might not be the platforms themselves. Instead, the issue is understanding what queries can help DevOps teams better understand the root cause of an IT issue before there is a major disruption. In the long term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify issues that might lead to a disruption long before it actually occurs.

    Of course, the result of any query that gets launched needs to be visualized in a way that is easily understood. Grafana Labs is now making a case for a more integrated approach that, at its core, employs its visualization tools to make it simpler to discern what’s occurring in IT environments. After all, no matter how talented any DevOps team may be, it’s still not possible to manage what was never seen in the first place.

  • Cycode Leverages eBPF to Secure CI/CD Pipelines

    Cycode Leverages eBPF to Secure CI/CD Pipelines

    Cycode today added a Cimon extension to its application security platform that uses extended Berkeley Packet Filtering (eBPF) to thwart cyberattacks against continuous integration/continuous delivery (CI/CD) pipelines.

    Alex Ilgayev, head of security research for Cycode, said Cimon uses eBPF to inspect network connections, running processes and file modifications within a pipeline to learn standard behaviors. Armed with those insights, Cimon will then surface any anomaly in real-time, he added.

    DevOps teams can then craft and embed security and compliance rules within their pipelines based on the severity of the anomalies discovered, said Ilgayev.

    eBPF makes it possible to run sandbox programs at the kernel level without adversely impacting performance. In effect, eBPF bridges the boundary between kernel and user space by enabling developers to combine and apply logic across multiple subsystems that, historically, were completely independent of one another. That approach enables, for example, a security tool to scale to the point where it can identify threats at much higher levels of throughput to improve overall scale at a time when the volume of cybersecurity attacks continues to increase.

    Cycode is taking advantage of eBPF to enable DevOps teams to not only defend against known attacks involving malicious package installation, typosquatting, repojacking, dependency confusion, dependency hijacking and other types of dependency attacks but also zero-day threats, noted Ilgayev.

    Cycode provides a platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools. Most recently, Cycode added a Cycode Application Security Orchestration and Correlation (ASOC) module that will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    The approach enables the Cycode platform to discover, for example, dependency issues that would otherwise be missed by software composition analysis (SCA) or static application security testing tools (SAST).

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations are still struggling with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise.

    As the number of regulations specifically focused on application security steadily increase, every organization that builds software will soon need to embrace DevSecOps to better secure software supply chains. Unfortunately, developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be a primary cause of the breaches they are expected to clean up. The first step toward bridging that divide is, of course, to realize that application developers and cybersecurity teams need to be invested in each other’s success.

  • Revolutionizing DevOps With Low-Code/No-Code Platforms

    Revolutionizing DevOps With Low-Code/No-Code Platforms

    The DevOps industry is growing at an incredible pace, with its worth exceeding $8 billion in 2022. Analysts predict that the market will experience a five-fold increase and reach almost $40 billion by the end of the decade. But with this growth, there is a significant issue within the DevOps chain that continues to escalate: A widening talent gap. The U.S. Department of Labor predicted that by 2030, the global deficit of development engineers will exceed 85 million. Additionally, the demand for DevOps professionals is expected to increase by over 20% annually throughout the rest of the decade. These conflicting trends present significant challenges for software and application companies. While there is a substantial opportunity to generate revenue by creating new and better applications, the shortage of skilled personnel to develop these products is a significant roadblock. Integrating low-code and no-code tools into the DevOps process could be a viable solution to address the talent gap. These tools offer various benefits and efficiencies, including streamlining the work of existing DevOps professionals and enabling organizations to expand their teams beyond traditional personnel sources. Leveraging these tools could give companies in the DevOps industry a competitive advantage.

    Challenges of Traditional DevOps

    Traditional DevOps practices pose significant challenges for companies that hinder productivity and overall success. The first significant issue is the talent shortage. According to a report by the Manpower Group, 75% of employers consider finding tech talent their primary concern. As the demand for experienced DevOps professionals continues to grow, it is becoming increasingly difficult for companies to find the right personnel.

    Another significant challenge in traditional DevOps practices is the high learning curve. The prediction by Gartner that 75% of DevOps initiatives would fail to meet expectations by 2023 highlights the severity of the learning curve and the challenges associated with adopting DevOps practices without proper training and experience.

    To avoid delays, increased costs, and suboptimal productivity, companies should explore innovative solutions such as low-code and no-code platforms. This would enable citizen developers to contribute to the development process and streamline infrastructure management processes, enabling greater efficiency and scalability in their DevOps practices.

    How Low-Code/No-Code Revolutionize DevOps

    Low-code/no-code platforms are gaining widespread recognition for their potential to drive app development across organizations, as Gartner predicts that by 2024, 80% of apps will be developed by non-IT professionals. The adoption of these productivity tools can bring significant benefits to the DevOps landscape, particularly in the following ways.

    Reducing Workloads and Stress
    By using low-code and no-code software, organizations can distribute basic app-building and basic development tasks across the organization, freeing up skilled developers’ time and reducing their workload and stress. This significantly improves the workplace experience and enables developers to focus their time on delivering more complex, high-quality solutions.

    Accelerating Innovation With Low-Code/No-Code Platforms
    Low-code/no-code platforms can accelerate innovation by enabling developers to quickly spin up proofs-of-concept for more complex software development tasks that require coding expertise. Ideas and solutions can be tested before investing time and resources in full-scale development.

    Creating New Roles and Opportunities
    No-code platforms can create new roles and opportunities within the enterprise, such as no-code projects focused on optimizing processes and building solutions. Citizen developers without coding experience can pursue new career paths and opportunities to contribute to their companies’ success. One example is applying no-code technology to digitize paper forms across organizations. Employees without coding experience can create mobile apps that speed data collection, improve data accuracy and allow for instant digital data sharing and analysis.

    Giving Developers a More Strategic Role
    With tactical software development carried out within business units, developers can spend more of their time focused on cutting-edge technologies like mixed reality, quantum computing, and AI. This can give them a more strategic role in the enterprise and enable them to focus on the “next big thing.”

    Considerations and Challenges

    While low-code/no-code platforms have the potential to offer numerous benefits to DevOps teams, it’s important to be aware of challenges that have arisen when pairing the two successfully, and how to avoid them.

    Poorly-Designed or Insecure Applications
    With non-IT professionals developing applications, there is a higher risk of introducing vulnerabilities that could compromise the security of the application and the organization. Additionally, the lack of oversight and governance could lead to poor coding practices and technical debt. For instance, the use of new-generation iPaaS platforms by citizen integrators has made it difficult for security leaders to have full visibility into the organization’s valuable assets. Attackers are aware of this and have already taken advantage of improperly secured app-to-app connections in recent supply chain attacks, such as those experienced by Microsoft and GitHub.

    Companies need to make sure IT staff carefully check how low-code and no-code technologies are adopted and how apps are reviewed in order to reduce vulnerabilities.

    Limited Customization and Scalability
    While low-code/no-code platforms can help speed up application development by up to ten times, their limitations can create hurdles when building large, complex applications. These platforms can be useful for basic application development, but they may not be suitable for complex or highly-customized applications. For example, if your app requires robust offline capability that handles conflict resolution and on-device offline storage, you’re better off selecting a low-code platform like Alpha Anywhere than a drag-and-drop app builder like Appypie, which is a fit for less complex apps.

    Complex Integrations With Legacy Systems
    As organizations try to integrate low-code and no-code applications with legacy systems or other third-party applications, technical challenges can arise. For example, if an organization wants to integrate a low-code application with an existing ERP system, it may face challenges in terms of data mapping and synchronization. Some low-code and no-code applications are built to export data and share it well, but when it comes to integrating event triggers, business logic, or workflows, these software solutions hit limits. Buyers need to consider their requirements carefully before making a purchase.

    To address the potential challenges of low-code/no-code platforms, organizations must establish governance policies and procedures to ensure adherence to security and quality standards. This includes implementing proper access controls with zero-trust security, data privacy measures and vulnerability management processes. Organizations should work with their low-code/no-code platform providers to ensure seamless integration with other systems and scalability to support evolving needs. Along with this, regular assessments and audits of applications developed using low-code/no-code platforms can also help identify and address security risks before they turn into significant issues.

    Conclusion

    The integration of low-code/no-code platforms into DevOps practices represents a promising solution to address current challenges in the industry. By leveraging these platforms, organizations can expand their teams beyond traditional personnel sources and create a more inclusive environment for non-IT professionals to contribute to the development process. The rise of no-code is a win-win for everyone, and as early adopters seize this opportunity, they can gain a significant competitive advantage in the market. The future of DevOps is exciting, and the potential of low-code/no-code development is limitless, unlocking the innovation potential of all employees and empowering them to make a difference in their organizations.

  • Friend or Foe? ChatGPT’s Impact on Open Source Software

    Friend or Foe? ChatGPT’s Impact on Open Source Software

    OpenAI’s ChatGPT took the world by storm, amassing 100 million users in the first two months after its public launch. The continued interest in the tool has created a buzz among developers, especially those in the open source community. But this begs the question: How will ChatGPT impact open source software?

    Amid the excitement and promise that ChatGPT holds, many wonder whether the open source community, just like any other organization, should fear or embrace the technology. Certain concerns for open source contributors and developers are sparking debate as questions surrounding the origin of generated source code surface, and the possible ethical and legal implications are discussed. While valid, developers should not fear or stray away from using ChatGPT but rather shift their focus to understanding how to embrace it for positive outcomes.

    The Top Three Open Source ChatGPT Concerns

    Collaboration between contributors is the cornerstone of open source projects, which some fear will be disrupted with the increased use of AI-based tools. However, the level of synergy within the community cannot be easily taken away or replaced by tools. Instead, ChatGPT or other AI-based tools, including GitHub Copilot, allow developers to produce code more quickly and more efficiently.

    As developers increasingly use AI tooling to assist with new or enhanced code, project collaboration and oversight will help improve the AI-generated code.

    Debunking and navigating the top concerns will be imperative to take full advantage of the technology’s promise and potential.

    Validity. While the creation of code by ChatGPT has generated excitement among developers, critics argue that—without context—the validity of code can be questioned. Some open source developers worry that teams will begin to rely entirely on ChatGPT to generate code, but this concern fails to consider the humans involved in the process—today and far into the future.

    Developers don’t take ChatGPT’s output as the final word; rather, they use it as a baseline and jumping-off point to streamline their code. In fact, code is rarely created from scratch anymore. Developers rely on others’ source code. For example, code from Stack Overflow, GitHub and thousands of open source libraries that are available on public registries like npm, Maven, Nuget and PyPI. Bringing ChatGPT into the fold will not significantly change how developers source their code, but will improve development velocity, saving valuable time and associated cost.

    Training Data. Machine learning (ML) and deep learning (DL) model training must be fair, robust and explainable to avoid biases. If the data is wrong, the results will be as well. Garbage in, garbage out. Coming from ML/DL models, the code ChatGPT returns in response to prompts could raise concerns surrounding its accuracy. Like any other source (Stack Overflow, GitHub, etc.), ChatGPT’s code outputs are not guaranteed to be perfect, and developers must be mindful of this.

    However, there are more benefits of ChatGPT-trained models concerning code outputs. ChatGPT can also explain new or existing code, it can also effectively provide unit tests for code, which will help with writing better software faster.

    Ownership. Questions of ownership have surfaced regarding the use and distribution of the code that the AI tool generates. While the code that ChatGPT generates is the result of ML/DL inference from many sources, it’s the developer’s responsibility to use that code ethically and safely. It should be treated as any other public data or open source software, as not a final product and must be used in the context of your requirements. It’s also important to carefully review any code generated by ChatGPT and ensure that it doesn’t introduce vulnerabilities.

    Similar to GitHub Copilot, ChatGPT is trained by millions of lines of open source software. Code posted in prompts is likely to make it to models, too. Unlike copyrighted pieces of art and writing, the code that ChatGPT outputs should not be considered in a final state and should not be used in a way that is subject to licensing restrictions or legal implications that have dominated the conversations around its use.

    Ownership closely relates to the ethical dilemma of using AI-generated text, code and more. To address that, there are new tools that help detect whether AI generated the content and how much, which will be useful for educators concerned with students overusing the tool. This emerging area of checks and balances exemplifies the constantly evolving and improving technologies that allow humans, and in the case of open source, contributing developers to improve their craft and produce better open source software.

    ChatGPT’s Impact on Open Source Talent

    Discussions about whether ChatGPT will require new skills for existing positions or new jobs with specialized experts are ongoing. While new and exciting, ChatGPT won’t immediately create new or different jobs. Like any new tool introduced to developers, it takes time for developers to become familiar with the technology and understand how to use it best. ChatGPT is no different. For example, consider the previous push to use low-code/no-code technology. While this great technology is used to speed up the creation of apps and improve the usability for non-developers, it has taken time for organizations to properly use low-code/no-code technology. A similar perspective and trajectory will extend to the use of ChatGPT for all software development, including open source projects.

    In the coming weeks and months, it will be essential to encourage the open source community to embrace ChatGPT and explore its possibilities. Technology has already proven to be an effective educational tool. Consider asking ChatGPT for book recommendations about programming languages and coding; it delivers short descriptions for each book. Or, prompt it for the top takeaways from one specific book. By doing this, individuals can make learning so much easier. By learning from other developers and sharing resources, including results from ChatGPT, the community roots of open source will keep thriving.

    Human Involvement is Always Needed

    The public’s reaction to ChatGPT may be novel, but the idea behind the tool’s relationship to open source is not. Analyzing how ChatGPT works within the open source community reveals that it will be useful because it enhances the capabilities of developers, it doesn’t replace them.

    Whether it’s reviewing code, pair programming or learning from fellow developers, humans will not be replaced by generative AI, only enhanced. Leveraging the tool will decrease the time and effort needed to complete tasks, increasing developer quality and efficiency. The use of ChatGPT does not create new positions or overhaul current skill sets; it makes them better and empowers developers to expand their opportunities and enhance their abilities.

    Soon, ChatGPT and other AI tools will be standard practice within the open source community—or until a new technology is created and shakes up software development once again.

  • No, Dev Jobs Aren’t Dead: AI Means ‘Everyone’s a Programmer’? ¦ Interesting Intel VPUs

    No, Dev Jobs Aren’t Dead: AI Means ‘Everyone’s a Programmer’? ¦ Interesting Intel VPUs

    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: Nvidia’s CEO grabs headlines by saying your career is toast, and Intel is still fighting. (more…)

  • Linux Foundation Europe to Host RISE Open Source Project

    Linux Foundation Europe to Host RISE Open Source Project

    The Linux Foundation Europe, in collaboration with RISC-V International, announced today it will host a RISC-V Software Ecosystem (RISE) Project. Through the project, multiple organizations will contribute engineering and financial resources to harden critical open source software for use in commercial applications and enterprise IT environments.

    Founding members of the project include Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head and Ventana.

    RISC-V International is defining a set of application processors that includes software development tools, virtualization support, language runtimes, Linux distribution integration and system firmware that is intended to be used primarily in edge computing environments.

    Amber Huffman, chair of the RISE Project, said at a minimum, each of the founding members contributing €80,000 and additional engineering resources. The RISE Project deliverables will be prioritized by the RISE Technical Steering Committee (TSC) as the project looks to address performance, security and reliability issues involving open source software, she added.

    The TSC will also be able to shift skills from one initiative to another as priorities continue to evolve, Huffman added.

    The overall goal is to use a more holistic approach to eliminate duplicate work that each member of the RISC-V community would otherwise do separately to create an application processor, noted Huffman.

    The Linux Foundation Europe is an arm of the Linux Foundation that has been created to host projects that are of particular interest to organizations investing in open source software based in Europe. The RISE project is being launched at a time when the European Union debates a proposed Cyber Resilience Act that requires organizations that sell hardware platforms that connect to the internet to ensure that the devices their software runs on comply with cybersecurity best practices.

    The Linux Foundation also provides the funding for  the Open Source Security Foundation (OpenSSF) that is marshaling resources to enable maintainers of open source software to address vulnerabilities and adopt DevSecOps best practices to better ensure the security of downstream applications that incorporate that code. In addition, the OpenSSF is building out an incident management capability that will assist maintainers in the event a zero-day vulnerability is discovered.

    It’s not clear when all these investments might eventually lead to higher-quality open source software. However, it’s clear that vendors that benefit from open source software are rallying to address a range of quality assurance issues. Less clear is the degree to which enterprise IT organizations that benefit from open source software are making similar commitments.

    In the meantime, it’s not likely any of these issues will have a material impact on organizations’ reliance on open source software. The benefits of reduced costs and increasingly faster pace of innovation enabled by open source software development far outweigh the risks. However, as cybercriminals become more adept at embedding malware within software supply chains, there’s a clear need for increased vigilance.

  • CDF Marries Emporous Repository to Ortelius Management Platform

    CDF Marries Emporous Repository to Ortelius Management Platform

    The Continuous Delivery Foundation (CDF) has added the open source Emporous repository for software artifacts to an Ortelius platform for managing the software artifacts that make up a microservice.

    Ortelius was originally created by DeployHub and subsequently contributed to the CDF, which also oversees the development of the open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

    Emporous is based on a Universal Object Reference (UOR) conceptual model that enables dynamic schema registration and decentralized content-addressable reference of a wide spectrum of software artifacts. Originally developed by Red Hat, Emporous will now be managed as a sub-project within the larger Ortelius incubation-level project by the CDF.

    DeployHub CTO Steve Taylor said this integration would make it simpler to store, organize and search metadata related to software artifacts, along with the artifacts themselves, within the context of the Ortelius platform for managing microservices.

    Ortelius provides insights into the relationships and dependencies between different software components and applications. It does this by collecting and aggregating pipeline data from multiple sources within a software supply chain. Emporous will be incorporated within Ortelius to enhance metadata search capabilities and provide a single repository to store any type of artifact, from containers to jar files. It will now also be able to store metadata and also the artifacts themselves within the same Emporous catalog.

    Those capabilities will significantly improve security and compliance reporting across a software supply chain, added Taylor. DevOps and cybersecurity teams will be able to automatically apply and enforce supply chain policies and procedures, he said.

    DevOps teams need a way to aggregate all the data from the various tools they use and the data must be easily searchable. Armed with those insights, it should become simpler to surface insights into, for example, which components of an application contain known vulnerabilities.

    In the longer term, IT organizations will be able to apply machine learning algorithms and other forms of artificial intelligence (AI) to automatically surface insights that will enable DevOps teams to automate workflows, said Taylor.

    Microservices-based applications are considerably harder to build and manage than monolithic applications, but they are also easier to maintain because individual microservices can be ripped and replaced.

    Most microservices today are built using containers, but there are also microservices that are written in Java, for example. In some cases, developers view monolithic applications as being a large, less flexible microservice that they invoke via an application programming interface (API).

    There’s no doubt that the rise of microservices made application environments a lot more complex. The tools needed to simplify the management of the next generation of applications are finally starting to become more widely accessible. In theory, the number of organizations that can successfully build and deploy these types of applications should steadily increase in the months and years ahead.

    In the meantime, there’s clearly still plenty of work that needs to be done to improve the overall state of software delivery. A recent CDF survey found only 22% of respondents were using continuous integration and continuous delivery (CD) to automate the building, testing and deployment of code in a production environment. As CD becomes more distinct from CI, however, the number of organizations that can achieve that goal when deploying microservices-based applications should steadily increase.