devopsy.kinsta.cloud

Tag: open source

  • AsyncAPI: Transparency as a Value

    AsyncAPI: Transparency as a Value

    History has been marked by opaque and totalitarian power systems. Aided by prisons and walls that keep out the light. The concentration of power in the hands of a few individuals has marked human evolution. From feudalism to fascism, the annulment of the rights of individuals has been based on obscurantism and ignorance. Information has always been guarded by a few, in a few places, and under lock and key. Darkness was always understood as the opposite of knowledge, of science. Plato referred to the cavern, the place where shadows are barely glimpsed, distorted, manipulable from the outside. Subjected to the opacity of the camera obscura, we live in the hope of a shutter that will open a first light bulb.

    Fighting the One-Dimensional

    Faced with the danger of control and censorship, of single direction, of what Marcuse would end up calling “one-dimensional man”, the new tools born at the end of the 20th century cracked the traditional foundations on which power was based. The expansion of the internet offered an opening of windows to the world, the multiplication of paths. The entry of light into every home in the form of a seemingly infinite torrent of information, impossible to censor, unfathomable.

    The arrival of Society 2.0 marked the definitive turning point in government systems toward a necessary democratization. Under its premises, nothing can or should be hidden; everything is potentially visible. Moreover, there are no longer spectators who attend the show, but users appear ready to add their grain of sand in a collective bet, to open their shutter to let in some more light.

    The Spotlight

    The involvement and activation of users is the strength of a collective intelligence. The multiplication of images uploaded by users makes manipulation more difficult, broadens the options for contrasting perspectives and opinions. They add lines of writing to an amplified story.

    The user thus becomes a spotlight that avoids blind spots. One more flashlight at the service of the common good. For the image of a transparency, a slide, for example, to be projected on the wall, we need a light source directed toward the acetate, thus allowing us to see the intricacies of an image that remained in the dark until that moment.

    Disclosure

    Transparency has probably become the fundamental concept of the democratization processes undertaken by governments, institutions and companies in recent years. Ultimately, in its ideal state, democracy is nothing more than a method that allows the members of a community to analyze reality from different points of view to finally make decisions.

    From all this arises open source policy, a system that makes information free and at the same time allows users to see its management and decision-making processes and in which everyone is invited to collaborate. The community thus becomes an essential engine of work and communication.

    The Light

    AsyncAPI arises from this foundation. As an open government project, it defends transparency and democratization in its system of governance and organization. This organizational system aims to empower the people who make up the project, based on a horizontal structure for decision making.

    All relevant project data are public. The tasks under development are within the reach of and open to participation by the community. This is intended to cultivate an environment of trust and respect for the user that stimulates their participation in the pursuit of a common goal. This allows projects to be increasingly collaborative and participatory. Data and metadata. Code and image. As digital photography does, it is no longer possible to attend only to the final state, to the superficiality of the image that is shown, edited, composed, manipulated. The image becomes an open, transparent process, where we can compare its properties, its internal structure.

    Finally, the light.

  • FinOps Cloud Cost Optimization via Governance-as-Code 

    FinOps Cloud Cost Optimization via Governance-as-Code 

    Cloud implementations continue to grow in scope and complexity. Too often, this expansion also means costs keep spiraling out of control. In this article, we’ll examine why the emerging practice of cloud financial management (FinOps) is so essential to containing costs in the cloud. We’ll then discuss the challenges teams encounter as they start to apply FinOps approaches. Finally, we’ll reveal the opportunity presented by employing governance-as-code to establish continuous cloud cost optimization—and how this approach makes it practical for teams to put the theory of FinOps into practice so they can keep cloud costs in check.

    The Emergence of FinOps

    For many organizations, there’s been a race to leverage cloud services, with teams seeking to realize advantages in flexibility, agility and efficiency. Within an organization, it’s not only a matter of more workloads running in the cloud, it’s a matter of more distinct deployment models being used, more teams using cloud services and leveraging multiple service providers.

    In the process, teams have had to contend with rapid growth in the size and diversity of the implementations that have to be managed—and paid for. It is this latter aspect that has been a rude awakening to those responsible for managing budgets. Left unchecked, this growth in cloud use has led to spiraling costs and predicting, managing and controlling these costs only grows more difficult as deployments get more complex and more frequent.

    This need for improved cost management has given rise to a new discipline: Cloud financial management; or FinOps. In short, FinOps is a way of bringing financial discipline and accountability to the variable-cost paradigm found in the cloud. FinOps brings together a combination of technologies, processes and teams, including professionals from technology, finance and business. By gaining an improved ability to understand, track and manage cloud costs, teams can begin to maximize the value realized through their cloud expenditures. Given the strategic and urgent nature of cloud cost management, it’s not surprising that FinOps teams are growing. According to research conducted by the FinOps Foundation, FinOps teams expanded 47% over last year, and these professionals are expecting their teams to grow 75% in the next year.

    Challenges in Establishing FinOps

    While there’s a lot of promise behind the establishment of FinOps practices, there are also many obstacles standing in the way for teams. When the FinOps Foundation queried respondents about top challenges, these were the top five responses:

    • Getting engineers to take action (39%)
    • Dealing with shared costs (33%)
    • Accurate forecasting (26%)
    • Reducing waste or unused resources (25%)
    • Full allocation of costs (23%)

    Lacking comprehensive control and visibility over multi-cloud environments means these teams can’t proactively manage costs—and too often find out about wasted expenditures and high costs of underutilized resources after the fact. Because stretched teams are reliant upon manual follow-ups and tactics, it is difficult to get engineers to respond as quickly and effectively as needed.

    Compounding these challenges is the fact that across teams, different tools and processes are used. For example, different development teams might be using different provider services along with varying deployment tools, such as AWS Cloud Formation, HashiCorp Terraform, Kubernetes and so on. This inconsistency introduces inefficiencies and miscommunication and stifles team productivity.

    While the cloud offers a range of benefits compared to legacy, on-premises infrastructure, without proper governance, cloud costs can quickly spiral out of control. In fact, Gartner analysts report that in the next few years, 60% of organizations will encounter cost overruns in public clouds.

    Rethinking Cost Management

    For all the reasons articulated above, teams are being asked to take a new approach to cloud cost management, one that aligns with the principles of FinOps. For many, this means embracing the concept of governance-as-code to optimize cloud costs. Cloud governance-as-code represents a way to automatically and dynamically apply policies, including for cost optimization, in fast-changing cloud environments.

    With governance-as-code approaches, policies are defined using a standard language. Code associated with cost policies is created, deployed and maintained in much the same way developers manage application or infrastructure code. Developers don’t have to worry about tracking or managing costs. Cost policies are continuously evaluated against current state, utilization and configuration of cloud infrastructure. If any violations occur, automated notifications and workflows can be triggered. Here are the key requirements for using governance-as-code to establish continuous cloud cost optimization:

    Cost Policies are Defined via an Intuitive Language

    Traditionally, development, operations and financial groups worked in silos. Each team had its own tools, workflows and policies, and even fundamental terminology could vary substantially.

    To maximize the potential of continuous cloud cost optimization via governance-as-code, solutions need to enable teams to define, manage and revise policies using an easy-to-understand, consistent language. This makes it much easier for different teams to collaborate and gain alignment on key cost management policies and best practices.

    Finally, to be effective in establishing continuous cloud cost optimization, governance-as-code offerings need to employ a language that is independent of any specific programming languages that application developers may use. Further, these languages should be applicable to the broadest set of applications, cloud services, development tools and so on. This is vital to ensure that development teams retain maximum flexibility in the tools and services they can use.

    Cost Policies are Managed and Deployed via Git Within CI/CD Workflows

    Once policies are reviewed and finalized, teams must be able to apply these policies within the development organization’s existing continuous integration/continuous delivery (CI/CD) workflows.

    Through robust governance-as-code approaches, teams can create cost policies as code artifacts and deploy them via open source version control systems like Git. Through this approach, teams can apply policies in a manner consistent with their software development and delivery life cycles.

    By codifying cost governance in this way, cost controls can be deployed via Git within a CI/CD pipeline. This approach enables teams to avoid complex manual processes associated with tasks like managing tickets, requesting changes and so on. This also helps teams keep up with the accelerating pace of today’s dynamic cloud and development environments. Further, this approach means governance code can be traced through various state changes, rolled back if needed and so on, just like application code.

    Cost Policy Violations are Detected and Addressed in Real-Time

    Through continuous cloud cost optimization via governance-as-code, teams are  empowered to institute not only continuous detection but also immediate action. Policies can be employed at regularly scheduled intervals or they can be triggered based on certain events.  This approach enables enforcement of workflows and actions that may be required. If policy violations occur, notifications to relevant teams or team members can happen automatically and advanced workflows can be triggered. For example, a policy could identify RDS instances greater than 30 days old that have had no connections in the last 14 days. It would then notify the owners of these instances. If they don’t take action in seven days, the instances could automatically be stopped.

    Cost Policy is Continuously Enforced and Refined

    Continuous cloud cost governance-as-code has a never-ending life cycle, just like the team’s software development life cycle. Cost governance code is built, deployed, tested and released, and the process continues as new policies are developed and refined over time. As requirements change, teams need to be able to periodically analyze cost data and update policies as needed.

    As organizations continue to invest larger sums in their cloud implementations, the need to establish strong FinOps capabilities will only grow more critical. However, as these cloud deployments continue to grow more complex, it can get increasingly difficult to realize the promise of FinOps. For these reasons, employing governance-as-code to establish continuous cost management is emerging as a key approach. With this approach, teams can achieve sustained compliance and minimize waste.

  • HashiCorp Previews Updates to Consul Service Mesh

    HashiCorp Previews Updates to Consul Service Mesh

    During an online HashiConf Global conference, HashiCorp today made available a beta of an update to its open source Consul service mesh for virtual machines and Kubernetes clusters that makes it possible for multiple administrators to share the same instance of a multitenant service mesh.

    Version 1.11 of Consul will also add support for a command line interface (CLI) for Kubernetes that will provide an alternative to Helm charts for installing Consul on those clusters.

    Raymond Austin, director of product marketing for HashiCorp, said it’s become apparent that there is a need for a higher level of abstraction for managing application programming interfaces (APIs) that is easy to deploy across both legacy IT environments based on virtual machines and cloud-native environments based on Kubernetes clusters.

    Of course, in many cases, those Kubernetes clusters are deployed on top of virtual machines. However, there are also now more instances of Kubernetes being deployed on bare metal platforms at, for example, the network edge.

    As IT environments become more complex, a service mesh makes it simpler to discover, access and secure APIs that are now rapidly proliferating across the enterprise. That transition requires a more dynamic approach to not only managing APIs but also the network services those APIs depend on, added Austin.

    HashiCorp is betting that many IT organizations will prefer to rely on a lightweight open source platform supported by a single vendor rather than relying on more complex open source service mesh offerings being developed under the auspices of a consortium.

    It’s still not quite clear who within an IT organization is assuming responsibility for deploying a service mesh. Most often, it’s a development team that makes the initial decision. However, as IT operations teams become more aware that service meshes represent a capability that needs to be horizontally made available across multiple applications, it may be only a matter of time before some organizations decide to standardize on a single service mesh to reduce operational overhead, noted Austin.

    Service meshes will also play a critical role in simplifying management of networking and security services at a higher level of abstraction within a larger DevOps workflow.

    It’s still early days as far as service mesh adoption in the enterprise is concerned, but there are already a large number of service mesh options. In fact, there may never be a single dominant service mesh platform. Interoperability standards still need to be ratified that enable organizations that have standardized on different service meshes to apply policies to microservices spanning hybrid cloud computing environments.

    Of course, not every IT organization requires a service mesh yet, either. Many IT teams can still get by using a traditional proxy server or an API gateway until the number of microservices-based applications deployed starts to achieve critical mass. One way or another, however, the more APIs there are to manage, the more inevitable it becomes that an IT team will deploy a service mesh.

  • New Relic I/O Aims to Simplify Instrumentation

    New Relic I/O Aims to Simplify Instrumentation

    New Relic today at the KubeCon + CloudNativeCon North America conference launched a New Relic Instant Observability (I/O) initiative through which it is making available open source tools to simplify application instrumentation.

    Marck Robinson, senior vice president for engineering at New Relic, said the catalog of tools will help DevOps teams instrument a much wider range of applications. New Relic will make those tools available as part of the free tier of its observability platform delivered via the cloud. DevOps teams will be able to use more than 400 pre-configured quickstarts to both instrument applications and create dashboards, Robinson said.

    New Relic itself is contributing quickstarts for cloud services, open source tools and platforms such as Kubernetes, Istio and Cassandra. Third-party vendors that have already contributed to the catalog include Cribl, Fastly, Gigamon, Kentik, Lacework and Trend Micro. Each contribution is being vetted by New Relic as part of an effort to foster the development of a larger open source observability ecosystem, noted Robinson.

    Robinson said overall, New Relic is trying to make it easier for DevOps teams to close an instrumentation gap that is impeding IT organizations from moving beyond monitoring to embrace true observability of their IT environments. The recent New Relic 2021 Observability Forecast report notes only a quarter of respondents (26%) have a mature observability practice, with the most commonly cited barriers to observability being a lack of resources (38%) and skills gaps (29%).

    As a result, DevOps teams often encounter a last-mile observability challenge when it comes to both instrumenting applications and then building their dashboards, said Robinson.

    As part of a larger effort to make it easier to instrument applications, New Relic has open sourced agent software, standardized on the OpenTelemetry tools being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and contributed the Pixie observability platform for Kubernetes environments to the CNCF.

    Observability in one some or another has always been a core tenet of any DevOps best practice. Initially, DevOps teams focused on continuous monitoring as the most effective way to proactively manage application environments. However, it can still take days, sometimes weeks, to discover the root cause of an issue. However, observability platforms are emerging that correlate events in a way that makes it easier for analytics tools to identify anomalous behavior indicative of a root cause of an IT issue. Armed with these insights, it becomes a lot simpler for IT teams to resolve issues faster.

    In contrast, monitoring focuses on predefined metrics to identify when a specific platform or application is performing within expectations. The metrics tracked generally focus on, for example, resource utilization. Observability, on the other hand, combines metrics, logs and traces—a specialized form of logging—to instrument applications in a way that makes it simpler to troubleshot issues without having to rely solely on a limited set of metrics that have been pre-defined to monitor a specific process.

    With the rise of microservices-based applications, the shift to the cloud and more end users than ever working remotely, the need for observability has never been more critical. The issue now is finding a way to make it much simpler to achieve.

  • LF Networking (LFN) Adds to Open Source Portfolio

    LF Networking (LFN) Adds to Open Source Portfolio

    At the online Open Networking & Edge Summit + Kubernetes on Edge Day event LF Networking (LFN), an arm of the Linux Foundation focused on networking, today added several projects that promise to make it simpler to programmatically manage networking services based on open source software.

    Walmart is contributing a L3AF project for managing network applications that make use of an extended Berkeley Packet Filter (eBPF) capability that allows applications to run in a sandbox at the microkernel level of an operating system. Intel and Aarna Networks, meanwhile, are donating the seed code from an EMCO project that provides a universal control plane to securely connect and deploy workloads across distributed computing environments that span everything from the edge to the cloud.

    Arpit Joshipura, general manager for networking, edge and internet of things (IoT) for the Linux Foundation, said the L3AF project adds a control plane for managing those applications to the LFN portfolio that addresses load balancing, rate limiting, traffic mirroring, flow exporter, packet manipulation, performance tuning and other management tasks. Earlier this year, the Linux Foundation set up a separate eBPF Foundation to further advance development and adoption of eBPF across multiple operating systems.

    At the same time, LFN also revealed today that Project Alvarium, a tool for measuring how well data is being delivered to devices that was originally created by Dell, and eKuiper, an existing open source lightweight IoT data analytics and streaming platform, are now part of the LF EDGE portfolio of projects.

    Finally, an open source mobile edge computing project, dubbed Edge Gallery, that was originally created by Huawei has been contributed to the Linux Foundation.

    Joshipura said the LFN continues to gain momentum as more vendors contribute core technologies that, ultimately, don’t provide them with enough differentiated value to continue to develop on their own. The LFN today also revealed that VMware and F5 Networks have joined the LF EDGE consortium as premier members, while mimik and Veena, Inc. have become general members of LFN and the Eclipse Foundation has become an associate member.

    The LFN also provides a mechanism that promotes adoption of those technologies more widely than any one vendor can achieve on its own. The total cost of delivering next-generation edge computing platforms based on wireless 5G networks will also be sharply reduced as LFN projects continue to mature, said Joshipura.

    In general, the rate at which various LFN projects are updated continues to accelerate, said Joshipura. The Akraino project for creating blueprints for edge computing platforms recently delivered its fifth update to address use cases involving smart cities, cloud-native multi-tenant environments and vehicular networks. An EdgeX Foundry project for IoT platforms, meanwhile, recently revamped its application programming interfaces (APIs) to make them more secure and enable more message-based communications. The Home Edge project will also soon issue a Drewberries update that will address code stabilization, scripting, APIs, data synchronization and security.

    It’s now only a matter of time before these LFN projects become more integrated with DevOps workflows as IT teams seek to give developers more programmatic control over network services. The issue now is deciding not so much whether to integrate network operations and DevOps teams but rather determining to what degree those teams will need to fold into each other.

  • IDC Tech Spotlight: Making Open Source Work for You

    IDC Tech Spotlight: Making Open Source Work for You

    Starting from remarkably humble beginnings over three decades ago, open source software is the story of a better mousetrap that wins over the world. Originally, the intent of open source projects was to create software that system administrators and developers could use without having to pay licensing fees – but it has become much, much more. This IDC Technology Spotlight takes a deeper look at the value proposition associated with using commercially supported open source software in mission-critical environments, like IBM Z.

    To read more, please visit: IDC Tech Spotlight: Making Open Source Work for You: Achieving Optimum Value, Security, and Productivity

  • Sonatype Report Shows Spike in Supply Chain Attacks

    Sonatype Report Shows Spike in Supply Chain Attacks

    Sonatype today released a report that finds there has been a 650% year-over-year increase in supply chain attacks aimed at upstream public repositories. Cybercriminals hope to compromise these repositories by injecting malware into software components that many organizations might be using, according to the report.

    The seventh annual State of the Software Supply Chain Report is based on an analysis of 100,000 applications and 4 million component migrations made in the last month alongside a survey of 702 software engineering professionals. Specifically, the report focuses on demand and security trends associated with the Java (Maven Central), JavaScript (npmjs), Python (PyPI) and .Net (nuget) ecosystems. The top four open source ecosystems now contain a combined 37,451,682 different versions of components, a nearly 20% increase year-over-year.

    Over the course of 2021, developers also downloaded more than 2.2 trillion open source packages from the top four ecosystems, a 73% increase over the prior year.

    However, despite the huge available supply of open source software, use of this software is primarily concentrated in a small number of popular projects. Production applications are only using 6% of available open source projects.

    Not surprisingly, popular projects are more vulnerable to compromise. A total of 29% of popular project versions contain at least one known security vulnerability. Conversely, only 6.5% of projects that are not widely used have vulnerabilities.

    Stephen Magill, vice president of product innovation for Sonatype, said popular open source projects tend to have better security practices in place because of the larger number of maintainers and contributors working on the project. The paradox is that less-popular open source software is not likely to be targeted by cybercriminals who tend to focus on targets that represent the best chance to infect downstream applications, said Magill. Popular open source projects were 2.8 times more likely to contain vulnerabilities, the report found.

    Projects with a faster mean-time-to-update (MTTU) are also generally more secure. They are 1.8 times less likely to have vulnerabilities, the survey found.

    The report also found developers make suboptimal choices 69% of the time when updating third-party dependencies, even when newer versions of projects are generally available. Developers may be avoiding those updates because they may be perceived to be not as stable as they would like. However, those updates generally contain the latest security patches needed to address a recently discovered vulnerability. Commercial engineering teams only manage 25% of the components they use, leaving the majority of their open source dependencies stale and susceptible to increased security risks, the report found.

    Finally, the report suggested there is a greater need for automation. Equipped with intelligent automation, a medium-sized enterprise with 20 application development teams would save a total of 160 developer days a year. Sonatype estimated that could save organizations $192,000 a year.

    In general, Magill noted that the security of software supply chains should continue to improve in the wake of an executive order issued by President Biden. In the meantime, however, most organizations would be well-advised to start reviewing the components and dependencies that make up their software supply chain sooner rather than later. After all, chances are good that cybercriminals are already doing much the same thing.

  • How Does That Stack Up?

    How Does That Stack Up?

    There’s an entire class of successful innovations made up of things that people didn’t realize they needed. Things that were an obstacle they found a way around and didn’t think about until the innovation showed them an easier way. Think of things like virtualization (hardware was the bottleneck, but “That’s just the way it is,” until it wasn’t) or web monster shopping sites (“They don’t have that in the stores; I guess I’ll live without,” until you could order the weirdest or smallest things from the likes of eBay and Amazon).

    My rule here is that I only talk about products and services if I use them and find value in them. And even then, I try to do it sparingly. But in the spirit of the innovation story you just read, I’m going to point you at one of the coolest new websites on the net. I don’t know the company; have not done business with them, couldn’t even name a principal. But I have spent a surprising amount of time on their site, both in the Feed section and Browsing Stacks.

    The site is Stackshare.io, and the reason I think it is so innovative is what and who it is aimed at: Listing companies’ DevOps stack and offering advice on different parts of the DevOps stack.

    The Browse Stacks section is for presenting what other organizations are doing, so you can get good ideas for your own stack. But the developers of the site appear to have recognized the other useful aspect of this information: Matching organizations to prospective employees based on technologies. You can go look and see that Company X is using GitLab, for example, and that can then influence your job search.

    The Feed section is just a running discussion that uses categories to ask questions or offer insight and advice about decisions a given organization came to—so, “Chose X over Y” is actually a standard subheading for posts, as is “Need advice on Z” or “Recommends A”. It makes for great reading, and no doubt while reading through, you’ll have some advice to offer one of the “Looking for advice” posts.

    The Stackshare.io participants seem to range in size from startup to massive, and that is one of the things I hope they change as they grow—the options for looking at DevOps stacks are “Popular” and “Trending”. We all want more filters than that—organization size, number of apps, stuff like that—to help us zero in on environments that are similar to our own. My little company does not have the needs that Facebook does. And while it’s true that some startups use more tools in their toolchain than Facebook, you get the idea.

    Another issue I had with Stackshare.io’s site (that I fully understand, but still wish could be different) is forced registration/login to see some data. It’s not even particularly sensitive data—I know what ELK and Azure Data Services are, so putting the definition/description behind a registration page/login is kind of silly. But every free site needs data to pay the bills, and I suppose I’m glad it is info that’s also available elsewhere that is behind a reg wall.

    The company offers APIs for integration to your site/tool and private company instances of StackShare to help you manage one of my other gripes—the five (or fifty!) different DevOps stacks many organizations have allowed to develop in-house.

    So if you are job hunting, Stackshare.io can help you find companies doing what you would like to do or know you’re good at. If you are an organization trying to improve or set up a new toolchain (which is how I found the site), it has a lot of information to digest, though not all of it is easily accessible at this point. Either way, keep kicking it and keep an eye out for tools that do the job, no matter where you are looking.

  • F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks today revealed plans to launch multiple projects in the months ahead that will extend its commitment to open source beyond the NGINX proxy software the company acquired in 2019.

    The announcement was made during an online NGINX Sprint event; two of the projects are extensions of NGINX that will address networking requirements between microservices-based applications in addition to the management of fleets of NGINX instances. The third project is a platform-agnostic open source developer tool for building modern applications that does not necessarily require NGINX proxy software.

    At the same time, F5 Networks also unveiled an open source NGINX Modern Apps Reference Architecture that gives IT teams access to a complete, fully operational microservices-based application that can be deployed in minutes on a Kubernetes cluster. Based on a modular approach made up of open source components that come pre-wired and pre-integrated, F5 Networks is committing to extending this framework in collaboration with multiple third-party vendors and organizations.

    F5

    Rob Whiteley, general manager for the NGINX product group at F5 Networks, said the company is also committing to modernizing its NGINX proxy software to leapfrog rival open source Envoy proxy software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). NGINX is still more widely employed than Envoy largely because it is lighter-weight and easier to deploy, but Whiteley conceded that Envoy has more advanced capabilities.

    Envoy, of course, is at the core of the Istio service mesh. F5 Networks supports both Istio as well as a service mesh it has developed on top of NGINX. Depending on the number of application programming interfaces (APIs) that an organization needs to support, an IT team might make use of proxy software, ingress controller or an API gateway for a service mesh to manage them.

    Finally, F5 Networks said it will participate in the Kubernetes ingress project and that it is joining the gateway API community as its implements its own NGINX-based gateway controller to ensure its proxy software and Kubernetes remain tightly aligned in the future.

    In general, Whiteley said F5 Networks also is making a commitment to be clearer about where the line between the open source and commercial editions of its offerings is drawn. As a rule, the open source editions are designed for developers and small teams while the commercial version is designed to scale within enterprise IT environments. The overall goal is to promote innovation without enabling cloud service providers to reap all the revenue benefits of F5’s research and development by creating a service based on that open source software, said Whiteley.

    As part of that effort, F5 Networks is expanding the number of open source projects it supports to make it easier for developers to contribute code beyond the core NGNIX proxy software, said Whiteley.

    It’s not clear to what degree F5 Networks will be able to rally the open source community to advance additional projects beyond NGINX. The company is promising to provide additional details at an unspecified future date. However, Whiteley said there is still plenty of room for innovations not only in emerging technologies such as service meshes but also proxy software that is already widely employed within many enterprise IT organizations. Especially since most of them are embracing microservices-based applications that will ultimately change every aspect of IT.

  • Kentik Open Sources Five Projects to Advance Network Observability

    Kentik Open Sources Five Projects to Advance Network Observability

    Kentik today unfurled a developer hub, dubbed Kentik Labs, through which it is making five open source projects available as part of an effort to advance observability across network operations (NetOps).

    The five projects are:

    kTranslate: A system for pulling and pushing network data that is the basis of the Kentik Firehose integration the company created for the New Relic observability platform

    NetDiag: Scalable, asynchronous implementations of low-level network diagnostics

    Convis: Example code showing how to attribute process and container information to network traffic via the Linux kernel using eBPF

    kProbe: A high-performance host and sensor network probe (PCAP)

    Grafana App: A real-time tool for ingesting and querying network data

    Nick Stinemates, vice president of business development at Kentik and co-chair of Kentik Labs, said the goal is to enable DevOps teams to incorporate NetOps within the workflows already being employed to programmatically manage the rest of IT.

    Stinemates noted that, as IT environments become more distributed, managing NetOps has become more challenging. If there is a failure, it can be difficult for DevOps teams to determine if the issue is due to application code, the underlying infrastructure or some other root cause. Kentik Labs is committed to providing tools that will help DevOps teams reduce their mean time to recovery (MTTR), he added.

    Most NetOps teams increasingly rely on software to manage distributed networks either in the form of graphical tools provided by router and switch vendors or by using the Python programming language and the open source Ansible automation framework that enables IT teams to declaratively manage IT infrastructure.

    As the teams that manage network operations gain more proficiency with those tools, it becomes simpler to incorporate them within the construct of a larger DevOps team. While DevOps teams have been programmatically managing IT infrastructure-as-code (IaC) for years, network management has largely remained in a separate silo. However, as more applications are deployed in the cloud, it’s clear NetOps needs to become more integrated with the rest of the workflows employed to deploy and manage a highly distributed IT environment, said Stinemates.

    Less clear is to what degree the networks that make up a hybrid cloud computing environment will continue to be managed by network administrators versus site reliability engineers (SREs) that are starting to assume responsibility for managing compute and storage.

    Regardless of who manages the network, the next generation of microservices-based applications that are dependent on application programming interfaces (APIs) to call various services are much more latency-sensitive than previous generations of applications. Many of those applications will regularly experience performance issues due to networking issues that are often not readily apparent to DevOps teams. The goal should be to, at the very least, arm those DevOps teams with the tools required to confirm the source of those issues before a “war room” is convened to determine how to address the issue.