devopsy.kinsta.cloud

Category: Infrastructure/Networking

  • Leveraging eBPF for DevSecOps

    Leveraging eBPF for DevSecOps

    eBPF is a revolutionary technology originating from the Linux kernel. It is used to safely and efficiently extend the kernel’s capabilities without requiring changing the kernel source code or loading kernel modules/extensions.

    Today, eBPF is used extensively to:

    • Provide high-performance networking and security in modern data centers and cloud-native environments
    • Extract fine-grained security observability data at low overhead
    • Provide insights for performance troubleshooting
    • Provide preventive application and container runtime security enforcement

    eBPF-Enriched Context

    eBPF is the base data layer that is needed in runtime cloud security. eBPF gives you information at a high level on Layers 3, 4 and 7, allowing you to see all network communication and correlate it with processes and specific applications that are communicating on those ports.

    To fully leverage eBPF, you need to pair this raw data with additional cloud infrastructure context to gain a full understanding of which resources and services are in use.

    For example, by leveraging eBPF, you can determine if you have 10 different applications all communicating on port 443, whereas a traditional network monitoring tool would tell you that you have a certain amount of traffic on this port but wouldn’t be able to segment this traffic and show how much of that traffic is coming from each individual application.

    Knowing which communication is coming from an individual application increases visibility. It allows you to see what your applications are doing in real-time and identify signs of compromise or decreased performance.

    Increasing Observability With eBPF

    eBPF provides users with intrinsic, comprehensive insight into communication flows across the entire system. The applications for enhancing security observability with eBPF are vast, ranging from enabling highly detailed process visibility to facilitating end-to-end observation of processes and flows.

    When dealing with Layer 4 to Layer 7 traffic involving multiple protocols, eBPF emerges as an optimal solution. Through eBPF, TLS traffic traversing pods, nodes and cloud platforms can now be uniformly instrumented across layers.

    In other words, with eBPF, you can observe your application and your node and gain a vast amount of raw data, which, with the right tools, you can correlate to understand your entire network topology.

    Beyond eBPF Raw Data to Context and Correlation: Layer 7 and Beyond

    Specifically for observability, you can use eBPF to apply filters directly in the kernel, which reduces the overhead and allows you to ingest significantly more raw data. eBPF’s architecture allows you to do all of this, observe network traffic and Layers 3, 4 and 7 without compromising your security or performance.

    With eBPF, you are able to understand the execution events, system call events and all of the network ingress and egress. But it’s not always enough.

    You will need to correlate it with Cloud APIs, Kubernetes identities, pods and namespaces to understand the actual identities and relationships between the individual workloads, all the way down to the application layer. By doing so, you are able to understand application-level identity and use this context to understand your application behavior as well as your most critical risks and threats.

    Leveraging eBPF for Threat Detection and Response

    Security and networking observability are inherently interconnected. eBPF helps you to gain insights such as abrupt shifts in behaviors, spikes in activity within specific processes indicating potential exploitation or attacks, service-to-service communication trends and more. These projects enable users to examine network transactions, identifying the pods, processes and system calls involved.

    With eBPF, you can see OS-level runtime threats. eBPF gives you the ability to listen to system calls but also to go one step further and block or terminate any process, PID (process identifier), system call or network packet. This allows for a more granular approach to automated threat detection and response without damaging your system or hurting your infrastructure.

    You can also use eBPF to implement prevention rules, meaning you can instruct eBPF to automatically block any malicious processes or pre-designated system calls or network packets, going beyond traditional uses of eBPF for monitoring and security, to become a more proactive, preventative tool for securing your infrastructure and applications.

    Real-World Benefits of eBPF

    eBPF presents a number of real-world benefits, going beyond traditional monitoring, observability and security to help with overall alert noise reduction and improved forensic analysis.

    How eBPF Contributes to Noise Reduction

    By itself, eBPF does not reduce noise. In fact, it increases because of the influx of raw data from every system call. However, with the right tools, you can leverage this raw data and correlate it with additional context to understand your infrastructure and application behavior. This effectively reduces the alert noise that you would otherwise receive because you can view more detailed insights into resource behavior.

    By filtering and aggregating this data, you receive more insights about applications, overall giving you less noise because you’re focusing on what actually matters.

    By having this eBPF raw data at runtime, you can apply intelligent filters to filter through the most important data and use it accordingly, resulting in better prioritization, more focused efforts and increased operational efficiency.

    Forensic Analysis

    Another important real-world use case for eBPF is conducting forensic analysis. By leveraging eBPF’s raw runtime data and applying intelligent filters, you can quickly pinpoint problem origins and conduct forensic analysis at the application level.

    By leveraging eBPF’s raw data from Layer 7, you gain a granular understanding of applications and the process-level communication within an application, allowing you to foresee the potential blast radius if an application were compromised in terms of who it could interact with and what damage could occur.

    Conclusion

    In summary, eBPF is a powerful technology that can be effectively leveraged for monitoring, observability and security purposes. However, when eBPF’s raw data is combined with context from cloud APIs, it can be leveraged even further with intelligent filters to provide unparalleled cloud infrastructure and application context, allowing you to understand application-layer identity, provide real-time security, pinpoint problem origins and stop threats with surgical, active response.

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.

  • Permiso Makes Open Source Tool to Identify Cloud Threats Available

    Permiso Makes Open Source Tool to Identify Cloud Threats Available

    Permiso today launched an open source tool dubbed CloudGrappler that surfaces indicators of compromise in cloud computing environments.

    Based on a cloudgrep project originally created by Cado Security, CloudGrappler detect patterns that Permiso, a provider of an identity threat detection and response platform, associated with tactics and techniques commonly used by various cybercriminal syndicates.

    The tool enables DevSecOps teams to define the data sources they want to scope in a scan of an Amazon Web Services (AWS) or Microsoft Azure cloud. Via a JSON file, DevSecOps teams can access a list of predefined tactics, techniques and procedures (TTPs) that are commonly used to exploit cloud computing environments. DevSecOps teams can also dynamically add queries or a file with multiple queries to scan a specific data set. After scanning, CloudGrappler delivers a JSON report that provides a breakdown of the scan results.

    Ian Ahl, senior vice president for P0 Labs, the research arm of Permiso, said that capability makes it possible for DevSecOps teams to identify issues in cloud computing environments that warrant further investigation before there is a major incident. The primary goal is to make it simpler for DevSecOps teams to determine if they need additional assistance to thwart a potential threat, he added.

    Cybercriminals are, like almost everyone else, creatures of habit and often tend to leverage the same TTPs multiple times simply because they know they’re effective. However, those TTPs also provide clues to their presence in an IT environment. Once discovered, a DevSecOps team can decide if they can remediate the issue themselves or need to tap external cloud security expertise, noted Ahl.

    In general, cloud computing environments may be more secure than most on-premises IT environments. However, the processes used to provision cloud computing environments are often flawed because developers typically don’t have much cybersecurity expertise. Misconfigurations are often rife across cloud computing environments.

    Cybercriminals are also especially adept at stealing credentials to gain initial access to cloud computing environments, which they leverage to escalate privileges in a way that provides them unfettered access to the entire cloud computing environment.

    Adoption of DevSecOps best practices has improved cloud security, but there are still plenty of instances where, for example, a port inadvertently left open has enabled cybercriminals to infest a cloud computing environment with malware that could lie dormant within cloud applications for months before finally being activated.

    There are simply not enough cybersecurity experts available to secure cloud computing environments, so it’s going to be largely up to DevOps teams to secure them. The issue is that in the race to build and deploy applications as quickly as possible, cloud security best practices are either forgotten or simply ignored. Of course, it’s that very carelessness that cybercriminals are counting on to allow them to wreak havoc in an era where the percentage of mission-critical applications running in cloud computing environments will only continue to increase exponentially.

  • Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare today launched a Magic Cloud Networking platform that makes it simpler to programmatically manage multiple cloud networking environments using Terraform code.

    Based on a platform the Cloudflare gained when it acquired the core technology from Nefeli Networks late last year, the Magic Cloud Networking platform presents IT teams with a console through which they can use the existing Cloudflare One secure access service edge (SASE) platform to securely manage multiple cloud networks. The Cloudflare global network spans more than 310 cities in over 120 countries and interconnects with more than 13,000 networks worldwide.

    Annika Garbers, director of product for Cloudflare, said this addition to the Cloudflare portfolio promises to make it simpler to integrate network operations (NetOps) with DevOps workflows in a way that makes it simpler to enforce zero-trust IT policies.

    The degree to which NetOps and DevOps are integrated tends to vary widely from one organization to the next. It’s still not uncommon for DevOps teams to be able to provision a virtual machine in seconds or minutes but then be forced to wait days for a NetOps team to provide then network access. Arguably, those kinds of delays defeat the purpose of investing in DevOps in the first place.

    That’s becoming a more problematic issue as organizations start to deploy workloads across multiple clouds, each with its own construct for managing software-defined networking infrastructure. The Magic Cloud Networking platform provides DevOps teams with a higher level of abstraction for programmatically managing those networks using Terraform code that is already widely used to manage infrastructure-as-code, noted Garbers.

    That approach eliminates the need to rely on cumbersome virtual routers that IT teams don’t want to manage. In fact, more IT teams than ever just want to be able to access network services versus having to build, deploy and manage physical routers and switches, said Garbers. In the age of the cloud, the physical network underlay is typically managed by the cloud service provider, so all that’s required is a way to programmatically unify the management of multiple cloud networks that can be invoked via lower-level application programming interfaces (APIs).

    The one thing that is certain is that as networking services become more programmable, the pace at which applications can be deployed is only going to accelerate. Each organization will need to determine which teams are best suited to manage any given layer of the networking stack. Still, regardless of approach it’s clear networks are finally catching up to rest of the IT infrastructure that is already being managed using code. The challenge, as always, is making just as easy for network administrators that lack programming skills to manage those networks as easily as a DevOps team that already has extensive experience using code to manage the rest of the infrastructure used to provide IT services.

    Of course, there will still be plenty of routers and switches to manage in on-premises IT environments but it’s only a matter of time before they become part of a larger DevOps workflow.

  • Survey: Significant Shift in IaC Tool Preferences

    Survey: Significant Shift in IaC Tool Preferences

    A survey of 350 IT professionals conducted by Firefly, a provider of a platform for managing cloud computing environments, suggests usage of infrastructure-as-code (IaC) tools is evolving rapidly in the cloud computing era.

    For example, more than 40% of the respondents reported that, to some degree, they are already using OpenTofu, an open source IaC tool that was launched as a fork of the Terraform IaC in the wake of changes to the software licensing terms it is made available under by HashiCorp. Well over half said they planned to use OpenTofu in the future. That compares to 60% using Terraform today, but only just over 20% said they planned to use Terraform in the future.

    The licensing changes HashiCorp implemented only affect third-party entities within a third-party platform. However, the survey indicates the number of end users affected by that change is more substantial than anticipated. A full 56% of respondents described the changes made to the Terraform license as disruptive.

    The survey also finds there is a lot more diversity in terms of the types of IaC tools being employed, with both the IaC tools from Pulumi and the open source Crossplane framework being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) also gaining traction. The report finds more than 40% of respondents are also using Pulumi, with well more than half planning to use that IaC tool in the future.

    Crossplane, meanwhile, is now being used by 40% of respondents, with 60% planning to adopt it.

    Conversely, the report also notes the number of organizations planning to migrate away from CloudFormation from Amazon Web Services (AWS) is rising. While well over 60% use AWS CloudFormation today, only a third plan to use it in the future.

    Cindy Blake, vice president of marketing for Firefly, said as organizations employ additional cloud platforms, IT teams are clearly looking for tools that make it easier to centralize the management of multiple computing platforms. That trend will only accelerate as more DevOps teams adopt platform engineering as a methodology for managing the building and deployment of applications at scale, she added.

    In fact, noted Blake, it’s already fairly common for IT teams to use two or more frameworks. The report finds 57% of respondents work for organizations that are using two or more frameworks. Overall, the report finds that more than 64% of respondents have also codified more than half of their cloud assets.

    The number of organizations employing IaC tools to programmatically manage infrastructure is only going to increase, said Blake. The report, for example, found that three-quarters of respondents either already are or plan to use IaC tools to configure software-as-a-service (SaaS) application environments. In the longer term, advances in artificial intelligence (AI) will make it simpler for organizations to achieve that goal. Open source tools such as AiAC, for example, already make it possible to leverage large language models (LLMs) to generate code. Those types of tools will eventually eliminate the need to master specific programming languages to provision IT infrastructure as code, noted Blake.

    It’s not clear how IaC tools within the context of DevOps workflow will evolve, but the one thing that is certain is that the number of types of tools being adopted has never been more diverse.

  • Dell Brings DevOps to Edge Computing Environments

    Dell Brings DevOps to Edge Computing Environments

    Dell Technologies today updated its edge computing platform this week to make it simpler to programmatically provision infrastructure using DevOps best practices.

    Phil Burt, senior director of project management for edge computing at Dell Technologies, said version 2.0 of Dell NativeEdge adds additional declarative blueprints based on YAML files and the Topology and Orchestration Specification for Cloud Applications (TOSCA) framework.

    Blueprints for Telit, Litmus and PTC for manufacturing use cases, Deep North for retail, Dell Streaming Data Platform for analytics and Rancher Labs K3s for Kubernetes environments are provided.

    Those blueprints make it simpler to either deploy applications on a lightweight operating system that Dell developed optimized for edge computing platforms or any other software stack an IT organization may prefer, he added.

    Dell is also adding support for the virtual Trusted Platform Module (vTPM) and UEFI Secure Boot capabilities to apply zero-trust IT principles to edge computing platforms using hardware-based cryptography and secure storage for encryption keys, certificates and passwords.

    Finally, Dell is also making available a three-year subscription plan for NativeEdge to lower the total cost of deploying edge computing platforms.

    Dell relies on virtual machines it developed for edge computing platforms to deliver software. IT teams can then opt to deploy monolithic applications or container-based applications running on an instance of Kubernetes deployed as an extension of the virtual machine provided by Dell. Those platforms can then also automatically connect to a network to provide the connectivity required.

    Regardless of approach, Dell is providing a method to programmatically orchestrate the management of highly distributed edge computing environments, noted Burt.

    In the longer term, Dell is also researching how to apply generative artificial intelligence (AI) to the management of edge computing environments using the data its monitoring tools provide, he added.

    While edge computing has been around in one form or another for decades, as more organizations start to process and analyze data at the point where it is created and consumed, the number of applications deployed at the network edge has increased substantially. As such, the number of applications that need to be built and deployed at the edge using DevOps best practices is growing exponentially. In fact, managing those workloads is only going to become that much more challenging as more AI models are deployed at the network edge.

    Of course, not every workload at the edge is managed by an IT team. For years, many organizations have relied on operational technology (OT) teams that have historically deployed applications at the network using manual processes. Organizations that embrace DevOps practices to automate the deployment of workloads at the edge will naturally have to navigate some cultural issues alongside the technical challenges encountered when programmatically deploying software.

    It’s not clear how much software will be running at the network edge in the years ahead, but as the capabilities of the IT infrastructure made available continue to increase, so will the complexity of the applications that will be deployed. The challenge, as always, is going to be finding the best way to manage all that distributed software at what will soon be an unprecedented level of scale.

  • Arm Extends Processor Architecture to Transform IT

    Arm Extends Processor Architecture to Transform IT

    Arm today extended its processor portfolio to add two offerings that increase the performance-per-socket provided by 50% and performance-per-watt provided by 20%, respectively.

    Part of the Arm Neoverse Compute Subsystems (CSS) family of processors, these third generation Neoverse IP processors include an Arm Neoverse CSS V3 design to improve performance and Arm Neoverse CSS N3 design to improve energy consumption. Arm, for example, envisions the first instances of the N3 being used in networking and data processing units (DPUs) that require thermal design power measurement of as low as 40 watts.

    Dermot O’Driscoll, vice president of product solutions for the Infrastructure Line of Business at Arm, said Arm is already working with partners to manufacture these next-generation processors that will find their way onto system-on-chip (SOC) subsystems. Arm assumes responsibility for configuring, optimizing and validating a complete compute subsystem for key use cases on behalf of its partners, he noted.

    As part of that effort, Arm is continuing to work with partners to provide early access to SoCs to enable their software development teams to construct applications using simulation and emulation tools as next-generation platforms are being developed and deployed, he added.

    That approach helps ensure that software that is optimized for these processors is available at the time when SoCs become available, noted O’Driscoll. Variations of those Arm processors now routinely show up everywhere from the network edge to cloud computing environments to provide IT teams with an alternative to x86 processors that, so far, are not able to match the price/performance of Arm processors that are also more energy efficient.

    DevOps teams are under more pressure than ever to improve application performance without increasing the overall carbon footprint of their IT environments. Achieving those goals will require everything from more energy-efficient processors to modernized software that makes optimal use of IT infrastructure resources, especially as more inference engines are deployed to run artificial intelligence (AI) models, noted O’Driscoll.

    The challenge right now is many DevOps teams lack the tools needed to track overall energy consumption within the context of their application environment, but as DevOps continues to evolve, it will only be a matter of time before energy consumption metrics become a standard element of an observability platform being relied on to optimize DevOps workflows.

    In the meantime, as IT infrastructure environments continue to evolve, IT teams should expect to be deploying applications on a wide range of Arm, X86, graphical processor units (GPUs) and other classes of processors designed to optimize specific types of workflows. At the same time, Arm is advancing the development of “chiplets” that are optimized to run specific types of workloads within a larger SoC rather than deploying different platforms to run a specific class of processors.

    It may take a while for IT teams to wrap their arms around all the different processor options that are now at their disposal, but as the number of processor architectures being used continues to expand, the need for DevOps expertise will continue to increase.

  • What the Evolution of Specialized Hardware for AI and ML Means for DevOps

    What the Evolution of Specialized Hardware for AI and ML Means for DevOps

    The widespread adoption of artificial intelligence (AI) and machine learning (ML) technologies is accelerating the evolution of computational hardware, essential for automating complex processes and enhancing accuracy in decision-making. This acceleration is crucial in advancing computer science and data processing, especially within the various segments of AI/ML data pipelines.

    This growing demand is prompting a diverse array of chip manufacturers, from established players to emerging contenders, to innovate and lead in the development of faster and more efficient processing solutions. The primary goal? To design chips that optimize data transfer, improve memory management and enhance power efficiency. These advancements are far from incremental; they are pivotal in meeting the escalating demands of sophisticated AI and ML applications.

    This evolving hardware landscape for DevOps necessitates greater unification and automation of the various applications to the specialized AI infrastructure. With chip architectures diversifying, building the application stacks focusing on portability, performance and ease of access becomes even more crucial. The ability to seamlessly embrace multiple architectures will be key to striking the right balance for the varying technical abilities of the people who want to interact with technology.

    This article explores the implications of these hardware advancements on DevOps processes within AI and ML. Additionally, we explore strategies DevOps teams may consider to ensure applications remain efficient and portable across various chip architectures.

    The Rise of Specialized Hardware

    Historically, general-purpose hardware, including GPUs and CPUs, was the staple for many workloads. However, a clear pivot to specialized hardware is underway in artificial intelligence and machine learning, where training and inferencing demands have grown exponentially. These applications often hit performance limitations inherent in traditional hardware, partly due to the modern constraints of Moore’s Law. As a result, there is an increasing need for hardware capable of handling specific AI tasks with increased efficiency and speed. For instance, in certain machine learning scenarios, using hardware that supports single-precision floating-point computations can speed up processes without the need for the accuracy provided by double-precision computations.

    Although NVIDIA remains a dominant force in the AI chip market, the competition is heating up, with various companies offering innovative alternatives. And it’s not only from the usual suspects like Intel or AMD; Google has made strides with its Tensor Processing Units (TPUs). Amazon recently announced Trainium2, a new AI chip designed specifically for training AI systems. This chip, set to compete with Microsoft’s Maia and Google’s TPUs, underscores the growing custom AI chip development trend among major tech companies. Beyond these giants, startups such as Cerebras, SambaNova Systems, Graphcore and Tenstorrent bring fresh takes on AI hardware solutions.

    Challenges for DevOps

    As specialized hardware becomes more prevalent, the DevOps community will need to manage various new challenges, including performance portability. Performance portability refers to ensuring that applications run efficiently and perform well across varying computing architectures with minimal to no modifications.

    Cognitive computing (the broader category of AI and ML) varies in complexity, depending on the algorithms, models and creators’ unique demands for hardware-specific features. While an architecture-tailored version will certainly maximize performance on respective platforms, it complicates the process of ensuring a consistent software experience across diverse hardware.

    The challenge of system design lies in optimizing the environment for maximum efficiency, especially when the precise nature of the workload is unknown to those responsible for designing and supporting the systems.

    Of course, there are also significant and related considerations with continuous integration and continuous deployment (CI/CD) pipelines. The intricacies of CI/CD pipelines are magnified when pursuing performance portability. The need to validate software performance across multiple hardware configurations introduces a more elaborate testing matrix and can extend deployment cycles, directly affecting time-to-market requirements. Suddenly, workloads are now crossing the traditional IT infrastructure and high performance/supercomputing boundaries once defined by microservice and batch processing technologies; they are now one in a CI/CD pipeline.

    As organizations adopt specialized hardware, there’s the potential for a parallel rise in specialists focusing solely on one type of hardware or application use case. While such expertise can drive innovation and optimization for a particular platform, it also creates complexity and the potential for knowledge silos and unnecessary complexities for the operations teams and clients that use those systems.

    Leveling up Performance Portability

    Performance portability and closely related concepts, such as hardware-agnostic performance and cross-platform efficiency, are increasingly important for DevOps teams. As the technological landscape shifts, the pressing question becomes: How can the industry and DevOps teams navigate this evolution seamlessly?

    Ongoing research and development will no doubt play a key role. For example, the U.S. Department of Energy (DoE) is exploring new methodologies to support its Exascale Computing Project. This includes refining existing software libraries, pioneering new programming models and developing new tools that could eventually influence wider DevOps practices. Other researchers are developing software abstraction layers, aiming to simplify the adaptation of generic code for specific hardware configurations.

    Beyond new tools and methodologies that may come from current R&D efforts, there are many existing tools and processes that lend themselves to improving performance portability, including:

    • Containerization: Containers encapsulate applications and their dependencies in a way that helps ensure they run consistently across various environments. Open source tools like SingularityCE with Open Container Initiative (OCI) compatibility can help standardize and simplify deployment across different hardware configurations, promoting performance portability for high-performance computing and traditional IT infrastructure management.
    • Benchmarking and profiling: To achieve performance portability, it’s imperative to understand how software behaves across different architectures. Benchmarking tools provide quantitative performance measures, while profiling tools offer insights into software behavior, helping developers identify bottlenecks and areas that need optimization.
    • Code Portability Libraries: In addition to libraries like OpenCL that enable software execution across diverse hardware, recent advancements in container technologies complement this capability. For example, enhancements in container device interfaces, such as those in SingularityCE, streamline the integration of hardware-specific resources. This development aids DevOps teams in optimizing software for various hardware without extensive codebase rewrites, exemplifying the tools supporting hardware diversity and software agility in all aspects of cognitive computing.

    Of course, on top of all these tools and strategies, agile methodologies will remain essential since they prioritize iterative development, continuous feedback/improvement, and adaptability—all of which are important to fast-evolving hardware and software configurations.

    Looking Ahead: Adaptability as the Key

    As we embrace the new frontiers in AI and ML, the role of DevOps teams in navigating a constantly evolving hardware landscape becomes increasingly vital. At the heart of this journey lies the formidable challenge of application portability—a challenge that calls for technical expertise and a strategic shift toward adaptability. Enter containers emerging as indispensable tools that ensure a consistent application experience and performance across diverse platforms and handle the intricacies of portability.

    Likewise, adopting agile methodologies transcends process adherence; it embodies a mindset of flexibility and responsiveness, essential in rapid technological shifts. These approaches, far from temporary fixes, are integral to a strategy that aims to unleash the potential of AI. As DevOps teams continue to navigate these challenges, their success will depend on their adaptability and willingness to explore and integrate established and emerging technologies—particularly those excelling in scalability and efficiency. This proactive exploration and integration will be the key to surviving and thriving in this dynamic technological landscape. And yet, while we have discussed this problem regarding scientific applications, the impact is also felt on the AIOps side of the house, using AI-specific hardware with AIOps practices. While our goal here was to discuss the complexities of creating and administering systems for artificial intelligence and machine learning, we have yet to approach the security conversation, particularly with confidential computing, which is a topic for another time. Happy computing.

  • ngrok Previews API Gateway Service to Streamline App Networking

    ngrok Previews API Gateway Service to Streamline App Networking

    Under an early access program, ngrok today made available an application programming interface (API) gateway that can be consumed as a service.

    Rather than having to deploy, maintain, and secure API gateways themselves, application development teams, via a single command or function call, can now invoke a service through which they can route API traffic, authenticate and authorize access, and apply rate-limiting policies using an ngrok policy engine.

    ngrok CEO Alan Shreve said this approach also makes it simpler for IT teams to unify ingress management at a time when application networking is becoming more challenging to manage. That approach also reduces friction because instead of being dependent on an IT operations team, it gives developers more direct control over APIs, he added. Today, most access to APIs is granted after developer first create a ticket request in an IT services management (ITSM) platform, noted Shreve.

    In addition, the ngrok gateway also streamlines access to APIs spanning multiple clouds and on-premises IT environments in a way that enables organizations to implement a multi-cloud computing strategy, he added. Today, many organizations are locked into a single platform because they are dependent on the API gateway services provided by their cloud service provider, noted Shreve.

    Finally, organizations will only need to pay for the API gateway service based on actual usage versus incurring the cost of acquiring a gateway upfront, said Shreve.

    Previously, ngrok has been making available software development kits (SDKs) to provide programmable access to its API gateway. The as-a-service option being offered now is the next logical extension of that effort, noted Shreve.

    In general, more infrastructure than ever is being consumed as a service, so making available an API gateway service is only the latest example of that larger trend, he added.

    Each organization, based on total cost, will naturally need to decide when it makes the most economic sense to consume IT infrastructure as a service; however, as application networking continues to become more challenging to manage at a time when the number of IT professionals with that expertise remains limited. Relying on a service provides a viable alternative for managing what are often hundreds of APIs spanning a distributed computing environment.

    It’s not clear yet precisely which teams within an IT organization are assuming responsibility for application networking, but as layer 4 through layer 7 of the networking stack become more programmable, more responsibility for networking can be assumed by DevOps and platform engineering teams. Existing networking teams, meanwhile, continue to manage the physical networking underlays used to route network traffic. Regardless of how application networking evolves, the rigidity that has characterized the delivery of network services is starting to fade away in a way that makes it possible to dynamically invoke networking services as needed.

    IT teams must decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications. The goal, however, should be to eliminate as much friction as possible at a time when applications have become more dependent on networking services than ever.