devopsy.kinsta.cloud

Category: News

  • Fastly Adds Observability Tools for Edge Computing Environments

    Fastly Adds Observability Tools for Edge Computing Environments

    Fastly, Inc. this week added a set of observability tools to its portfolio that are optimized for edge computing platforms connected to its content delivery network (CDN).

    Laura Thomson, senior vice president of engineering at Fastly, said the company is now providing a set of tools that enable DevOps teams to capture logging data and metrics in real-time via a single console.

    The first two available tools are Origin Inspector—to observe network traffic flows including HTTPS response codes—and Domain Inspector—to access metrics based on both historical and real-time data. In total, Fastly is now providing access to more than 200 metrics spanning client, origin, cache, web application firewall (WAF), Compute@Edge, Image Optimization services and others that cover 100% of the data generated since the service was spun up.

    There is no sampling of data, and the company is also providing integrations with 33 storage and analysis services provided by either Fastly or a third party, noted Thomson. IT teams can now log any aspect of HTTP requests and responses through a large variety of logging formats, including the Common Log Format, JSON or as a key/value store. IT teams can also store their own logs to make sure they retain complete control over access.

    Over the next several months, Fastly will continue to expand this portfolio of observability tools, including an Edge Observer dashboard it is providing to customers that are deploying applications at the edge, added Thomson.

    In general, observability tools are being used to not only improve processes and overall customer experience but also identify and block suspicious activity. Fastly is making a case for observability tools that enable DevOps teams to achieve those goals without necessarily having to deploy a separate observability platform.

    Of course, most DevOps teams have been continuously tracking various pre-defined metrics for years. Observability tools, in contrast, are designed to make it feasible to interrogate logs, metrics and traces so that IT teams can discover issues before there is a disruption to services. The challenge, of course, is that not every IT team necessarily knows how to shape the queries required to discover the root cause of a potential issue.

    One way or another, DevOps teams will need to be able to remotely diagnose edge computing issues as the number of workloads deployed on these platforms expands. IT teams are not going to be able to travel to the physical location of every edge computing platform every time an issue arises. In many ways, the rise of edge computing will force a transition to observability tools that will enable IT teams to more proactively manage IT environments rather than respond after a metric has already exceeded its threshold.

    It’s not clear to what degree that approach will prevent IT issues from occurring, but the amount of time required to detect and remediate issues should dramatically decline as more visibility into IT environments, including edge computing platforms, is gained.

  • Rust Momentum Intensifies | Elon Says No WFH

    Rust Momentum Intensifies | Elon Says No WFH

    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: People won’t shut up about Rustlang, and Musk mandates Twitter teams return to the office. (more…)

  • GitHub Previews Free CI/CD Migration Tool Due in 2023

    GitHub Previews Free CI/CD Migration Tool Due in 2023

    At its GitHub Universe event, GitHub today unveiled a bevy of updates to its cloud service, including a forthcoming set of migration tools. The tools will automate migrations from legacy continuous integration/continuous delivery (CI/CD) platform to GitHub Actions.

    GitHub Actions Importer is already being used by a small group of enterprise IT organizations to migrate workflows and template the GitHub CI/CD platform.

    Damian Brady, senior manager for developer advocacy at GitHub, told conference attendees that these free tools will become more broadly available in 2023. GitHub Actions Importer will be distributed as a Docker container that manifests itself as an extension of the GitHub command line interface (CLI).

    One of the biggest challenges the company has faced in driving adoption of its platforms is that many DevOps teams don’t want to rebuild the templates and workflows they are already using on their existing CI/CD platform, he noted.

    Other GitHub Actions extensions include native integration with software development tools for building internet-of-things (IoT) applications and support for personal access tokens (PATs) that enable more granular control over permissions and repository access.

    Other security capabilities include expanded access to audit log events in the enterprise edition of GitHub, an ability for maintainers of open source repositories to privately share vulnerability reports and support for Ruby as one of the programming languages now supported by a CodeQL tool for discovering vulnerabilities.

    Additional extensions to existing services for developers also were previewed, including an ability to interact with the GitHub Copilot tool for automating code writing using voice commands. Dubbed “Hey, GitHub!” the tool is available as an experiment being advanced by the GitHub Next research team.

    Finally, the company previewed enhancements to code search-and-view capabilities in the Codespaces tool that will now be made available for free for up to 60 hours per month to developers.

    GitHub claims its CI/CD platform is now being used to process 10 million builds a day, most of which are employing code accessed via its repository. It’s not clear how that compares to other CI/CD platforms, but it’s apparent the GitHub Actions CI/CD platform has gained a significant amount of traction as GitHub continues to make a case for creating tighter integrations between its repository and CI/CD platform. GitHub is also clearly signaling it will spend a lot more time wooing organizations that already have a legacy CI/CD platform installed.

    In the meantime, the next era of DevOps has arrived as workloads become both more complex to build and deploy across highly distributed computing environments. Many of the CI/CD platforms that organizations deployed are now straining under the weight of multiple customizations and extensions that have been made over the years. Each DevOps teams will need to decide whether maintaining those platforms makes the most technical and economic sense or if they should migrate to a more modern platform.

    Regardless of what they decide, one thing that is certain is that DevOps teams won’t be getting larger, so the need to invest in higher levels of automation has become pressing.

  • CloudBees Demos Orchestration Capabilities of ReleaseIQ Platform

    CloudBees Demos Orchestration Capabilities of ReleaseIQ Platform

    At the online DevOps World 2022 event today, CloudBees demonstrated for the first time the capabilities of the application release management platform it gained last month through the acquisition of ReleaseIQ.

    Shawn Ahmed, chief marketing officer and interim chief product officer at CloudBees, told conference attendees that the ReleaseIQ platform will provide application development teams with visibility into precisely how their code is making it into production environments.

    Armed with those insights, it then becomes possible to understand exactly how the way commits are made during a build process are, for example, creating a workflow bottleneck, he added.

    The ReleaseIQ platform is designed to enable DevOps teams to both create and maintain pipelines using a no-code tool. That enables greater transparency into workflows via dashboards that also provide optimization recommendations.

    CloudBees already provides a Flow orchestration engine within its continuous delivery platform. However, ReleaseIQ provides a similar capability across multiple continuous integration/continuous delivery (CI/CD) platforms using a SaaS platform that is more accessible. ReleaseIQ can also be integrated with multiple platforms including CloudBees CI, Jenkins, CircleCI, GitLab, Bamboo, ArgoCD and others.

    Naturally, the current level of DevOps maturity varies widely by organization. However, as more organizations realize how much they depend on software to drive digital business transformation processes, the need to further automate application development and delivery becomes more apparent. While CI is widely used today, the number of organizations that have consistently implemented CD to automate application release management is still fairly limited. The underlying infrastructure that software is deployed on typically has a unique set of application programming interfaces (APIs) that each CD platform needs to support. Platforms such as ReleaseIQ provide a higher level of abstraction that simplifies managing the pipelines that deliver software.

    CloudBees is essentially positioning ReleaseIQ as the orchestration engine for both unifying pipeline management and, ultimately, enabling value stream management across increasingly complex application development environments. It may take a while to fully realize that ambition, but with the acquisition of ReleaseIQ, the company is now pursuing a more cloud-centric approach toward enabling DevOps teams to, for example, more easily reuse pipelines.

    DevOps teams, of course, have created a lot of scripts over the years to provide orchestration capabilities. The issue is that those scripts tend to be brittle in the sense they don’t scale especially well over time. They also tend to be poorly documented and challenging to maintain if the script writer leaves the organization. It’s not uncommon for new members of a DevOps team to replace a script with one they wrote simply because they’re more familiar with how it’s constructed.

    More than a decade after the launch of the Jenkins CI/CD platform, there are still plenty of manual DevOps processes that should be more automated. A no-code orchestration platform may prove to be a significant step toward automating a wide range of tasks that consume more time than they should.

  • Cribl Simplifies Telemetry Data Analytics

    Cribl Simplifies Telemetry Data Analytics

    Cribl today announced general availability of a search capability that makes it simpler to query observability data where it resides without having to first collect and centrally store it.

    Nick Heudecker, senior director for market strategy for Cribl, said Cribl Search makes it possible to analyze telemetry data at its point of origin or when it is stored in a low-cost object storage platform to minimize costs.

    As the volume of telemetry data being collected continues to grow, DevOps teams are struggling with ingesting it all. Cribl takes advantage of a platform it created to stream and normalize the collection of telemetry data. Cribl Search adds the ability to also query that data at the endpoint where it resides, said Heudecker.

    While observability has always been a core tenet of DevOps, achieving it has been a major challenge. In addition to deploying and managing agent software to instrument IT environments, there’s a significant amount of time and effort required to set up the pipelines necessary to transfer data to a platform for storage and analysis. The more data is collected, the greater storage costs become. Cribl is making a case for automating those tasks using a tier of software that abstracts data into a format that can be more easily collected and analyzed.

    In general, observability is emerging as the next logical evolution of continuous monitoring. Existing monitoring tools enable DevOps teams to track specific pre-defined metrics. Observability platforms are intended to make it easier to query telemetry data to discover the root cause of an issue that is not being tracked by a set of pre-defined metrics.

    It’s not clear yet whether IT organizations perceive observability to be an evolution of monitoring or a distinctly separate but complementary capability, but it’s apparent IT teams need a lot more context than they have historically been able to attain using legacy monitoring tools. Each platform used within an enterprise typically comes with its own monitoring tools that are used by the IT teams tasked with managing it. Whenever there is an issue, it’s not uncommon for DevOps teams to spend hours correlating data from multiple tools to ascertain the root cause of a problem. Observability platforms promise to reduce that time and effort by applying analytics to data collected from multiple platforms. The challenge is finding a way to efficiently collect all that data, which in the past has often required a data engineer to build a pipeline spanning multiple sources of telemetry data.

    One way or another, observability platforms should make it easier for DevOps teams to manage IT issues more proactively. The goal, as always, is to identify issues before they cause a major disruption. In that sense, it may be difficult to prove the ROI of deploying an observability platform. However, the best IT incident is always going to be the one that never happened or, at the very least, never escalated to a level of noticeable disruption.

  • VMware Extends Equinix Alliance to Drive Managed Hosting Service

    VMware Extends Equinix Alliance to Drive Managed Hosting Service

    VMware today announced it has extended its alliance with Equinix to launch a managed distributed cloud service that runs instances of its cloud computing platform in hosted IT environments.

    Announced at the VMware Explore 2022 Europe conference, the VMware Cloud on Equinix Metal service takes advantage of more than 240 Equinix data centers in 71 major metro areas around the world to deploy instances of the VMware Cloud platform running atop the company’s virtual machine software.

    Narayan Bharadwaj, vice president of cloud solutions at VMware, said this VMware service extends the scope and reach of the company’s multi-cloud computing strategy beyond the scope of the major hyperscalers and traditional on-premises IT environments.

    The goal is to provide a managed IT environment that provides an alternative for deploying latency-sensitive applications closer to the network edge where data can be processed and analyzed in near-real-time, he noted. In addition, Equinix’s hosted IT environment also makes it possible for IT teams to more easily comply with requirements in highly regulated industries.

    It’s not clear what percentage of applications today are running in managed hosted environments versus a public cloud or local data center. But as more organizations decide not to operate data centers themselves, many of them are discovering managed hosting services are preferable to the cloud for reasons spanning everything from application performance and cost and security to compliance.

    In some cases, organizations are determining that certain classes of longer-running applications initially deployed in the cloud are actually less expensive to run in an on-premises IT environment, noted Bharadwaj. A managed hosting option often provides the flexibility benefits of the cloud at a lower cost for those applications, he added.

    As cloud computing evolves, it’s become apparent that IT is becoming more distributed than ever. Many organizations are finding they now have a mix of applications running on public clouds, in co-location facilities and traditional on-premises IT environments. The challenge is that with each new platform employed to run applications, the total cost of managing IT increases. Regardless of any potential infrastructure cost savings, each platform typically requires a set of dedicated specialists to master the frameworks need to manage it. In fact, the single biggest IT expense remains the cost of labor. VMware is making a case for a familiar IT framework that can be deployed anywhere to rein in those costs.

    DevOps, of course, was created to provide a new approach to automating the management of IT at scale. However, DevOps continues to be employed unevenly, largely because there are not enough IT professionals with the programming skills required to successfully manage IT-as-code. Managed services are gaining traction because, in most cases, they shift the responsibility for managing DevOps workflows onto a vendor such as VMware.

    It remains to be seen just how automated the management of IT will become in the months and years ahead. However, it’s apparent that, in the era of the cloud, more organizations are opting to rely on third parties to manage infrastructure so they can devote more resources to building and deploying applications.

  • OutSystems Acquires Ionic to Further Automate App Development

    OutSystems Acquires Ionic to Further Automate App Development

    OutSystems this week revealed it has acquired Ionic, a provider of an open source framework that provides developers with a higher level of abstraction for building and deploying mobile and desktop applications.

    OutSystems CTO Patrick Jean said Ionic will accelerate the company’s ongoing efforts to extend the reach of its platform for building low-code applications without developers having to worry about, for example, the screen size of the device an application is deployed on it because the framework automatically right-sizes it. Ionic, in effect, will provide an extension to the platform that OutSystems already uses to automate the building and deployment of low-code applications, he added.

    In addition to its namesake user interface (UI) framework for building mobile applications that can run on multiple platforms, the Ionic portfolio also includes a tool for natively deploying web applications, dubbed Capacitor, and a toolchain for building web component-based design systems, dubbed Stencil. Collectively, these tools are used today by more than five million developers.
    OutSystems plans to extend the capabilities of these tools to make it simpler to deploy applications on both mobile devices and desktop systems, said Jean. The overall goal is to reduce the cognitive load that developers currently carry when they need to build and deploy applications that run on multiple platforms, he added.

    That capability will prove critical as more individuals beyond professional developers become involved in building, deploying and updating applications, noted Jean. In fact, many of those developers are likely to be business people that only develop applications on a part-time basis, he added.

    The percentage of applications being built using low-code tools has increased dramatically. Professional developers have embraced these tools and platforms alongside so-called citizen developers that are using them to build applications, as well. As the backlog of applications that needs to be built steadily increases, low-code platforms have played a crucial role in enabling developers to keep pace with the demand for new applications.

    Less clear is the impact these low-code applications are having on DevOps workflows. On one hand, there are clearly more applications that need to be deployed than ever. At the same time, many of the DevOps and data modeling processes that once required, for example, a dedicated continuous integration/continuous delivery (CI/CD) platform are being embedded in the platforms provided by the vendors that create low-code tools.

    Regardless of how low-code applications are deployed, the one thing that is certain is the pace of digital business transformation is being greatly accelerated by these tools and platforms. DevOps teams will soon need to put guardrails in place that enable developers with a wide range of experience and skillsets to securely deploy and update applications.

    On the plus side, DevOps teams should also expect it to become easier to automate the delivery of low-code applications at levels of unprecedented scale. In fact, the issue going forward may not be whether IT can keep up with the needs of the business but whether the business can keep pace with the rate of innovation now being enabled.

  • SRE Survey Reveals Major Technical and Cultural Challenges

    SRE Survey Reveals Major Technical and Cultural Challenges

    Catchpoint, in partnership with Blameless, today published an annual survey of 559 site reliability engineers (SREs) that found 59% of respondents didn’t view tool sprawl to be a major concern. Another 40% said tool sprawl is a moderate (33%) to serious problem (8%).

    More than half of respondents said they build as much as 30% of the tools they use themselves, with more than half (54%) noting their organization tracks three or more different types of telemetry data to drive observability. The top three types of telemetry data collected are infrastructure (62%), application (58%) and network monitoring (55%) and, on average, the survey suggested the median toil level of SREs dropped 5% year-over-year.

    Just under half of respondents (46%) also noted they saw no or low value from artificial intelligence for IT operations (AIOps) compared to 30% that have seen moderate to high value. Another 25% are still unsure.

    Finally, the survey concluded that organizations that have adopted a “just culture”—where organizations ensure that incident reporting is not met with punitive measures—are 500% more likely to be Elite performers in terms of the DevOps Research and Assessment (DORA) metrics defined by Google.

    Leo Vasilou, director of product marketing for Catchpoint, said that the survey results provided some insights into the challenges SREs face as they strike a balance between trying to achieve DevOps goals and the fact that hiring has become more constrained during an economic downturn.

    That stress, however, has less to do with managing toolchains than it does ensuring that applications driving critical business processes are consistently available, he noted.

    SREs have emerged as a distinct DevOps function in recent years, focused almost exclusively on programmatically managing the dependencies that exist between a wide range of applications and the underlying infrastructure upon which they depend. Optimizing applications in the cloud-native era has become more challenging because the number of dependencies that exist between the microservices that make up a modern distributed computing environment continues to exponentially increase. In many cases, applications are continually added to IT environments without a commensurate increase in the overall size of the SRE team.

    Regardless of the economic climate, hiring and retaining SREs remains a challenge given the demand for IT professionals with those skills. Of course, there is no formal SRE certificate that is widely recognized so who qualifies to be an SRE tends to vary from one organization to the next. The one thing that is generally agreed upon is that SRE automate a wide range of tasks that would otherwise require multiple IT administrators to perform. Glassdoor also reports that, on average, an SRE makes north of about $125,000, which ranks among the highest salary level within any IT organization.

    Each organization, depending on their geographic region, would need to determine how many IT administrators they could replace if they hired an SRE. That doesn’t mean IT administrators that rely on a wide range of graphical tools to manage IT tasks are going away any time soon, but as DevOps continues to evolve, the dynamics between SRE and IT administrators also will continue to evolve.

  • Snowflake Makes Case for Building and Deploying Apps on Platform

    Snowflake Makes Case for Building and Deploying Apps on Platform

    During a Snowday 2022 event, Snowflake this week moved to make it simpler to build applications on top of its cloud platform for managing data in addition to enhancing the overall security of the platform.

    The company has made generally available Snowpark, a framework for building Java, Scala, SQL or Python applications. Snowflake also committed to making generally available in early 2023 an open source Streamlit framework for building Python applications that Snowflake acquired earlier this year.

    Snowflake also revealed it is adding observability tools to the platform to make it easier to build, test, debug, deploy and monitor data pipelines, including alerting tools (private preview), logging capabilities (private preview), event tracing (private preview), task graphs and history (public preview).

    Torsten Grabs, director of product management for Snowflake, said those capabilities will make it easier to alert DevOps teams to issues that might arise with applications deployed on the Snowflake platform.

    At the same time, Snowflake is also making it simpler to build data pipelines by making a Serverless Tasks capability generally available. In addition, the company is previewing a Schema Inference engine that makes it simpler to ingest data and a Dynamic Tables capability to declaratively manage data pipelines.

    Other capabilities being added to the platform include a public preview of a Query Acceleration Service to make additional compute resources available on demand. Snowflake has also improved query efficiency with join elimination in addition to providing search optimizations.

    There are also now cost optimization tools that enable IT teams to run a cost-benefit analysis of Snowflake services in addition to tools that make it easier to replicate data across multiple cloud computing environments running the Snowflake platform.

    IT teams can now also replicate Streams and Tasks via a capability in public preview that enables data pipelines to seamlessly work on secondary Snowflake accounts and configure failovers using a graphical tool that is available in private beta.

    Finally, Snowflake has also enhanced its cross-cloud Snowgrid Capability to make it easier to share both public and private listings of data in addition to applying tags to and searching masked data.

    The latest editions to the Snowflake platform come at a time when more organizations are starting to adopt DataOps best practices to manage data. Snowflake is now making a case for building and deploying applications on top of a platform that automates the management of the data pipelines used by applications to access data.

    It’s not clear to what degree the Snowflake platform will be employed to host applications, but the company is clearly betting the volume of data residing in its cloud platform will attract a wide range of application developers that, in turn, will need to be supported by DevOps teams.

    Of course, Snowflake is not the only provider of a data warehouse or data lake that has similar ambitions. Regardless of platform, however, the one thing that is clear is that a convergence of DevOps and DataOps workflows is now underway as IT organizations look to streamline the management of the massive amounts of data that now reside in the cloud.

  • Cisco Adds Open Source Tool to Validate Serverless Functions

    Cisco Adds Open Source Tool to Validate Serverless Functions

    Cisco has launched an open source project, dubbed FunctionClarity, that makes it possible to verify signatures before code is deployed in a serverless computing environment.

    Vijoy Pandey, vice president of emerging technologies and incubation at Cisco, said that one of the application security issues that has emerged in serverless computing environments is the lack of validation capability to verify code signatures prior to deployment. As more organizations employ serverless computing frameworks, the overall software supply chain becomes less secure, he noted.

    FunctionClarity includes a command line interface (CLI) tool to invoke a verification function that can be deployed on the Amazon Lambda serverless platform to address that issue; support for Microsoft Azure and Google Cloud serverless platforms is planned, he added.

    The FunctionClarity project aims to close that gap by employing either a keyless approach using open source sigstore tools or a traditional encryption key, noted Pandey.

    The FunctionClarity project is the latest extension of a Cisco OpenClarity initiative that includes an existing project for securing application programming interfaces (APIs) using a service mesh, dubbed APIClarity, and a tool for detecting and managing software bills of materials (SBOMs) and vulnerabilities in container images and filesystems dubbed KubeClarity. All three projects are part of an ongoing Cisco effort to contribute code to the open source community that, while essential, does not provide a lot of differentiated value for any one vendor, said Pandey.

    The FunctionClarity project arrives at a time when concerns over the security of software supply chains is on the rise. Many of the software security issues that organizations are encountering stem from the simple fact that developers can provision cloud infrastructure without any kind of meaningful cybersecurity review. Code signing, within the context of a larger set of DevSecOps workflows, is now starting to gain traction to better ensure secure software supply chains. The challenge is that as more code winds up running on serverless computing platforms, a need to extend the reach of whatever approach to code signing an organization adopts becomes more evident.

    In general, the open source community is collectively trying to respond to an executive order issued by the Biden administration that required federal agencies to implement a series of steps to better secure their software supply chains. One of those measures includes wider adoption of code signatures to ensure the authenticity of code being incorporated into applications. The challenge is that incorporating code signatures into DevOps workflows has historically not been a trivial process to implement. Most recently, a free sigstore cloud service launched that promised to make it easier to achieve that goal.

    It’s not clear how widely or even how rapidly code signing will be adopted, but enterprise IT organizations are paying close attention to how federal agencies are responding to the executive order. Many of the tools and processes defined by those agencies will inevitably be copied by enterprise IT organizations that have thus far made limited use of code signing to verify the authenticity of software components. The challenge now is finding a way to achieve that goal without slowing down the rate at which modern software is developed.