devopsy.kinsta.cloud

Author: Mike Vizard

  • Kong Donates Kuma Service Mesh to the CNCF

    Kong Donates Kuma Service Mesh to the CNCF

    The Cloud Native Computing Foundation (CNCF) announced today it has accepted the open source Kuma service mesh developed by Kong as a sandbox level project.

    At the same time, Kong announced an update to the service mesh for monolithic and microservices-based applications that makes it easier to deploy multi-tenant instances of Kuma across multiple types of networking environments.

    A service mesh provides a layer of abstraction across networking environments that simplifies the deployment of distributed applications. Rather than having to manually configure each application service for a specific network, the service mesh automatically routes application traffic across multiple network underlays.

    Kuma is based on Envoy, an open source proxy server developed under the auspices of the CNCF. Kuma will be the second service mesh project that CNCF has accepted after Linkerd. However, Linkerd is not based on Envoy, so the CNCF is adding another service mesh project.

    Kong CTO Marco Palladino said Envoy provides an opportunity to create a lighter-weight service mesh that is easier to deploy across a distributed computing environment.

    Arguably, the best-known instance of a service mesh is Istio, which was developed by Google, IBM and Lyft for Kubernetes clusters. Istio, however, is complex to deploy and manage, and it hasn’t come under the auspices of any open source consortium.

    Palladino said given the popularity of Envoy, it only makes sense to add a service mesh that is both lighter-weight, scales better and is more extensible. For example, the latest release of Kuma adds support for global/remote control plane replication across hundreds of thousands of data plane proxies, he said.

    Also added was an ingress data plane mode that automates cross-platform and cross-cluster service mesh communication and a native universal DNS service discovery application programming interface (API) that makes it appear multiple services are all sharing the same cluster.

    As a sandbox-level project managed by the CNCF, Kong is now inviting other organizations to contribute to the development of the Kuma service. It remains to be seen which service meshes will eventually gain broad support. In addition to Kuma, Istio and Linkerd, the open source Consul service mesh from HashiCorp is vying for support. There are other proxy servers as well, such as NGINX, on which service meshes can be constructed.

    Very few IT organizations have deployed any type of service mesh in a production environment. However, as the number of microservices being deployed steadily increases, IT organizations need an easier way to enable applications to invoke network resources. Kuma provides a service mesh to address that issue that can be employed by both emerging microservices-based applications and legacy monolithic applications.

    Kuma also makes it possible to more easily secure traffic, establish service connectivity permissions and capture metrics using a combination of routing rules that can be set using APIs, says Palladino. It also comes with out-of-the-box policies for the most common service mesh use cases.

    Service meshes should also play a major role in the eventual convergence of network operations (NetOps) and best DevOps practices. Network specialists still will be needed to deploy the physical network underlay. However, network services themselves are becoming a virtual abstraction that developers can invoke within the parameters of policies defined by a central IT organization.

    The challenge now is advancing service mesh platforms to the point where the average enterprise IT team is capable of deploying and managing them.

  • OpenLegacy, Boomi Simplify Legacy Application Integration

    OpenLegacy, Boomi Simplify Legacy Application Integration

    OpenLegacy, a provider of a platform through which application programming interfaces (APIs) are layered on top of legacy application processes, announced today an alliance with Boomi, an arm of Dell Technologies that provides organizations with access to an integration platform-as-service (iPaaS) that is made available as a cloud service.

    Zeev Avidan, chief product officer for OpenLegacy, said the company’s core platform enables IT teams to convert legacy application processes into microservices that can be involved by tools such as Boomi using an API. Rather than merely providing access to an application, OpenLegacy is designed to capture all the business logic, metadata and associated middleware associated with a specific business process executing on, for example, an IMS or AS/400 platform, he said.

    The Boomi alliance extends that capability to include processes created by either citizen integrators or developers via the Boomi cloud service. That’s critical because most mission-critical applications in the enterprise still run on legacy platforms. Rather than having to rewrite those applications from scratch, Avidan said OpenLegacy makes those applications more easily accessible to other applications and platforms via a software development kit (SDK) based on Java.

    At a time when many organizations are looking to accelerate digital business transformation initiatives, Avidan said being able to programmatically invoke an entire business process accelerates the rate at which those initiatives can be completed because business processes don’t necessarily have to be re-engineered.

    In the case of Boomi, that capability is now being extended all the way to end users to make it feasible to tap into existing business processes using a set of tools that already have been adopted by more than 11,000 organizations.

    OpenLegacy is making a case for DevOps teams to think in terms of legacy business processes rather than individual applications. Historically, many organizations have relied on enterprise service bus (ESB) platforms to integrate applications. However, a DevOps team still has to manually integrate all the software components that make up a business process once application environments are connected.

    Legacy platform integration in the absence of OpenLegacy becomes the digital equivalent of an archaeological dig, said Avidan, noting many organizations wind up hiring expensive systems integrators to accomplish the task.

    In the wake of the COVID-19 pandemic, there is clearly a lot more interest in modernizing business processes. Many employees are working from home for the foreseeable future. Cloud services such as Boomi provide a means of enabling end users to craft workflows on their own. The challenge has always been finding a way to easily connect those workflows to transaction processing systems and other systems of record around which the business depends.

    It’s not clear to what degree providing that level of access will drive a burst of business process innovation. However, DevOps teams that spend an inordinate amount of their time integrating new applications with legacy business processes might be keen to leverage an approach the promises to turn those business processes into a reusable microservice.

  • DevOps Deeper Dive: Apple Adds Fuel to ITSM Fire

    DevOps Deeper Dive: Apple Adds Fuel to ITSM Fire

    Apple’s acquisition this week of Fleetsmith, a provider of IT service management (ITSM) tools for Apple devices, is reigniting a fierce debate over how best to manage endpoints in heterogeneous IT environments.

    Fleetsmith, along with rivals including Jamf Software and IBM, provides ITSM tools that only manage Apple devices. The company argues that the IT teams managing Apple devices prefer to use tools that feel like MacOs or iOS applications. However, both enterprise environments typically have both Apple and Windows devices. As such, many IT teams have adopted ITSM tools that allow them to centrally manage both platforms.

    Until now, Apple has been relatively neutral in terms of how best to manage its devices. The acquisition of Fleetsmith signals the company is about to focus more on ITSM at a time when many organizations need to revamp their approach to managing endpoints in the wake of the COVID-19 pandemic.

    With more individuals likely to be spending more time working from home, the management of highly distributed endpoints becomes even more challenging. Apple has yet to outline its plans for Fleetsmith or say whether it will continue to support Fleetsmith customers. The assumption is the company will incorporate the Fleetsmith ITSM tools into its portfolio.

    Mac and Windows: Can’t We All Get Along?

    In the meantime, providers of platforms capable of managing heterogeneous endpoints are pressing their cases for increased centralization. Many IT organizations have adopted separate tools for managing Windows and Apple devices; centralizing the management of endpoints presents those organizations with an opportunity to reduce costs.

    “IT teams don’t want to hop around infrastructure, said Greg Keller, CTO for JumpCloud, a provider of ITSM tools. “Centralization creates this single-pane-of-glass efficiency.”

    The need to centralize endpoint management will become even more pronounced as desktop computing moves into the cloud, added Pradyut Roy, a product manager for ManageEngine, a provider of ITSM tools that also span multiple types of endpoints.

    “There is going to be a huge drive to centralize the control plane,” said Roy.

    A survey of 519 IT professionals published this week by ManageEngine finds 47% of organizations are planning to provide more mobile-capable assets to employees. As those endpoints are rolled out, IT teams will need ITSM platforms accessible from anywhere that enable them to manage devices regardless of what network they are connected to at any given time.

    Apple doesn’t have the greatest reputation when it comes to appreciating ITSM requirements in the enterprise. For example, it often changes application programming interfaces (APIs) in ways that are not backward-compatible, so providers of ITSM tools often must make significant updates to their tools. That API issue is likely to become even more significant as organizations that have adopted best DevOps practices look to extend them to applications running on Apple devices.

    ITSM is clearly in a state of flux. Most IT organizations rely on legacy ITIL-based processes to manage IT infrastructure consistently. As businesses begin to require more flexibility, many of those ITIL-based processes will need to be revisited. The opportunity—and the challenge—now is finding a way to converge ITIL and DevOps practices across as many different types of endpoints as possible.

  • Red Hat Extends Reach of Ansible Automation Framework

    Red Hat Extends Reach of Ansible Automation Framework

    Red Hat this week launched a collection of downloadable workflows for automating IT processes that will be made available via the Ansible Automation Hub.

    At the same time, Red Hat has updated the Red Hat Ansible Automation Platform to add an automation services catalog to keep track of workflows and a return on investment (ROI) calculator that enables IT teams to determine which workflows are the most valuable based on usage.

    Red Hat also updated the core Red Hat Ansible Tower automation engine to streamline processes and reduce bottlenecks.

    Tom Anderson, vice president for the Red Hat Ansible Automation Platform at Red Hat, said Red Hat Certified Ansible Content Collections includes workflows from Red Hat and vetted third-party providers. As such, IT teams employing Ansible to automate the management of IT can have confidence these playbooks and workflows are both secure and supported, he said.

    Red Hat decided to separate the management of Ansible workflow content from the underlying platform because it’s become apparent new workflows are being made available at a faster cadence than updates to the core Red Hat Ansible Automation Platform, he noted.

    As part of that effort, Red Hat this week is also making available additional automated workflows that leverage Red Hat Tower to automate tasks and jobs via a centralized console, along with workflows that leverage Red Hat Satellite systems management software and the Red Hat Insights monitoring service.

    Anderson said interest in IT automation has expanded significantly in the wake of the economic downturn brought on by the COVID-19 pandemic. Many organizations have either frozen IT headcount or been forced to reduce the size of their IT staff. However, managing IT environments continues to grow more complex as emerging technologies such as microservices and Kubernetes clusters gain momentum.

    Some organizations may, of course, opt to put a hold on adopting new platforms, but just as many are continuing to invest in cloud-native technologies necessary to drive digital business transformation initiatives, which require applications that are both more flexible and resilient. Because of that, Anderson said, the urgency surrounding IT automation project has increased.

    In fact, he noted, Red Hat has created “office hours” during which the company provides IT teams with access to Red Hat personnel at specific times to provide additional guidance.

    As an open source project, Ansible is gaining traction as a management framework because it provides a declarative approach to automating IT that doesn’t require IT operations teams to learn how to code. Ansible is also being embraced by IT infrastructure providers including Cisco Systems and Dell Technologies, which makes it easier for IT teams to create playbooks that automate tasks across multiple platforms. Over time, those cross-platform capabilities foster the creation of an ecosystem that further increases Ansible momentum, Anderson noted.

    There’s no doubt IT teams were increasing their reliance on IT automation frameworks prior to the pandemic. Now, however, automating the management of IT is not just about increasing productivity and efficiency; in many cases, it’s become a matter of survival.

  • Snyk Report Finds Decline in Open Source Vulnerabilities

    Snyk Report Finds Decline in Open Source Vulnerabilities

    Snyk, a provider of tools for discovering and remediating vulnerabilities in open source code, today published a report that finds the number of new vulnerabilities discovered in open source software packages has declined 20% on a year-over-year basis. However, the bulk of the vulnerabilities being discovered are considered to be high severity, the report finds.

    Alyssa Miller, application security advocate for Snyk, said the decline represents a significant improvement as developers become more conscious of cybersecurity issues. As long as humans write code there will always be security issues; however, Miller said the latest report suggests improvements in open source security are likely to continue as more developers embed vulnerability scanning tools within their application development tools.

    Those tools enable developers to discover vulnerabilities in their code long before they ever find their way into a production environment, she noted.

    The Snyk report is based on a survey of 500 developers, security practitioners and IT operations staff and scans run by Snyk on open source software packages. It finds the top vulnerability currently impacting scanned projects is prototype pollution, which results in objects in JavaScript applications being modified, was found in nearly 27% of all the projects Snyk surveyed.

    Better-known vulnerabilities, such as cross-site scripting attacks, are still being reported in high numbers, but Snyk reported the number of projects actually being impacted by this class of vulnerabilities is fairly low. These threats appear to be getting caught and remediated much earlier than many lesser-known vulnerabilities, said Miller.

    Want to learn more? Tune in Tuesday, June 30, at 11 a.m. Eastern for The State of Open Source Security in DevSecOps Pipelines: A Panel Discussion, a DevOps.com webinar hosted by Snyk

    The report notes the bulk of the vulnerabilities discovered continue to involve indirect dependencies (70%) within packages built using tools such as Node Package Manager (86%), Ruby (81%) and Java (74%). The survey also finds 60% of organizations do not fully inventory the dependency trees in their software.

    Despite the progress being made, Miller said it’s clear much work needs to be done. For example, the survey finds more than 30% do not review Kubernetes manifests for insecure configurations. Requirements for security-related resource controls in Kubernetes are also not widely implemented, according to the survey. Many container images labeled as final contain large numbers of known vulnerabilities—the 14.3 Node image had 642 known vulnerabilities, for example.

    In addition, 44% of the participants indicated that they are currently using Kubernetes to orchestrate their containers. Many respondents who said they use Kubernetes also employ Helm to package applications (40%). According to the report, 68% of stable Helm Charts contain an image with a high severity vulnerability.

    Ironically, Miller noted many of the same vulnerability issues that have derailed many “golden image” initiatives in the past decade appear to be manifesting themselves again in the age of containers.

    Finally, the survey finds 57% of respondents have implemented static code analysis tools (SAST), followed by employing security test cases during quality assurance (28%); dynamic application security testing (DAST) (20%); software composition analysis (19%); and threat modeling (19%).

    Despite that relatively low reliance on security tools in the development process, it’s clear progress is being made as DevOps teams and cybersecurity teams collaborate more closely. As more security tools are incorporated into the DevOps pipeline, application security should begin to improve at even faster rates.

  • Survey Finds SRE Role Remains Largely Aspirational

    Survey Finds SRE Role Remains Largely Aspirational

    Monitoring tools provider Catchpoint, in collaboration with the DevOps Institute, has published a survey that finds there is a significant gap between the tasks and duties that define the role of what a site reliability engineer (SRE) should be versus what is actually occurring within IT organizations that have hired SREs.

    Based on a survey of 600 IT professionals who have SRE titles or individuals that identify themselves as performing SRE-like tasks, the “Catchpoint SRE 2020 Report” finds the bulk of respondents are still squarely focused on managing IT infrastructure.

    Google, which is widely credited with defining the SRE role, maintains SREs should be spending as much time managing applications as they do infrastructure. Survey respondents on average are spending 75% of their time on operations. Only 14% of respondents said they are spending 50% or more of their time on application development processes. More than have of respondents (53%) also noted they are becoming involved too late in the application life cycle.

    The Catchpoint survey finds the top three tasks survey respondents associated with their roles were monitoring and alerting (93%), dashboarding (73%) and managing infrastructure as code (71%).

    Catchpoint CEO Mehdi Daoudi said one of the most telling aspects of the survey is only 53% of respondents identify observability as a task associated with their role, even though that’s a core tenet for best DevOps practices. Further down the list of DevOps tasks were testing (41%), telemetry (38%) and chaos engineering (26%).

    Daoudi said it’s probable many IT organizations are adding SREs in anticipation of furthering their DevOps ambitions. Not every SRE has all the skills required, but as more of them gain hands-on experience it’s likely many will grow into those roles. In fact, 41% of respondents said half or more of their work revolves around mostly manual, repetitive tasks that could be automated. More than half of respondents (52%) said they spend too much time on debugging-related tasks.

    Part of the challenges many IT organizations face derives from not putting enough focus on automating the management of legacy IT infrastructure, said Daoudi. Every time a new platform is adopted there’s a rush to operationalize it. However, IT teams frequently overlook the need to automate the management of rote tasks to free up more time to learn how to manage new platforms such as Kubernetes.

    Going forward, the survey finds nearly 50% of respondents said they believe they will be working remotely post COVID-19. More than half of respondents also said personal challenges included staying focused and having a good work/life balance while working from home.

    The degree to which SRE titles are being adopted to enable IT professionals to justify a raise or simply pad their resumes is unknown. However, the focus on the SRE role is likely to increase in the wake of the economic downturn brought on by the COVID-19 pandemic. In theory, a single SRE should be able to manage all the tasks that previously might have required as many as 10 IT administrators. At a time when many organizations are looking to reduce the total cost of IT, the number of full-time employees required to manage IT environments has clearly become a major concern.

  • Puppet Launches Relay to Simplify Automating DevOps Workflows

    Puppet Launches Relay to Simplify Automating DevOps Workflows

    Puppet today made available a public beta of Relay, an event-driven platform through which DevOps teams can automatically invoke pre-configured workflows.

    Company CTO Deepak Giridharagopal said Relay listens for DevOps events that can then trigger an automated workflow such as automatically deleting underutilized cloud resources, enforcing cybersecurity controls or remediating known issues.

    Relay connects to dozens of DevOps tools, cloud services and application programming interfaces (APIs) to automate workflows across a wide range of platforms, including PagerDuty, GitHub, Datadog, Jira, Terraform, Slack and others.

    Giridharagopal said Relay will also enable IT organizations to reuse workflows versus continually cobbling together one-off workflows for processes that address routine use cases that can be tackled using existing content.

    At the root of that issue is tool sprawl within DevOps environments. Each DevOps team tends to create their own workflows using their preferred tools, even though they may be replicating a workflow process that has already been addressed using other tools. Relay provides a means to reuse workflow across disparate DevOps tools, which Giridharagopal said should significantly increase overall DevOps productivity.

    The Relay platform is also designed to be extensible in that it also allows DevOps teams to create custom workflows that can then be reused by other members of DevOps teams, he added.

    Giridharagopal said with the rise of microservices it’s apparent workflow automation within DevOps environments is about to become a more pressing issue. As the number of individual services that need to be managed increases, the need to automate workflows across more complex IT environments becomes more critical. DevOps teams can’t effectively manage modern cloud-native applications relying on manual workflow processes, he said.

    Relay is part of a broader shift toward event-driven architectures, which are gaining increased traction within IT environments. While event-driven architectures have been around as a concept for decades, the emergence of platforms based on, for example, serverless computing frameworks are changing how IT resources are invoked. Via any number of APIs, it’s feasible to automate a wide range of IT functions using these types of platforms.

    Of course, the biggest challenge for many organizations has been building automated workflows that work consistently across multiple platforms. The level of process expertise required to build those workflows is not inconsequential. Puppet, via Relay, is providing pre-configured workflows to address some of the more common use cases in a DevOps environment. DevOps teams will still need to build their own custom workflows to address more complex use cases. However, platforms such as Relay promise to sharply reduce the time spent creating scripts and associated workflows to address routine tasks.

    In the meantime, interest in all forms of IT automation is on the rise in the wake of the economic downturn brought on by the COVID-19 pandemic. IT organizations are moving quickly to reduce the total cost of IT by automating as many processes as possible. In many cases, it’s not clear when some IT organizations might be able to add additional headcount anytime soon. Automation, as such, is now as much about survival as it is simply trying to increase productivity.

  • SaltStack Looks to Automate DevSecOps Processes

    SaltStack Looks to Automate DevSecOps Processes

    SaltStack announced today it has integrated its automation framework with a variety of third-party security platforms to further the adoption of best DevSecOps processes.

    Mehul Revankar, director of product management for SaltStack, said version 6.3 of SaltStack Enterprise provides integration with offerings from Splunk, Tenable, Qualys, Rapid7 and Kenna Security. Data generated from vulnerability scans conducted using tools from Tenable, Qualys and Rapid7 can be directly imported into SaltStack Enterprise to inform automated DevSecOps processes, while integration with Kenna Security makes it easier to automate and prioritize vulnerability remediation based on the level of risk.

    Revankar said that latter capability is crucial because remediation efforts should not be prioritized based on the severity of a vulnerability alone. For example, a vulnerability may be discovered in an application that sits behind a firewall, but if that application doesn’t provide access to the web an organization may decide to not patch that vulnerability immediately regardless of its severity because the risk of a breach is still relatively low, he said.

    These capabilities will enable SaltStack Enterprise to serve as a foundation for providing security orchestration, automation and response (SOAR) capabilities within the context of a DevSecOps process by making it easier to incorporate cybersecurity within the context of a larger playbook for automating the management of IT, he added.

    Most of those playbooks will be developed by DevOps teams in collaboration with cybersecurity professionals, noted Revankar.

    In addition to improving DevSecOps processes, SaltStack hopes to make it easier for external applications such as Splunk and Datadog to consume data generated by its framework by providing compatibility with Prometheus, an open source IT monitoring tool developed under the auspices of the Cloud Native Computing Foundation (CNCF). A SaltStack Enterprise Splunk add-on tool has been added to the Splunkbase repository.

    SaltStack is also making available a performance and health dashboard to enable DevOps teams to track 25 SaltStack Enterprise metrics that are surfaced using the Prometheus data format.

    The open source Salt framework on which SaltStack Enterprise is based has emerged as a popular option for automating IT processes. Because it is based on Python, the barrier to adoption for Salt in terms of programming expertise is comparatively low to other programming languages. As such, more IT operations teams have been inclined to learn Python to leverage Salt to automate processes.

    Like most vendors that have adopted open source business model, SaltStack extends the capabilities of Salt via an enterprise edition that it both extends and provides commercial support.

    Interest in IT automation is on the rise as organizations of all sizes look to maximize what limited cybersecurity resources they have and cut costs. IT automation in the form of SOAR presents an opportunity to consistently apply cybersecurity policies more broadly without having to increase the size of the IT organization.

    The challenge, of course, is having the expertise required to build a playbook. In the case of open source frameworks, many of those playbooks are shared among the members of a community such as Salt. Regardless of how those playbooks are acquired, it’s clear that as IT becomes increasingly more complex most IT organizations are not going to be to do without them.

  • Cloud Foundry Foundation Updates CLI to Extend DevOps Processes

    Cloud Foundry Foundation Updates CLI to Extend DevOps Processes

    The Cloud Foundry Foundation (CFF) today released an update to its command-line interface (CLI) that will enable DevOps teams to build more granular and complex workflows spanning multiple processes across the open source platform-as-a-service (PaaS) environment.

    Announced at the Cloud Foundry North American Summit, version 7 of the Cloud Foundry CLI employs updates to the application programming interfaces (APIs) exposed via the Cloud Foundry PaaS to invoke package, droplet, build and process control resources while adding resources such as sidecars, manifests and deployments.

    The updates to the CLI and associated APIs will make it possible to enable rolling application deployments, run multiple processes within the same container and add metadata to objects.

    Chip Childers, executive director of the CFF, said most of the organizations that have adopted the Cloud Foundry PaaS are already fairly advanced when it comes to implementing best DevOps practices. The latest version of the CLI will make it possible to tighten DevOps feedback loops within the PaaS environment.

    In general, CFF is positioning the Cloud Foundry PaaS environment as a common framework for building and deploying applications on traditional virtual machines and Kubernetes clusters. The CFF has launched an incubation project, dubbed KubeCF, that enables a virtual instance of the Cloud Foundry runtime to be deployed on Kubernetes. At the same time, the CFF has made available Project Eirini, another incubation project that enables the Cloud Foundry scheduler to be replaced by Kubernetes, and Project Quarks, which allows the CF Application Runtime to be packaged using containers.

    The CFF has also launched Cloud Foundry for Kubernetes (cf-for-k8s), a more ambitious effort to replace the underpinnings of the PaaS environment with a Kubernetes foundation. That initiative should result in Cloud Foundry requiring much less IT infrastructure to be deployed. The CFF has also committed to embracing other cloud-native technologies such as the Istio service mesh.

    As part of that effort, the Bosh framework that the CFF created to automate the deployment of its PaaS will also eventually be replaced by a framework optimized for Kubernetes environments.

    Childers said it’s now clear Kubernetes will mature to the level required to support an enterprise-class application development environment. The opportunity now is for IT vendors such as VMware, SUSE and others to deliver an application development environment that makes developers more efficient than any other on cloud-native infrastructure, said Childers.

    For example, VMware today is making available a public beta of the VMware Tanzu application service for Kubernetes based on the cf-for-k8s project.

    Contributors to the CFF project are clearly trying to make up for lost time. Rival PaaS environments such as Red Hat OpenShift have long been integrated with Kubernetes. The CFF community, however, is betting more enterprise IT organizations will embrace Kubernetes once they discover various distributions of a PaaS environment they already rely on is available on that platform.

    Whatever the path chosen, the one thing that is clear is the Cloud Foundry PaaS is about to become a lot more accessible to organizations that, no matter how great the developer experience, previously balked at its overall size.

  • JFrog Extends Reach and Scope of CI/CD Platform

    JFrog Extends Reach and Scope of CI/CD Platform

    At its online JFrog swampUP Conference today, JFrog announced it has extended the reach of its ability to distribute software to include options based on peer-to-peer and content delivery network (CDN) mechanisms.

    In addition, JFrog expanded the reach of the JFrog Pipelines continuous integration/continuous delivery (CI/CD) platform, enabling DevOps teams to build their own library of reusable pipeline steps via an Extensions Development Kit (EDK). DevOps teams can encapsulate frequent and common actions in their pipelines that can run sequentially or in parallel. That approach also serves to reduce the need to rely on plugin modules to extend a JFrog delivery pipeline.

    Finally, JFrog has added another free public artifact center that provides a means to manage Helm charts, which are widely employed to deploy applications on Kubernetes clusters. ChartCenter is intended to make it easier to deploy microservices based on containers.

    JFrog CEO Shlomi Ben Haim said all three additions to the JFrog portfolio extends the ability for users to manage the entire DevOps workflow from integration to delivery regardless of what type of software is being deployed or where it is installed.

    As DevOps teams look to deploy software on edge computing platforms within an internet of things (IoT) environment, Ben Haim said they will need to be able to employ either a peer-to-peer or CDN-based approach to manage that process efficiently. Existing mechanisms are not designed to handle large volumes of artifacts that need to be delivered in a specific order. The new mechanism added to the JFrog CI/CD platform enables DevOps teams to achieve that goal without having to acquire a separate platform, he said.

    In fact, Ben Haim noted, efficiently delivering software to edge computing platforms represents the next great leap forward for DevOps. Achieving that goal, however, will only be practical if the entire CI/CD workflow process keeps track of all the dependencies and metadata end-to-end, he said, noting that approach will enable endpoints to pull only the delta code required to update the software after an application is initially deployed.

    There is no doubt extending best DevOps practices to edge computing platforms will be a major challenge. Most DevOps teams already struggle with CD because each platform software is being deployed on is unique. Because of a general lack of standardization in terms of potential endpoints that might be deployed at the edge, that “snowflake” issue is likely to become even more exacerbated as IT environments become more distributed than ever.

    In general, Ben Haim said far too much of the DevOps focus continues to be on source code management when in reality the biggest issue IT organizations face is how to efficiently manage binaries. At a time when organizations are making massive investments in digital business transformation, Ben Haim noted the rate at which software is deployed and updated is about to accelerate dramatically.

    As such, Ben Haim said it’s now only a matter of time before DevOps workflow processes will need to be able to scale well beyond their current limits.