devopsy.kinsta.cloud

Author: Mike Vizard

  • Cosmonic Unveils PaaS for Building Wasm Applications

    Cosmonic Unveils PaaS for Building Wasm Applications

    Cosmonic today at the KubeCon + CloudNativeCon North America conference unveiled a platform-as-a-service (PaaS) environment for building cloud-native applications using Web Assembly.

    Based on the open source wasmCloud distributed computing environment now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), the Cosmonic PaaS gives developers access to a lightweight environment that makes it simpler to quickly build applications that can run anywhere.

    Cosmonic CEO Liam Randall said a PaaS enables developers to achieve that goal by making databases and other non-functional services available via an abstraction layer that eliminates the need for developers to provision these resources themselves.

    Designed to be deployed on any cloud service or on-premises IT environment, the Cosmonic PaaS also enables developers to define their own laptops, cloud resources or entire data center by combing resources to create Constellations. Cosmonic also enables developers to build a Super Constellation by adding customer-hosted components to the services provided by Cosmonic.

    Originally developed under the auspices of the World Wide Web Consortium (W3C) for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The wasmCloud project was created by Cosmonic to provide an open source application runtime that hosts components, written as Wasm modules, that can then be loosely connected to build applications. Cosmonic reports there are now more than 100 members of the wasmCloud community.

    The Cosmonic PaaS extends the capabilities provided by wasmCloud so developers can now more easily build Wasm applications via an abstraction layer defined by Cosmonic. Those applications are also more secure than applications built using previous software artifacts because all Wasm code is executed in a stateless and reactive sandbox that prevents malware from moving from one software component to another.

    It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Every earlier format for building applications locked developers into a specific platform. Wasm is the first software artifact that enables applications to run on any platform, including Linux and Windows, without any modification required.

    Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.

    Obviously, Wasm has major implications for DevOps teams, and Randall said Cosmonic is working toward integrating its PaaS with multiple continuous integration/continuous delivery (CI/CD) platforms.

    It’s not clear how quickly Wasm will drive a transition to another era of computing, but the ramifications for how IT is managed in the next era of cloud-native computing could be profound. It remains to be seen how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that there are an increasing number of platforms that will make it possible to more easily embrace Wasm.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it just that much easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered. We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Direct Contact

    ZoomInfo Engineering
    Waltham, Mass.
    Cloud Security Operations Engineer
    $145,000 to $180,000

    Dice.com

    Orion Business Innovations Careers
    Montvale, N.J.
    DevOps and Engineering Manager
    $140,000 to $160,000

    Indeed.com

    Liberty Mutual Insurance
    Remote
    Scrum Master II – Secure DevOps
    $131,000 to $152,300

    LinkedIn

    Kyndryl
    Denver, Col.
    Cloud DevOps
    $120,000 to $200,000

    SimplyHired

    Penguin Computing
    Fremont, Calif.
    DevOps Engineer
    $120,000 to $170,000

  • OpsVerse Adds Backstage Catalogue to Managed DevOps Service

    OpsVerse Adds Backstage Catalogue to Managed DevOps Service

    OpsVerse this week added an open source Backstage catalogue software for building developer portals to its managed DevOps service.

    Originally developed by Spotify, Backstage makes it possible to centralize the management of multiple services that are being built and maintained by multiple developer teams. Backstage is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    OpsVerse CEO Arul Francis said the company is now employing Backstage to create a centralized control plane dubbed OpsVerse ONE through which organizations can more easily centralize the management of a DevOps toolchain. Every applications team can see all the services and related resources they own and then via a single click launch a project, he noted.

    The managed OpsVerse platform is based on curated editions of open source software such as Argo continuous delivery (CD) and Prometheus monitoring software that OpsVerse enables organizations to access as a set of software-as-a-service (SaaS) applications. Those applications can then either be deployed in cloud platforms made available by Amazon Web Services (AWS), Microsoft or Google or in an on-premises IT environment.

    The addition of OpsVerse ONE will also make it simpler to extend the OpsVerse toolchain via more than 80 plugins that are currently available for Backstage catalogue software, noted Francis.

    It’s not clear what degree organizations are embracing managed DevOps platforms but at the very least smaller organizations should find it simpler to embrace best DevOps practices by relying on a managed service. There are also plenty of larger organizations that may determine that continuing to manage DevOps toolchains has become problematic after years of integrating various tools and platforms in ways that now are both challenging to maintain and secure. OpsVerse claims to have in the last six months already tripled the number of customers it supports.

    As application development becomes more complex to manage in the age of microservices, many organizations are at a crossroads. They need to decide to what degree it makes sense to continue to devote resources to managing DevOps platforms versus consuming them as a cloud service. Many of the resources that are now allocated to managing DevOps platforms could theoretically be shifted toward building and deploying more applications. In some cases, organizations may decide to continue to rely on legacy DevOps platforms to maintain existing applications while employing a cloud service to build modern cloud-native applications that have many more dependencies than monolithic applications.

    Regardless of the degree to which organizations decide to rely on managed services, platforms such as Backstage as it continues to evolve will make it simpler to extend open source toolchains. Spotify developed Backstage to bring some order to its own internal application development and deployment processes before deciding to contribute Backstage to the open source community. While Backstage is still an incubation-level project within the CNCF, it’s already being used across multiple DevOps production environments to make it easier to integrate additional tools without having to sacrifice their ability to centrally manage a DevOps environment.

  • Cisco Unveils 800G Networking Platform to Advance DataOps

    Cisco Unveils 800G Networking Platform to Advance DataOps

    At the Open Compute Project (OCP) Global Summit conference, Cisco announced it developed an 800-gigabit switch that consumes significantly less power than the previous generation of its networking equipment.

    Thomas Scheibe, vice president of product management for cloud networking for Cisco’s Nexus and ACI product line, said the throughput provided by the latest 7-nanometer iteration of Cisco One ASIC processors is primarily needed by organizations processing massive amounts of data to train artificial intelligence (AI) models either in a local data center or in the cloud. The challenge is that many of the organizations are looking to build AI models that process massive amounts of data while simultaneously reducing their IT infrastructure’s carbon footprint, he noted.

    Cisco has been able to achieve that goal by continuing to invest in proprietary ASIC processors; they are at the core of its networking portfolio to improve data operations (DataOps), said Scheibe. Many IT teams are also looking to replace legacy network routers and switches that consume more power and reduce energy costs by as much as 77%, added Scheibe. In terms of climate impact, Cisco claimed its 8111-32EH switch can now provide 25.6Tbps at 15% of the power requirement. Cisco projected that switch will save about 10,000 kg CO2e per year compared to a 12.8Tbps switch. That equates to the greenhouse gas emissions generated by an average gasoline-powered passenger vehicle driving 26,155 miles, according to Cisco.

    IT teams also have the option of deploying either Cisco’s network operating system or SONiC—Software for Open Networking in the Cloud—network operating system (NOS).

    Cisco is also providing IT organizations with the option to configure its latest routers and switches to run at either 800, 400 or 100 Gigabits with an eye toward upgrading throughput sometime in the future.

    In general, DataOps as an IT discipline is maturing as organizations realize they need to implement best practices to optimize data flows across their organization. Cisco is giving IT teams the option of employing a standard Ethernet fabric or an alternative fabric that increases throughput by predicting which packets need to be delivered to a specific location based on their attributes and the behavior of previous network traffic. As the volume of data that needs to be accessed by low-latency applications continues to expand, DataOps will become a more critical IT discipline. Historically, storage administrators tended to be responsible for data management, but as these applications continue to proliferate, a new class of DataOps engineers is emerging to optimize the flow of data across distributed computing environments.

    In the longer term, it’s not clear how much carbon dioxide emissions are factoring into IT decisions these days, but there are organizations that have begun to track it as part of an effort to lower their carbon emissions. Most cloud service providers have also committed to being carbon neutral. Cisco is betting achieving that goal will require IT infrastructure upgrades at a time when the amount of data that needs to be processed will only continue to exponentially increase.

  • Sonatype Report Surfaces Scope of Known Vulnerability Challenge

    Sonatype Report Surfaces Scope of Known Vulnerability Challenge

    Sonatype this week published a State of the Software Supply Chain Report that found a 633% year-over-year increase in malicious attacks aimed at open source software residing in public repositories.

    In addition, Sonatype launched a Sonatype Safety Rating system that employs machine learning algorithms and other metrics to identify the most secure open source components stored in those repositories.

    The report found 96% of open source Java downloads have known vulnerabilities that could have been avoided if an available, more secure version had been used. Collectively, the report estimated there were 1.2 billion known-vulnerable dependencies that could be avoided if developers had only been aware that a later version of a software component was available.

    According to the report, the average Java application contains 148 dependencies. Updates to Java applications are, on average, made 10 times a year, so development teams are being asked to track 1,500 dependency changes per year.

    Sonatype CTO Brian Fox said the report makes it clear that organizations are not assuming enough responsibility for using open source software that has known vulnerabilities. In effect, organizations are blindly and recklessly using software components without any real appreciation of the associated risks, he said.

    Rather than a knee-jerk reaction to each new zero-day vulnerability that is discovered, Fox said, IT teams need to focus on putting processes in place to make sure the latest, most secure edition of any given software module is being used. A survey of 662 engineering professionals included with the report, however, found 68% of respondents were confident that their applications were not using known vulnerable libraries. Nevertheless, a random sample of enterprise applications conducted by Sonatype found 68% contained known vulnerabilities.

    Overall, the report surmised that consumption of open source software will soon surge past an estimated 3.1 trillion total requests, with six out of every seven vulnerabilities being the result of a transitive dependency created by indirect relationships between software components. At the current rate of consumption, it’s fairly clear that the processes used to build and deploy applications today are insane given how dependent organizations are on applications, said Fox.

    In the wake of a series of high-profile security breaches, there is, fortunately, a lot more focus on securing software supply chains today than there was this time last year. The scope of the challenge, however, is mind-boggling when you consider the totality of applications already deployed in application environments that have known vulnerabilities. Organizations need to first make sure they are remediating vulnerabilities in their most critical applications while at the same time implementing DevSecOps best practices. This will ensure as few vulnerabilities as possible find their way into the next generation of applications.

    Obviously, these application security issues are not going to be resolved overnight. DevOps teams will be spending the next several years addressing a level of technical security debt that has been allowed to accrue for more years than anyone in IT really cares to admit.

  • Datadog Extends Reach of Integrated DevOps Platform

    Datadog Extends Reach of Integrated DevOps Platform

    At its Dash 2022 conference, Datadog announced today it is extending the reach of its namesake cloud-delivered monitoring and observability platform to address continuous testing, application security and cost management.

    In addition, Datadog has made available in beta a Data Streams Monitoring tool that makes it simpler to identify upstream issues that are likely to impact DevOps workflows. Also in beta is a Dynamic Instrumentation tool that makes it possible to employ Datadog agent software to collect data on the fly from specific source code to investigate performance issues. Datadog is also making available in beta a Resource Catalog to make it easier to navigate cloud resources that IT teams are employing and has added a Datadog Workflows tool to create blueprints to for automating repeatable processes.

    Datadog is also expanding the reach of its Watchdog telemetry analysis service infused with machine learning algorithms to add beta support for containers. There is also now a beta of an Event Management tool that DevOps teams can employ to more easily investigate a stream of related alerts using the Watchdog service.

    The Datadog Continuous Testing service, now generally available, provides DevOps teams with a workbench for generating and maintaining tests that can be integrated within continuous integration (CI) workflows. Datadog has also added an Intelligent Test Runner tool, in beta, to enable DevOps teams to only run tests that need to run when a change is made by analyzing code execution paths to increase developer productivity.

    Renaud Boutet, senior vice president of product at Datadog, said the goal is to make it possible for DevOps teams to create and run tests from within the Datadog user interface in parallel using a set of no-code tools without having to employ scripts. The capability will make it possible to automatically generate tests using data collected by the Datadog platform as part of an infinite DevOps workflow loop, he added.

    At the same time, Datadog is making generally available a cloud security management service that combines its existing cloud security posture management (CSPM) service and the cloud workload security (CWS) service to provide an integrated cloud-native application platform (CNAP) at no additional cost. In addition, Datadog is making it possible to block access to application components that are under attack or might be attacked in real-time based on the known vulnerabilities detected using tools that are currently in beta.

    That approach reduces the total cost of cybersecurity by providing IT teams with a single service through which they can manage application security using a platform Datadog gained last year with the acquisition of Sqreen.

    Finally, Datadog is making generally available a cloud cost management tool that leverages its monitoring capabilities to enable organizations to automatically attribute spend to applications, services and individual teams. Changes to spending patterns that impact costs are surfaced alongside the same tools IT teams are already using to monitor their cloud computing environment. That unified visibility increases awareness of costs in a way that encourages DevOps teams to optimize the utilization of multiple classes of cloud resources.

    The services being added are extensions of a Datadog platform that employs a single set of agents it provides. The Datadog platform also supports the open source OpenTelemetry agent to deliver a wide range of services. That approach eliminates the need for IT teams to deploy multiple agents each time they add an additional monitoring, security, testing or cost management tool.

    Datadog has been making a case for an integrated platform that reduces the level of integration effort DevOps teams would otherwise need to expend when deploying separate point products to address monitoring, observability, security and cost management issues. That approach makes it easier for DevOps teams to collaborate and reduces the total cost of DevOps. In contrast, each time a DevOps teams adds a point product to address a specific issue, they need to deploy and maintain a separate set of agents.

    In the longer term, it’s not clear how problematic that agent issue will be once open source OpenTelemetry agent software is more widely employed. However, it may still be years before open source software provides the same capabilities that are available today using proprietary agent software.

    It may take some time before every application is as fully instrumented as it should be, but as monitoring and observability platforms continue to evolve, it is possible to more proactively manage application environments.

  • Red Hat and IBM Pledge to Bring NLP to Ansible

    Red Hat and IBM Pledge to Bring NLP to Ansible

    At the Ansiblefest 2022 conference today, Red Hat and its parent company IBM announced the Project Wisdom initiative to bring natural language processing (NLP) to the open source Ansible IT operations automation platform.

    At the same time, Red Hat announced that the curated instances of Ansible from Red Hat are now available in the marketplaces operated by Amazon Web Services (AWS) and Microsoft.

    Richard Henshall, senior manager of Ansible product management at Red Hat, said the goal is to make IT automation much more accessible to a broader range of end users and IT professionals that lack the declarative programming expertise to use YAML files to automate IT processes. Instead, Red Hat and IBM Research teams are pledging to combine their expertise to create an artificial intelligence (AI) model that would enable anyone to use natural language to automate an IT process.

    Ansible has emerged as the de facto open source standard for automating a wide range of IT processes, but the number of processes that could be automated still far exceeds the number of IT processes that are currently automated. In recent years, IT automation tools have become more accessible thanks in part to the rise of low-code and no-code tools, but some level of programming expertise is still required. Project Wisdom is being launched to eliminate the need to acquire those skills before being able to automate a process.

    Of course, there will still be complex processes that may require the ability to programmatically manipulate YAML files, but the number of trivial IT processes that could be automated is still incalculable. In theory, a natural language interface for Ansible would greatly reduce the time and effort required for anyone to automate an IT process regardless of their skill level.

    Interest in IT automation is rising once again as the global economy continues to soften. Organizations are looking to automate as many processes as possible in their efforts to keep IT staff size as small as possible. The more time IT teams spend on manual processes the less they will be able to manage IT environments that get more complex with each passing day.

    It’s not clear to what degree IT processes can be automated, but as businesses become more dependent on IT, the line between IT automation and business processes continues to blur. Natural language processing capabilities could make it simpler for organizations to greatly accelerate digital business transformation initiatives.

    Regardless of the level of IT automation achieved, it’s clear the way IT is managed is about to evolve once again. The days when IT teams configured and provisioned IT resources using fragile custom scripts are coming to an end as platforms like Ansible are more widely adopted. The only issue that remains to be seen is how quickly IT processes can be automated and whether the rate of automation can keep up with the volume of applications currently being developed.

  • New Relic Reports Major Spike in Volume of Log Data

    New Relic Reports Major Spike in Volume of Log Data

    New Relic today shared a report based on anonymized data it collects that showed a 35% increase in the volume of logging data collected by its observability platform.

    The report also identified logs generated by NGINX proxy software (38%) as being the most common type of log, followed by Syslog (25%) and Amazon Load Balancer (20%).

    In addition, Fluent Bit is the most commonly used open source processor and forwarder tool (38%) among IT teams that have adopted the New Relic platform. Another 16% are using New Relic infrastructure agent, followed by 14% that send log data directly to New Relic via an HTTP endpoint.

    The report also found 50% of all logs ingested by language agents come from Java applications, followed by .Net (26%), Ruby (22%) and Node.js (2%).

    Jemiah Sius, director of developer relations at New Relic, said as more cloud-native applications are deployed, the volume of log data that is collected is only going to increase as open source OpenTelemetry tools are more widely adopted. In addition, IT teams will also be collecting metrics, traces and events to better pinpoint the root cause of issues using observability platforms such as New Relic One, he added.

    Amazon Web Services (AWS) is now, of course, one of the biggest sources of log data. The New Relic report noted that the serverless AWS Lambda service is the most widely employed source of log data among AWS customers that employ the New Relic One platform. However, use of the AWS Firehose service for extracting, transforming and loading (ETL) data has grown sharply in the last year, noted Sius.

    The New Relic report found while only 32% of New Relic accounts that use AWS have adopted Firehose, there has been a 62% increase in adoption year-over-year.

    Log data is usually the first thing any IT team consults whenever there is an issue, but as the volume of log data increases it’s becoming more difficult to associate log data with specific IT events. The issue that each IT team will have to come to terms with is how much log data to store alongside metrics, traces and other data formats to help them proactively identify the root cause of an IT issue.

    Observability platforms, in the meantime, promise to make it possible to query that log data to identify relationships between events. The goal is to enable IT teams to investigate issues before they can disrupt IT services rather than merely reacting to events after they have unfolded, said Sius.

    The hope, of course, is that machine learning algorithms will soon automatically identify issues before most IT teams even know there is a problem. Given the overall complexity of modern IT environments, it’s unlikely most IT teams even know what queries to launch to identify the root cause of an issue. Instead, as machine learning algorithms become more familiar with what constitutes normal IT events, it will become simpler for those algorithms to surface the issues that are actually worth IT’s attention.

  • Oracle Enables Partners to Reuse Cloud Platform

    Oracle Enables Partners to Reuse Cloud Platform

    At its CloudWorld event, Oracle today announced it will enable IT teams to deploy the same platform it uses to independently deliver cloud services anywhere they see fit.

    Leo Leung, vice president of products and strategy for Oracle, said an Oracle Alloy offering will enable organizations to provide a full set of cloud services they can extend and brand as their own. All of the more than 100 infrastructure and platform services that the company makes available on Oracle Cloud can now be deployed anywhere, he said.

    In addition, Oracle unfurled a MySQL HeatWave service through which IT teams can access instances of the open source MySQL database running on the Amazon Web Services (AWS) cloud. A similar offering for the Microsoft Azure cloud is also planned.

    As part of an ongoing effort to gain share against rival cloud service providers, Oracle has been making a wide range of services available at a lower cost. Oracle Alloy now extends those efforts by making it possible for a wide range of organizations, including traditional enterprise IT organizations and internet service providers, to benefit from the company’s research and development efforts.

    Organizations that ally with Oracle can set their own pricing, rate cards, account types and discount schedules and define the support structure and service levels. A preconfigured instance of Oracle Fusion Financials to enable Oracle Alloy partners to manage customer invoicing and billing is also provided.

    It’s not clear to what degree these organizations might want to compete with cloud service providers such as Amazon Web Services (AWS), Microsoft and Google, but Oracle Alloy does provide an alternative approach to cloud computing that enables organizations to retain more control over the IT services they provide to others. The challenge, of course, is that acquiring the infrastructure is only one part of the equation. Organizations will also need to hire and retain IT specialists needed to manage cloud platforms on an ongoing basis.

    As the volume of applications being deployed in cloud computing environments steadily increases, Oracle clearly views Oracle Alloy as an opportunity to make up for lost ground in a market segment that it initially all but ignored when cloud computing first emerged more than a decade ago. Now, Oracle provides cloud services in 40 commercial and government regions across 22 countries. It has added 10 public cloud regions over the past year and has plans to add six additional commercial regions.

    Oracle is betting that, in some cases, partners will opt to deploy some cloud services themselves while relying on Oracle for others depending on the level of demand for specific classes of services. In effect, Oracle is enabling a set of federated cloud services to emerge that are no longer specifically tied to a single provider. It remains to be seen how receptive organizations will be to that approach, but it’s certain that the number of organizations that could afford to deliver cloud services could substantially increase. In theory, at least, increased competition should also lead to lower cloud costs for the organizations that consume those services.

  • JFrog Adds Module to Better Secure Software Supply Chains

    JFrog Adds Module to Better Secure Software Supply Chains

    JFrog today added a JFrog Advanced Security module to its Artifactory repository that enables DevOps teams to scan both binaries and source code for vulnerabilities and misconfigurations.

    Stephen Chin, vice president of developer relations for JFrog, said that approach will enable DevOps team to ensure applications are secure before they are deployed in a production environment.

    In addition to discovering vulnerabilities, the JFrog Advanced Security module also detects exposed secrets such as passwords, access tokens and private keys, said Chin. Leveraging existing scanning capabilities provided via the JFrog Xray software composition analysis tool, it can also be used to inspect the file used to provision infrastructure-as-code, he added.

    Most importantly, it provides development teams with the context needed to determine which components of an application are using containers that encapsulate code that is actually exploitable, noted Chin.

    One of the major issues DevOps teams encounter today is that they are often presented with a long list of vulnerabilities by cybersecurity teams—many of which don’t meaningfully impact applications that are not exposed to the Internet. DevOps teams then need to manually report why any given vulnerability doesn’t need to be remediated. The JFrog Advanced Security module helps automate that process, said Chin.

    In general, JFrog continues to pursue a binary-first approach to securing software supply chains, said Chin. While it’s important to address vulnerabilities in source code whenever possible, it is application binaries running in a production environment that cybercriminals are going to exploit, he noted.

    Cybercriminals have, in effect, opened a new front in their efforts to compromise IT environments by injecting malware into software components before they are deployed in a production environment. The hope is that, once deployed in those environments, malware can be activated at some later date. As a result, DevOps teams are now being required to improve cybersecurity hygiene across their software development processes, said Chin.

    It’s not clear at what rate organizations are embracing DevSecOps best practices to achieve that goal, but in the wake of an executive order issued by the Biden administration that requires federal agencies to better secure their software supply chains, the expectation is that more enterprise IT organizations will follow suit. The challenge is finding a way to build and deploy more secure applications without negatively impacting the rate at which they are built and deployed. Earlier this year, JFrog launched the open source Pyrsia project that employs blockchain technology to ensure open source software packages are not compromised by vulnerabilities and malicious code.

    In the longer term, it’s only a matter of time before the historic divide that has existed between DevOps teams and cybersecurity professionals starts to narrow as applications become more secure. The biggest immediate challenge is that many of the applications deployed in production environments already have known vulnerabilities. In the months ahead, many DevOps teams will be asked to assess the severity of those vulnerabilities as part of ongoing efforts to improve application security. Those patching efforts will undoubtedly have a significant impact on the amount of time available to write the code needed to build new applications or update existing ones with new capabilities.

    One way or another, however, the amount of technical security debt that has been allowed to build over the last several decades needs to be addressed.