Tag: KubeCon

Ghosts in the Machine: How AI Agents Will Take Over DevOps
Would it be good or bad if your deployment pipeline had a mind of its own, where your infrastructure adapted to changes before you even noticed them?

This will happen in DevOps by introducing AI agents into the ecosystem. An AI agent is an AI that can take action. Think about a traditional LLM like OpenAI’s ChatGPT or Anthropic’s Claude. These AIs process input and generate output, but it is up to the user to act on the information. ChatGPT can create code and manifests capable of running a container, but it has no agency — it cannot act on what it knows.

AI agents are different. They have three key capabilities:
- Perception: Agents gather and interpret information from their environment. This could involve reading logs, monitoring metrics or analyzing reports. Perception allows the agent to understand the context in which it operates.
- Decision-Making: Based on perception and programmed objectives, agents evaluate situations and determine the best course of action. This might involve using ML/LLM models, rule-based systems or a combination of both to make informed choices.
- Action-Taking: Unlike traditional AI models, agents can execute actions in their environment. In a DevOps context, this could mean deploying code, adjusting configs or initiating automation. The ability to act autonomously is what sets agents apart from passive AI systems.
These three capabilities work together in a continuous loop, allowing AI agents to interact with and influence their environment in real-time. This makes them potent tools in the DevOps ecosystem.

How AI Agents Can Work in DevOps

How might this look in reality?

Like this:

Just like any deployment cycle, it starts with a developer pushing code changes to a repo. In current deployment pipelines, CI/CD automation kicks in at this point to test and deploy the code.

The agent sits at this point and monitors the repo for new commits. Upon detecting new code, the AI agent analyzes the changes and determines the optimal deployment strategy. Only then does the AI agent trigger the CI/CD pipeline. This pipeline is adjusted by the agent depending on the code, running different types of tests or adjusting the testing queue given preset priorities.

Then, the AI agent deploys the application and configures/provisions infrastructure as needed (e.g., scaling servers and allocating storage). Post-deployment, the AI agent continuously monitors performance and infrastructure health, collecting metrics, logs and events for constant analysis.

The agency comes from moving through the deployment pipeline and adjusting the pipeline on the fly. An AI agent can act to resolve issues as they arise. It will analyze the data in real-time and implement fixes from its knowledge base, such as restarting services, rolling back deployments, adjusting configurations or scaling resources. If it can’t fix the issue, only then the fault needs to be escalated to a human engineer.

Within all this, the agent is also learning. After any resolution, the AI agent updates its models based on new data and human feedback. It refines its algorithms for deployment strategies, anomaly detection and issue resolution, so the AI Agent becomes more proficient over time, reducing the need for human intervention.

We can quickly see the huge benefits of this within DevOps:
1. Increased Efficiency and Speed: AI agents can operate 24/7 without fatigue, making decisions and acting much faster than human operators. This leads to quicker deployments, faster issue resolution and overall improved operational efficiency.
2. Proactive Problem Solving: With their ability to continuously monitor and analyze system data, AI agents can often predict and prevent issues before they impact users. This shift from reactive to proactive management can significantly improve system uptime and user experience.
3. Scalability and Consistency: AI agents can manage increasingly complex systems and larger infrastructures without a proportional increase in human resources. They also ensure consistent application of best practices across all operations, regardless of scale.
4. Reduced Operational Costs: AI agents can significantly reduce operational costs by automating routine tasks, optimizing resource allocation and minimizing downtime. They can also make more efficient use of cloud resources, reduce the need for large on-call teams and minimize the financial impact of outages or performance issues.
These benefits demonstrate how AI agents can transform DevOps practices, leading to more robust, efficient and cost-effective operations while freeing human engineers to focus on higher-level strategic tasks and innovation.

What Agents Mean for Engineers

So, what of those human engineers? Is this the end of the DevOps role, with machines running the machines?

Yes, and no. Yes, in that the DevOps role will change. But no, in that the DevOps role won’t disappear. Instead, DevOps engineers will be freed to contribute more strategically within an organization. We see three possibilities for human input in the system.

First, the escalatory role. In this role, DevOps engineers become the ultimate problem solvers, handling issues that AI agents can’t resolve on their own. This role requires a combination of broad technical knowledge and creative problem-solving skills, as engineers will be tackling the most challenging and unique issues in the system.

Next, is the management role. DevOps engineers in this role will oversee and manage the AI agents, much like they might manage a team of human engineers today. They will be responsible for setting goals, defining policies and ensuring that the AI agents operate efficiently and ethically. This role involves a shift from hands-on technical work to more strategic thinking, requiring skills in project management, system architecture and even AI ethics.

Finally, the agenticops role. This emerging role focuses on the intersection of AI and operations. AgenticOps engineers will specialize in designing, implementing and optimizing AI agent systems for DevOps. They will need to understand both the intricacies of DevOps practices and the capabilities and limitations of AI technologies, acting as a bridge between traditional IT operations and cutting-edge AI implementations.

The machines aren’t here to replace us; they are here to elevate us.

To learn more about Kubernetes and the cloud native ecosystem, join us at KubeCon + CloudNativeCon North America, in Salt Lake City, Utah, on November 12-15, 2024.
November 5, 2024

Breaking Free From the Dead Zone: Automating DevOps Shifts for Scalable Success

When building software, especially SaaS, sticking to manual processes in DevOps is like bringing a knife to a gunfight. Manual processes not only slow down operations but also open the door to mistakes that can escalate into significant problems. This tricky spot, where there’s not enough automation and too much room for human error, isn’t a good place to be if your organization wants to grow smoothly and reliably.

Many organizations have adopted “shift left” as the primary driver for automation through CI/CD pipelines. This is good, but without automation at every step of the software deployment process, gaps exist and they can be glaring.

In this article, we’re going to introduce two terms that you’ve likely not seen before: ‘Shift Right’ and the ever-so-dangerous ‘Dead Zone’ of automation. We’ll explore how these two types of DevOps shifts can work together to alleviate DevOps toil and improve the quality of the services you deliver.

Understanding ‘Shift Left’: The First Piece of the Automation Puzzle

Let’s revisit the concept of “shift left.” In DevOps, shifting left means moving tasks like testing, security checks, and quality assurance to earlier in the development process—basically, closer to the start line where the code is written. Instead of discovering bugs or security issues right before launch (or worse, after it’s live), developers catch and address them upfront. For DevOps practitioners, this approach has been a real game-changer. It speeds up development cycles, reduces the cost and hassle of late-stage fixes, and leads to more robust, reliable SaaS. By bringing automation tools into the early stages, teams can nip problems in the bud, making the whole process smoother and more efficient.

You are likely already “Shifting Left”. For example, if you rely on build-time container security scanning, that is in effect shifting vulnerability management closer to your source code repo making the process “GitOps” friendly.

By Integrating automated unit tests into your development workflow, and by running these tests every time new code is committed, you’re catching bugs earlier in the process. That, in turn, reduces the chances of issues cropping up later in production.

Similarly, implementing static code analysis tools that scan for code quality and security issues as developers write code is a form of shifting left. This practice provides immediate feedback, allowing developers to address potential problems on the spot rather than during later stages of the development cycle.

All these automation methods share a common characteristic: when issues are found, it’s up to the developer to fix them. This often leads to the use of tracking tools like Jira to log issues for later resolution. In essence, when things go wrong, human intervention is still required—a point we’ll delve into further later on.

The Power of ‘Shift Right’ Automation

If ‘Shift Left’ is all about integrating processes closer to the source code, ‘Shift Right’ offers a complementary approach by tackling challenges that arise after deployment. Some decisions simply can’t be made early in the development process. For example, which cloud instances should you use? How many replicas of a service are necessary? What CPU and memory allocations are appropriate for specific workloads? These are classic ‘Shift Right’ concerns that have traditionally been managed through observability and system-generated recommendations.

Consider this common scenario: when deploying a workload to Kubernetes, DevOps engineers often guess the memory and CPU requests, specifying these in YAML configuration files before anything is deployed. But without extensive testing, how can an engineer know the optimal settings? Most teams don’t have the resources to thoroughly test every workload, so they make educated guesses. Later, once the workload has been running in production and actual usage data is available, engineers revisit the configurations. They adjust settings to eliminate waste or boost performance, depending on what’s needed. It’s exhausting work and, let’s be honest, not much fun.

‘Shift Right’ embraces the idea of not being tied to specific configuration settings at build time. Sure, we start with initial resource requests, but automation should adjust them swiftly. Runtime systems are better positioned to observe and make real-time adjustments. By shifting right in this context, we achieve better application stability and lower costs because we eliminate waste as it happens. It’s more effective to set scaling policies or guardrails for what automation can do, rather than sticking to rigid configuration settings.

Conflicting Approaches?

So, what happens when ‘shift left’ and ‘shift right’ strategies bump into each other? Let’s consider the example of workload rightsizing. How do we ensure that configuration changes made on the ‘right’ (post-deployment automation) don’t conflict with the source code on the ‘left’ (our pre-deployment configurations)?

Consider the deployment file below, where resource requests and limits are hard-coded:

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 2
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
– name: my-app-container
image: my-app-image:latest
resources:
requests:
cpu: “500m”
memory: “512Mi”
limits:
cpu: “1000m”
memory: “1Gi”

In this deployment file, the CPU and memory requests and limits are explicitly defined. If an automated system adjusts these settings at runtime to optimize performance or reduce costs, it creates a mismatch between what’s in your source code and what’s actually running in production. Continuous deployment tools like ArgoCD might flag these discrepancies as “drift” and could even revert the changes to match the original settings defined in code.

But here’s the catch: in Kubernetes, a Deployment creates Pods, but pods themselves don’t exist as entities in your source code. They are generated based on the Deployment specifications. This is actually beneficial for workload rightsizing because we can adjust pods at runtime without violating the consistency of our Infrastructure as Code (IaC).

So, if we don’t want to be tied down by the specific values in the configuration file above, what should we be setting instead? In CAST AI’s approach to workload rightsizing, we allow DevOps engineers to define scaling policies using annotations:

annotations:
workloads.cast.ai/vertical-autoscaling: “on”
workloads.cast.ai/scaling-policy: “my-scaling-policy”
workloads.cast.ai/apply-type: “immediate”

These settings are declarative rather than imperative—a style that’s very much in line with Kubernetes philosophy. Instead of specifying exact resource values, we’re defining the desired behavior at runtime. We tell the system what we want it to achieve and let automation handle the specifics. This way, we focus on setting policies or guardrails that guide the automation, rather than hard-coding low-level attribute values.

This is a great example of a ‘Shift Right’ strategy that compliments ‘Shift Left’”. We allow the runtime to set specific attributes of workloads, while source code contains specific guardrails and policies to ensure that the runtime has a reasoned strategy that captures the DevOps engineer’s desired state.

Considering ‘Shift Right’ for Container Security

We typically use image scanners integrated into the CI/CD pipeline to scan containers at build time, catching vulnerabilities before they ever reach production. This is how teams ‘shift left’ for security. However, if we stop there, we’re leaving our production environment exposed to container drift.

Let’s go over a significant yet somewhat common example: Imagine your data science team wants to deploy Jupyter notebooks within Kubernetes, attached to GPU nodes. Sound familiar? This setup is common because most local environments lack the GPU capacity to run meaningful machine-learning experiments.

You’ve scanned the Jupyter container image, and it comes up perfectly clean—zero vulnerabilities. It might look something like this from a scanning tool:

So how does container drift impact us? Python environments often lack certain packages, so we have the convenient !pip install command to add packages as needed. This is where things can go wrong. Well-intentioned data scientists might install anything, and that includes potentially harmful software like crypto miners, even in a container image that initially had zero vulnerabilities. Vulnerabilities like this can’t be stopped at build time—shift left isn’t an option here. To prevent these kinds of accidental or malicious activities, we need to shift right and leverage runtime detections.

Fig: A screenshot from a Jupyter Notebook application that connects to XMRig, a common crypto mining server.

But detecting these types of vulnerabilities isn’t enough. What then? Do we need a DevOps engineer to manually kill the malicious pod? How do we know if any damage was inflicted, or data exfiltrated?

A good runtime solution will not only detect malicious behavior like the example above but also automatically take action to kill the offending workload and prevent it from re-entering the system. Even better, it would be ideal if such workloads could be quarantined in a running state, giving SecOps a chance to examine what the malicious workload is doing and how it got into the environment. We call these types of automation policy enforcement. Without automation, we’re still relying on individuals to do the right thing.

Avoiding the Dead Zone

Having explored both ‘shift left’ and ‘shift right’ strategies, it’s clear that the dead zone — that middle ground dominated by manual processes—is a place we want to avoid. This zone is fraught with inefficiencies, human errors, and delays that can hinder growth and innovation. By embracing automation on both ends of the development lifecycle, we eliminate these pitfalls. Automation keeps us out of the dead zone by ensuring that tasks are handled quickly and consistently, freeing up our teams to focus on what truly matters: delivering value and driving the organization forward.

The Future of Automation: Left and Right Working Together

The future of automation in DevOps lies in creating bridges between the “shift left” and “shift right” strategies. A prime example of this is Dependabot, a tool provided by GitHub that automates dependency updates. Dependabot scans your project’s dependencies for outdated versions or vulnerabilities and automatically generates pull requests to update them.

Why is this important? Because it tackles a tedious yet critical task — keeping dependencies up-to-date to ensure security and compatibility. Dependabot automates the detection and initial update process, but it doesn’t remove humans from the equation. Instead, it involves them at the right moment, allowing developers to review and merge the changes. Machines handle the heavy lifting of identifying and proposing updates, while humans provide oversight and make informed decisions.

This approach exemplifies how automation can 10x outcomes without sacrificing control. It acknowledges that while some issues originate on the left or right sides of our pipeline, their solutions need to be fully integrated back into the source code to be effective. Automation initiates the fix, but human expertise ensures it’s implemented correctly.

At CAST AI, we’re excited about expanding this concept. For instance, suppose our system identifies an optimal database index that could significantly improve performance. Creating the index at runtime offers immediate benefits, but it’s not the complete solution. To make this improvement lasting and maintainable, we need to incorporate the change back into the application source code and move it through the entire pipeline.

This is where we see significant innovation potential that will help our customers avoid the dead zone. By automating the identification of such optimizations and facilitating their integration back into the development process, we will create a feedback loop that continuously enhances our customers’ software. We will ensure that improvements aren’t just temporary patches but become part of the application’s foundation.

Final Thoughts

Automation is no longer a luxury; it’s a necessity for scalable success. By leveraging both ‘shift left’ and ‘shift right’ strategies and ensuring they work together, we can eliminate toil and reduce the potential for human error. The key is to empower our teams with tools that automate the mundane and highlight the impactful, allowing us to focus on what truly matters: building great software.

To learn more about Kubernetes and the cloud native ecosystem, join us at KubeCon + CloudNativeCon North America, in Salt Lake City, Utah, on November 12-15, 2024.

November 5, 2024

Three DevOps Trends to Watch in 2024

The world of DevOps has evolved at an unprecedented rate in the last few years, yet it continues to be a primary driver of efficiency, innovation, and digital transformation for many organizations. Google’s 2023 Accelerate State of DevOps Report shows that a company’s software delivery performance quality predicts organizational performance, team performance and employee well-being.

In 2024, there are several trends that practitioners can expect to have a major impact on the industry. Forward-thinking tech companies will take advantage of the convergence of these trends as the year progresses. Opportunities exist for leaders in the cloud and virtualization arenas to increase operational flexibility, improve disaster recovery measures and leverage the rapid advancement of new technologies to give their company a competitive edge.

As the year rolls on, here are a few key DevOps trends to watch for in 2024:

1. Apple Silicon Release Cycles

The era of Apple Silicon is now in full force. With Apple now creating its own chips, the company can have complete control over its product development timeline. Additionally, each release is increasingly nuanced in how the hardware/software stack is built. In 2023 alone, we saw the introduction of the new M3 chip series, the completion of Mac’s transition to Apple Silicon among many other new capabilities and innovations. As the use of Apple technology in the enterprise continues to expand, companies that can quickly adapt to the faster release cycles of Apple’s new chipsets will see significant performance improvements.

2. Hybrid and Multi-Cloud Adoption

To compete in today’s dynamic business landscape, harnessing the power of cloud technologies is essential. The industry can expect to see a major surge in hybrid and multi-cloud adoption. In addition to the cost-efficient nature of the cloud, enterprises are increasingly moving towards hybrid and multi-cloud models to enhance operational flexibility and improve disaster recovery measures. In fact, global spending on cloud adoption is projected to top $1 trillion in 2024. As the cloud continues to be a key driver of innovation across industries, the ability to serve and integrate solutions across cloud providers or on-premises is increasingly becoming table stakes. Platforms that can operate seamlessly across these diverse cloud environments will offer a significant competitive advantage.

3. Securing Remote Work and Virtualization Environments

As virtual desktop infrastructure (VDI) continues to take the world by storm, security and compliance across complex environments is crucial. The continued advancement of cyberthreats makes the challenge of securing virtual identities more pertinent than ever. Especially as companies look to mitigate the risks of device and intellectual property theft in offshoring and consulting scenarios, the demand for secure remote desktop technologies has never been higher.

Additionally, security and compliance regulations are becoming increasingly robust. And providers should leave no stone unturned to ensure that their platforms are compliant with all security regulations and consistently audited to address any vulnerabilities that may pop up. Ensuring that the solution provided is living up to its promise especially as it relates to security and compliance is crucial to the public’s perception of your business. Solutions that offer robust security features while also enabling scalability and flexibility in operations will have a competitive edge as we enter the new year.

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.

March 14, 2024
What’s Driving Changes in Open Source Licensing?

Open source projects like Kubernetes transformed the software industry with the help of cooperative communities like the CNCF and the ability to share information quickly. Open source has also made it easier to launch products and gain market share with vendor-driven open source software (OSS) projects, kind of like a premium or PLG sales go-to-market (GTM) model.

However, years of SaaS innovation and disruption have threatened the profitability of vendor-driven open source projects, forcing several major players to shift away from the open source licensing that their companies were founded on. These changes have not only upset the user community but have also caused some people to wonder about the future of OSS. However, there are key differences between the projects that have recently changed their license to be more restrictive and projects supported by communities like the CNCF.

Vendor-Driven Versus Community-Led OSS

How involved and influential is the user community compared to the main or original vendor? This is one way to classify open source projects. Open source projects driven by the community are those where the community of users has the lead role in creating, updating, supporting and securing the software. Some examples are Kubernetes, Linux, Apache and CNCF projects. These projects usually use permissive licenses, such as GPL, Apache or MIT, that let users change, share and use the software for any reason without imposing limits or requirements. These projects also follow the cloud-native principles of scalability, portability, resilience and automation. Open source projects that are driven by vendors are those where one vendor or a few vendors provide most of the software and maintenance. At the same time, the community of users may add some modifications, support and patches. The primary motivation behind these projects is to monetize them. Some examples of open source projects that are driven by vendors are MongoDB, Elastic, Redis Labs and HashiCorp. These projects often use licenses that are more limiting or conditional, such as AGPL, SSPL or BSL, that restrict the use of the software in some situations, such as offering it as a service, or requiring users to pay fees or share changes. These projects may also have features or services that are proprietary or not available in the open source version or that are customized for specific cloud platforms or environments.

SaaS Influence on Open Source Projects

The advent of cheap and ubiquitous cloud computing resources and fast broadband connections has transformed the way software is delivered and consumed. Software-as-a-service (SaaS) has become a dominant model for many applications, offering users convenience, scalability and cost savings. However, SaaS also poses a challenge for some vendor-driven open source projects, as it enables cloud providers and other competitors to offer the same or similar software as a service without contributing back to the original vendor or the original project. This reduces the revenue potential and the incentive for the vendor to continue investing in the open source project.

In response to the challenges posed by cloud computing, some vendor-driven open source projects have changed their licenses or their GTM models. For example, MongoDB, Elastic, Confluent, Redis Labs and HashiCorp have adopted new licenses that restrict the use of their software-as-a-service by third parties or require them to pay fees or share their modifications. These changes are intended to protect the revenue and sustainability of the original vendors and to ensure that they can continue to invest in the open source project. However, these changes have also caused some controversy and backlash from the user community, who may feel that the project is becoming less open and more proprietary or that they are losing some of the benefits and freedoms of open source.

However, community-driven open source projects have largely maintained their permissive licenses and their collaborative approach. These projects still benefit from the diversity and scale of their user community, who contribute to the development, maintenance, support and security of the software. These projects also leverage the support of organizations and foundations, such as the Linux Foundation, the Apache Software Foundation and the CNCF, who provide governance, funding and infrastructure. These projects may also offer premium features or services, such as certifications, training or consulting, to generate revenue and sustain the open source project.

Summary

There are many different types of projects, licenses, communities and business models at play. While some vendor-driven open source projects have faced challenges covering development costs and have changed their licenses to be more restrictive, community-driven projects have largely maintained their permissive licenses and collaborative approach because the incentives behind these projects aren’t driven by profit. Open source is and will remain a vital and valuable component of the technology industry, enabling innovation, collaboration and interoperability.

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.

March 8, 2024
7 API Observability Anti-Patterns to Avoid
Observability has become a buzzword, and the API world is slowly catching up. But be careful when looking for content about API observability- there are many outdated best practices and irrelevant pieces of content.

I was recently invited as a guest to Stephen Townshend’s SlightReliability podcast, and his brilliant blog post on “Bad Observability” inspired me to start ranting about the topic.

Here is a follow-up to our discussion: The observability anti-pattern to avoid when working with APIs. Thanks, Stephen, for the inspiration!

Anti-Pattern: You Forgot Your Users

It’s easy to lose sight of the fact that APIs are built for people to use. APIs are not just a technical interface; they are a bridge that connects digital experiences and enables people to accomplish tasks efficiently.

There are two different kinds of users for your API:
- The developers who are integrating your API into their system.
- Your customers’ users, who will ultimately interact with the applications or services that rely on your API.
If you can’t understand how they interact with your APIs, you’re missing half the picture.

When developers integrate with your APIs, how long does it take them to make their first successful API call? What are typical errors slowing them down? Observability plays an essential role in surfacing insights to improve developer experience.

Once your customers’ applications or services relying on your APIs are in production, can you track how your releases impacted their requests? Which version of your APIs are they using? What are the most popular endpoints? Are all customers getting the same performance? Same error rates?

Anti-Pattern: Relying Only on API Monitoring

API monitoring typically involves sending automated test requests to API endpoints and verifying the responses. It helps you keep track of the health of your APIs even when there is no customer activity at all, and can be used to report uptime.

But API monitoring is nothing more than black box testing; you don’t see what is happening inside. You just know that your requests reach the API and receive responses, but you can only create and maintain tests for some possible use cases. You will miss something.

Anti-Pattern: Using API Access Logs for Troubleshooting

API access logs are records of requests and responses made to an API, capturing details such as the requestor’s IP address, HTTP method, requested endpoint, status codes and other relevant information for monitoring, debugging and security purposes.

Using access logs to troubleshoot API issues is like searching for a needle in your microservices haystack. One of our users had a performance issue with their APIs; they spent days searching for the root cause using access logs. Is it the gateway? Does it need more CPU? Is it a configuration issue? They enabled distributed tracing and, within seconds, they could see what was happening: All the time was spent in the authentication server issuing JWT tokens.

To really understand what is happening in your system, you need to be able to track a single user request from the API gateway to the upstream services and their dependencies for effective troubleshooting.

As Martin Thwaites puts it: “Logs are a poor man’s observability tool.” You need distributed tracing.

Anti-Pattern: Different Teams, Different Tools, Different Data

Different teams have different needs. The tool that works for your DevOps team might not fit your product team best. By forcing everyone to use the same tool, you’re not promoting unity but inefficiency.

However, while promoting tool diversity might be the right move for your organization, there should be some coordination and integration between different tools and data sources. Open standards like OpenTelemetry help ensure that information can be shared and leveraged across teams and tools.

The DevOps and the product teams should rely on the same error rate when assessing the performance and reliability of the newest API product launched.

Anti-Pattern: One Size Fits All

Different API architecture styles have different needs when it comes to observability.

REST APIs might be today’s default, but newer styles like GraphQL and gRPC are gaining popularity. Each of these styles has distinct characteristics and requirements regarding observability. Just think about GraphQL’s way of handling errors, which differs significantly from REST APIs. Web Socket and event-driven APIs have their own unique observability challenges, as well.

Different API architectures have different needs, and your observability strategy needs to reflect that to improve the overall reliability of your application.

Anti-Pattern: Observability for Production Only

Why aren’t you using observability in pre-production?

By using distributed tracing during the API development life cycles, developers can trace the flow of requests and responses across different services, providing a comprehensive view of how the API behaves under various scenarios.

With observability, they can identify performance bottlenecks and even detect architectural problems like N+1 problems in GraphQL queries.

For teams leveraging APIOps practices, observability data can be used as an additional validation before promoting an API to the production stage.

Anti-Pattern: Starting the Trace at the API Gateway is Overrated

Tutorials about observability usually start the instrumentation process at a microservice level. It is great to have detailed insights into your microservices. But a lot will happen at the API gateway level when dealing with APIs.

You want to capture all your user transactions, including those that never reach your microservices because of rate-limiting rules, an authentication problem or a caching mechanism.

Starting the trace at the API gateway gives you a clear entrance point and a complete picture of the journey of all your users. That’s why it’s important to use a modern API gateway with built-in support for OpenTelemetry.

So there you have it: Seven API observability pitfalls to avoid. Keep your APIs observable and your users happy!

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.
March 6, 2024
Driving the DevOps Evolution: ArgoCD, Tekton and Seamless Migrations
The landscape of CI/CD frameworks has evolved over the last couple of years. From the early days of Flux and Jenkins to the current focus on ArgoCD, this journey reflects the industry’s momentum toward efficient and reliable deployments.

In recent times, we have seen many modern software delivery platforms adopt ArgoCD or Flux for automating deployments within their ecosystems. However, as multi-cloud deployments and scalability still remain a challenge, we are seeing the industry shift toward more powerful Kubernetes-native frameworks like Tekton.

Evolution of CI/CD Frameworks

Flux: Paving the Way for GitOps

Flux was one of the pioneers in promoting the GitOps methodology. It allowed developers to manage infrastructure and deployments declaratively through version-controlled manifests.

GitOps, as introduced by Flux, emphasized the use of Git repositories as the single source of truth for configuration, making deployments more reliable and traceable.

Jenkins: The CI/CD Workhorse

With its extensibility and vast plugin ecosystem, Jenkins quickly became the go-to CI/CD solution for many organizations. While Jenkins was powerful, its complexity and challenges in maintaining pipelines led to the exploration of alternative solutions.

Spinnaker: Scaling Deployments

Spinnaker emerged as a powerful tool for continuous delivery with a focus on scalability and multi-cloud deployments.

Its support for canary releases, blue-green deployments, and pipeline orchestration attracted organizations aiming for more sophisticated deployment strategies.

ArgoCD: The Rise of GitOps

ArgoCD brought a renewed focus on GitOps, building upon the foundation laid by Flux. It provided a declarative way to manage Kubernetes applications, ensuring that the desired state in the Git repository is continuously in sync with the cluster state.

The adoption of ArgoCD has been widespread due to its simplicity, scalability and ability to synchronize with multiple clusters.

‘Modern’ DevOps Platforms: Riding the ArgoCD Wave

Many ‘modern’ software delivery platforms have either incorporated or integrated separately with ArgoCD to attempt a complete software delivery approach. This integration enables users to adopt GitOps principles seamlessly within their existing workflows.

Here’s a glimpse into what it looks like to work with ArgoCD on these platforms:
1. First off, you will have to orchestrate CI separately, which leads to context switching and a non-unified CI/CD workflow. You will need to leverage plugins on most of these platforms and hop back and forth between exploring steps and adding them to your pipeline for a few others.
2. For CD, it is essential for you to connect your ArgoCD instance by keying in the server URL. This requires a working understanding of ArgoCD and also a working setup of the same before even signing up to these DevOps platforms.
3. ArgoCD has to be defined as an artifact source and its specific steps must be added as deployment steps while configuring a pipeline. Other platforms require you to include steps or commands within the YAML files to interact with ArgoCD.
While GitOps automation can be achieved by integrating ArgoCD with DevOps platforms, it has to be noted that these are not native workflows. There will be challenges that crop up, like:
1. Improper synchronisation between repository and the deployment state on these platforms could result in unintended deployments or configuration drift.
2. GitOps practices, when coupled with certain platforms, may have limitations in handling multi-cloud or hybrid cloud deployments.
3. The complexity increases with the size of the infrastructure. The larger the number of clusters and environments the greater the number of pipelines and messier the orchestration.
4. The fact that ArgoCD needs to be set up and running before even subscribing to DevOps platforms defeats the purpose of having low-code/no-code DevOps.
The Rise of Tekton

As the industry looks for solutions to address the challenges posed by existing CI/CD frameworks, Tekton has emerged as a promising alternative. Prominent tech enthusiasts in the DevOps space, like CloudBees co-founder Sacha Labourey, and market momentum make it clear that there’s a significant number of organizations working on integrating Tekton within their platforms, just like we saw with ArgoCD a couple of years back.

What’s amazing is we already had platforms like Ozone, which started working on making Tekton enterprise-ready almost three years back and have further evolved over the years.

Tekton: Container-Native CI/CD

Tekton is a Kubernetes-native framework for building CI/CD systems. It provides custom resources to define CI/CD pipelines as code, allowing for greater flexibility and extensibility.

This is done by introducing the concept of tasks that run within a pipeline. These tasks are reusable and pre-defined, all of which can be viewed in the Tekton hub.

What ArgoCD achieves for GitOps is done with just one of the hundreds of task templates that Tekton comes with.

Too good to be true? Well, every rainbow has its rain! Migrating from one framework to another is a huge task, and that is precisely why many enterprises shy away from migration.

Can LLMs Help Automate the Migration of Existing Pipelines to Tekton?

If you look at the diagram below, the answer is a resounding yes. The model is trained based on existing pipelines and what their corresponding Tekton pipelines look like.

The overarching objective of this workflow is to facilitate a seamless conversion process using large language models (LLM) for generative AI.

Central to this approach is using the chat context and the strategic application of roles for LLM models to establish context. Additionally, sample pipelines are leveraged to train and fine-tune the model to define how the corresponding YAML files of all these platforms look for any given pipeline.

Here’s a more detailed read presented by Ozone as an industry-first last year at KubeCon North America.

Conclusion

The evolution of CI/CD frameworks reflects the DevOps industry’s dynamic nature and the demand for efficient software delivery pipelines. From Flux and Jenkins to ArgoCD and Tekton, each framework addresses deployment challenges.

ArgoCD gained traction based on its GitOps principles and Kubernetes integration, yet faces synchronization, multi-cloud support and scalability hurdles. Tekton, a Kubernetes-native CI/CD framework, offers scalability, event-driven architecture and cloud-native practices to make up for these shortcomings.

Whether embracing ArgoCD or exploring Tekton, the goal is resilient, scalable pipelines driving innovation and time-to-market acceleration.

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.
March 5, 2024
Best of 2023: Are We Witnessing the End of Open Source?

As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.

Hailed as a groundbreaking movement in software creation, open source software has become an indispensable pillar of modern software development. Often described as democratized technology, it has empowered countless individuals and organizations to collaborate and innovate. However, the community now stands at a critical juncture, and there’s some speculation that we’re seeing a decline in the open source space.

Why is Open Source so Popular in Modern Software Development?

At the heart of open source lies the power of collaboration. Unlike proprietary (closed source) software, open source invites participation from a diverse range of contributors, allowing them to work collectively to create and improve software. This inclusivity fosters shared knowledge and cooperation, leading to the creation of groundbreaking software.

In addition to collaboration, the open source development approach eliminates financial barriers and significantly enhances accessibility in software development. With open source software typically distributed under licenses that allow users to access, use, modify and distribute the software freely, this eliminates the need for costly licenses usually associated with proprietary software. This affordability allows organizations of all sizes to leverage innovative solutions without accruing high upfront costs.

Within the framework of open source software, transparency is ingrained. The accessibility of the source code makes it possible for users and contributors to scrutinize the source code, promoting trust and accountability. By promoting scrutiny and peer review, transparency ensures that flaws are quickly identified and addressed. It also empowers users to have greater control over their choices in technology.

With these benefits coupled with success stories from enormous projects like Linux, Apache and MySQL, open source positioned itself as having the potential to compete with proprietary alternatives, leading to widespread adoption across the technology industry.

More Projects are Jumping Ship

Given these numerous benefits, one might wonder: What challenges could arise with this approach? In recent years, there have been sentiments amongst contributors that the space might be losing steam. Their concerns are fueled by a few key factors that may erode or undermine the collaborative essence of the movement.

A huge factor is the commercialization of open source projects. A popular example of this phenomenon is the GitHub acquisition – GitHub, the home for open source projects for years, was acquired by the tech giant Microsoft in 2018. This news ruffled some feathers in the community, as Microsoft was seen as a proponent of proprietary software. It also raised doubts about whether GitHub would maintain autonomy over its decision-making process.

Regardless of these doubts, the community overcame the bump in the road rather quickly and continued contributing to the platform for years. However, in 2022, GitHub announced that a sub-program called Copilot, which open source developers had been working on, would emerge as a commercial product, with the profits going to GitHub itself. This development infuriated community developers, and they faced a rude awakening that any open source platform could decide to commercialize their projects without contributors sharing in the financial rewards or even gaining recognition for their work. Another open source project that has fallen victim to commercialization is OpenAI.

There have also been increasing concerns about whether open-sourcing core business models will cause more harm than good. Unlike in the past, it’s a lot easier for projects to become popular, creating a high possibility that someone else can steal the idea or offering and quickly create a commercial product based on the project.

These considerations are part of a broader discussion regarding the shifting dynamics and potential departure from the core principles within the community, causing participants to be uneasy.

The Dust Settles: Open Source Remains Strong

Despite the concerns and challenges facing the community, open source has undeniably transformed how we build and deploy software. We must approach the future of the movement with cautious optimism.

Drawing from past experiences like GitHub and OpenAI, it is clear that the community is resilient and adaptive. Contributors who do not agree with the acquisition of GitHub or the commercialization of OpenAI will take their gifts and contribute to projects whose values they agree with.

However, open source is at a crossroads and is grappling with challenges and changes that demand introspection. This introspection, hopefully, will lead to adjustments in the open source space that reaffirm its core principles and address concerns. Open source is not fizzling out, at least not yet; we can think of it as undergoing a transformative phase that will shape its future and ensure that it remains an important pillar in the software development landscape.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.

December 22, 2023
KubeCon: DevSecOps and Generative AI

Speaker 1: This is Techstrong TV.

Alan Shimel: Hi, everyone. Alan Shimel back here at Chicago KubeCon, North America 2023. If you’ve watched our coverage of past KubeCons or RSA or even sometimes on Techstrong TV, you know this fellow right here, he’s my friend, David DeSanto. David, is the… Is it Chief Product Officer?

David DeSanto: Chief Product Officer.

Alan Shimel: Yep, at GitLab. And GitLab always has something doing, especially if it’s the 22nd of the month, right?

David DeSanto: Correct.

Alan Shimel: How many consecutive 22nd of the month releases are we up to now? Do you know?

David DeSanto: Over 150. I know that.

Alan Shimel: Over 150.

David DeSanto: Yeah.

Alan Shimel: But GitLab is also a big community member of CNCF, as well as a bunch of the other Linux Foundation-

David DeSanto: Absolutely.

Alan Shimel: Foundations as well. And David’s always a wealth of information. So David, I hope I didn’t put too much pressure on you, but welcome.

David DeSanto: It’s fine. Thank you for having me.

Alan Shimel: Always a pleasure. So let’s first talk a little bit about the show.

David DeSanto: Yeah, absolutely.

Alan Shimel: GitLab is here. What are you seeing, hearing? What are you thinking about?

David DeSanto: Yeah, so I would say this probably is no surprise to everyone who’s watching, but this year it’s all about security and AI. And sure enough, at GitLab’s booth here, we’re booth M1, it’s also about…

Alan Shimel: Security and AI.

David DeSanto: Security, AI, and visibility.

Alan Shimel: So we’ve been talking a little bit about security and AI too. Surprise. And one of the… We actually, just a quick plug. We actually have a great virtual event coming up in December on AI, and it’s sort of where does AI meet, rubber meet the road. And I want to turn that around to you, David. Look, AI has tremendous potential to help, I think, with security.

David DeSanto: It does.

Alan Shimel: I don’t know how much of it is real today. I think a lot of it will be real, certainly. But what’s real today? No holds barred. What’s your take?

David DeSanto: Yeah, so maybe we’ll start with the AI part of that and then tie it into security. So I always look at new technology through the lens of my parents. They’re both much older than I am. And to them, when I showed them AI, it was magic because to them-

Alan Shimel: It really was.

David DeSanto: How is that happening, right? But then I also had to help ground that in reality for them to say, “Well, this is generative AI. It works by predicting the next word based off the series, right?”

Alan Shimel: Putting one foot in front of the other, right. It’s not sentient.

David DeSanto: When you look at it though, some people have thought it’s sentient.

Alan Shimel: No, your parents, I go by my wife’s sister, she’s 74, and yeah, she thought there was a little person in there, but yeah.

David DeSanto: Yeah, and actually just as a quick note, and the viewers will love this, but I introduced them to it at my sister’s wedding earlier this year. I needed to do a toast. So I had Bard generate the toast for me. And they were like, “How is this happening?” Right?

Alan Shimel: They’re beautiful, I hear you.

David DeSanto: But to kind of ground in reality and you realize how generative AI works, you have to then ask yourself what are the best use cases to apply it to? It’s not going to be able to tell you how many pages there are in a book, how many words are in a book. Those aren’t things that are questions it can build, right? But it can help you with tasks that can sometimes be mundane. It can help you with understanding something better. And that’s how I kind of tie it back to AI. So when GitLab started applying AI to our platform, we started in 2021 with code review because that was a huge pain point helping customers get through code review. The next area we looked at was actually security.

Alan Shimel: Really?

David DeSanto: And the reason why we did that is that GitLab is, in essence was a developer platform when we started, we’re an enterprise DevSecOps platform today.

But it was about helping developers be more effective. And developers don’t start their day off by saying, “You know what? I want to write a zero day vulnerability in the application today. I want to make it super vulnerable.” Right? They want to write really good code. And so we said, “We’ve helped shift security left. How do we help now those developers understand that security they’re seeing?” And so we launched at RSA this year, explained this vulnerability where it actually explains the vulnerability, natural language using AI gives them an example of how that vulnerability is exploitable. And it gives them an example of how to resolve it. And those code snippets it shows are in the language the developer’s writing it. And so when I think about AI and security, I think about it making security truly approachable. And if you can do that, then everyone starts to win.

Alan Shimel: So I would give you guys the Oscar for best use of AI, right? Because I think that’s where it shines. I had a very similar experience with me. So I’m not a coder.

David DeSanto: And I claim to be one, but it’s been a decade plus since I’ve run any code.

Alan Shimel: But you know what? Try putting a little code into your generative AI chatbot and say, “Explain this,” or, “What does this mean?” And it goes through line by line and tells you, “That’s what this is for. This is what it’s calling, this is what it’s doing.” And you can be a complete neophyte around let’s say Python or name your language, wherever you want to do it in. And it really teaches you how to code.

David DeSanto: It does. It does.

Alan Shimel: Line by line, syntax by syntax. So to me, that’s a great use of AI. That’s what we should be using it for. It’s not Google search. A lot of people I know, they think it’s Google. It’s not Google search.

David DeSanto: No.

Alan Shimel: But those kind, and it’s good for writing toasts for a best man or whatever, or an anniversary as someone in my office I know used it and his wife called him on it. But anyway, it’s really great for learning tool. Now, when we talk about AI and security, though, there’s an evil dark side to it.

David DeSanto: There is.

Alan Shimel: Which is how do you secure AI?

David DeSanto: Yeah. And so I love that question. So the first time we spoke, which now is four or five years ago, the question you asked me is, “GitLab and security, explain that.” And we talked about why we’re taking that journey. And today, GitLab is recognized as a security player in the space.

Alan Shimel: Absolutely.

David DeSanto: And it’s one of those things that we are very proud about because we helped define what shift left actually meant. And so if you bring this back to AI, the one thing I always tell people is that, yeah, code generation can be scary. You’re not sure, is it writing good code? Is it writing functional code? But if you’re using GitLab, that code gets committed back into your CICD pipeline and the GitLab security scanners run. And now you know that vulnerability has been resolved and nothing new has been introduced. And so if you pair AI with the right things around it, it can be truly powerful. But you’re right, if you’re not doing that and you’re thinking it is the person living inside the machine, you give a little too much trust to it today. AI is not a hundred percent there yet.

Alan Shimel: Absolutely. Well, so that’s the next segue. Don’t give up any secrets. Let’s not get in trouble. You’re a public company now, but where do you see AI going with GitLab specifically over the next, let’s say between now and RSA in May or something like that?

David DeSanto: Yeah, great question. So fortunately, we’re a very transparent company, so I can talk about roadmap and not get in trouble, but thank you for making sure that I don’t get myself in trouble with legal.

Alan Shimel: Or me.

David DeSanto: So where we see AI going with GitLab is there’s really two paths that we’re exploring. The first is GitLab Duo Chat. We released it back in June, it continues to mature. We’re seeing people gravitate towards wanting to talk to chat and not necessarily click a button in the UI or engage with AI that way. And it makes sense. If you think about it, we’re humans, you and I are talking, we’re having a conversation. That’s how we’d want to engage with it. And that’s why the chatbots are so popular.

And so what we’re looking to do is continue to take what we’ve released. We have 14 AI features today.

Alan Shimel: Really?

David DeSanto: Yeah. Everything from, GitLab is for the entire SDLC. So we have AI assistance in planning, coding, securing, deploying, the whole way across. And so we’re slowly moving those features into chat. An example that explained this vulnerability is a great example. So that’ll be available in chat here shortly. And the reason why we’re doing that is the natural thing is, “Well, help me resolve it. Here’s my code.” And so we want to help AI be not just a pair programmer for the developer, but be that trusted partner that can help write more secure codes. So I would say over the coming several months going into RSA, you’ll see a lot of AI and security and our Duo Chat feature coming together.

Alan Shimel: I love it.

David DeSanto: The other area is our-

Alan Shimel: Wait, hold on one second.

David DeSanto: Oh, sorry. Yeah, go ahead.

Alan Shimel: I want to make sure Duo Chat, not everyone out here is going to know Duo Chat.

David DeSanto: Yeah, so perfect. Yeah. So GitLab Duo is the name of our AI workflows within the GitLab platform.

Alan Shimel: Got it.

David DeSanto: The name is based off the fact that it’s you as a user, plus AI makes the AI dynamic duo.

Alan Shimel: A duo. Okay.

David DeSanto: It also helps that I’m a huge Batman fan and dynamic duo has that in it.

Alan Shimel: All right. I love it. I love it.

David DeSanto: I didn’t tell marketing that though.

Alan Shimel: No, no, no.

David DeSanto: No, no. No. Hopefully they don’t watch this. They’ll now know my secret.

Alan Shimel: What does marketing ever? I’m only kidding. I’m only kidding. I love my marketing people.

David DeSanto: So that’s the name of the suite of those AI workflows. And so there are things like explain this vulnerability. You’re explaining of codes for, we actually haven’t explained this code.

Alan Shimel: I love it.

David DeSanto: We’ll explain the code. We have our code suggestions, which is going to generate either code completion, your cursors in the file, it’s reading what’s before and after the file’s open and recommending code.

Alan Shimel: I love that.

David DeSanto: Or code generation where you can actually do comment decode, that’s actually the most popular for our users. As well as things in helping you do your planning, summarizing conversations, helping with CI configurations and beyond. So that’s what GitLab Duo is, and Duo Chat is part of that. And so that’s the chatbot you can launch within GitLab’s UI.

Alan Shimel: Now, is there a way to kind of implant this into your IDE, or?

David DeSanto: And that’s the last thing I was going to mention that we’re working on. Yeah. So the other thing-

Alan Shimel: You didn’t pay me to say that.

David DeSanto: I did not.

Alan Shimel: Okay.

David DeSanto: I did not.

Alan Shimel: Go ahead.

David DeSanto: It’s almost like you read our GitLab issues and read our roadmap.

Alan Shimel: We may not coordinate our wardrobes. But we do-

David DeSanto: We didn’t. I do wish I would’ve worn the fall shirt today.

Alan Shimel: Next time.

David DeSanto: We will. Next time we’ll do that.

Alan Shimel: All right.

David DeSanto: But anyway, we’re going to be bringing Duo Chat to the IDEs. So today we have it as an experimental feature and we’re trying it at GitLab today to make sure it works. But it’ll be available in all the IDEs that we support today, including the JetBrains Suite, Visual Studio, VS Code, Neovim, and the GitLab IDE.

Alan Shimel: I love it. I love that. Fantastic.

David DeSanto: But by the way, that’ll also then bring those same actions that are in the GitLab UI into chat in your IDE, so you can actually explain the vulnerability, explain the code, all those things directly where you’re working. You don’t have to leave your IDE to get that.

Alan Shimel: While we’re on this subject. A lot of people out here, look, there’s so much, there’s so much controversy around AI. Is it going to kill off humanity? Is it going to take everyone’s jobs away? Is it going… My feeling is, it’s not… Will it do some jobs? Yeah, but for the most part, it’s going to make a lot of people who do these jobs 10x more effective. How do you view it, and how does GitLab view this, in a world where chat and Duo Chat is built in and AI is built into the entire GitLab SDLC pipeline.

David DeSanto: Yeah.

Alan Shimel: Does it really 10x these people?

David DeSanto: So that’s our target. And to give a little context for everyone, GitLab Ultimate, which is our top tier, includes every future GitLab has including AI. We did a survey of our customers. We had an independent company do that. They found that people using GitLab Ultimate get a 7x boost in efficiency for their organization.

Alan Shimel: So you’re over halfway there.

David DeSanto: Yeah. And an ROI within six months of what they paid for it. And so when we asked ourselves, “How does AI help?” We set ourselves a 10x goal. So continuing to accelerate that efficiency. And our customers using GitLab today and GitLab Duo are talking about that. They’re talking about getting through code review faster. They’re talking about resolving vulnerabilities faster. And to the first part of your comment, we don’t see AI as a replacement for your team members. We see it as helping them be more effective, removing some of the mundane tasks that can slow them down and unlocking their true potential.

Imagine a world where your developers don’t have to worry about doing things like creating the template for the code and now they can just go in and write the actual strategic parts. And same thing across the entire software development lifecycle. I personally benefit from Duo almost on a daily basis, in that as the CPO of the company, I get pinged on our GitLab issues or GitLab Epic or whatever, and someone will say, “What are your thoughts on this?” And I’ll look at it and I go, “How long is this?” And I’ll go up and say, “PDF it.” And it’s like it’s a hundred pages, the issue’s been open eight months.

Alan Shimel: Summarize.

David DeSanto: Customers are coming, yeah. So I say-

Alan Shimel: I do the same thing.

David DeSanto: “Summarize the discussion,” right?

Alan Shimel: We’re connected. I do the same thing.

David DeSanto: And so that’s where I see it. That made me more efficient. I now didn’t spend two hours doing that.

Alan Shimel: I’m doing the same exact… As CEO at Techstrong, I’m inundated. Inundated with content. “Should we publish this? Is this the right tone? Here’s the abstracts.” And a lot of times, and I don’t mean to sound callous, but I just don’t have the time to go through it all. But a summary, man, just give it to me in five bullets.

David DeSanto: Right. And by the way, the other part of that that I use is that it could also help generate descriptions and tasks. And so-

Alan Shimel: A bot.

David DeSanto: Right? So I’ll just say, “I read all that. I have an action, remind me to do this. Help me create the task for it,” and so forth. But you are the great example, right? Same thing with the developer, a security person. There are other things that your brainpower should be used for and why spend the time doing those things that-

Alan Shimel: I agree.

David DeSanto: Truly are not moving Techstrong forward or that company’s application for it.

Alan Shimel: We’ll come up with a, we have a theme for given event, a virtual or in-person event. We need the abstract. I can have other people write the abstract, but it doesn’t really capture my vision for it. I find just putting that into bot, into a chat, it nails it. But here’s another thing that I think is, and again, for those of you out there who don’t use generative AI yet, you should. Don’t be afraid to give it a nice long prompt or give it a lot of back. Because the more info you give it, the better it kicks back to you.

David DeSanto: It does. It actually goes off feedback and you can like something or thumbs it down.

Alan Shimel: That was another kind of revelation. And I think it’d probably work the same way with code.

David DeSanto: It actually does. So the backend of GitLab Duo is monitoring for the amount of code you keep. So do you accept the recommendation? Do you not? It also measures retention. So is that code still there after you move on? And same thing with the chat. So I’ve actually had to say to it, and there’s a joke on the internet about you have to be polite back to the chatbot. I actually just recommend it because I’ve seen that documentary Terminator with Skynet. I’m just afraid-

Alan Shimel: One day they might come for you.

David DeSanto: You want to suck up to them now, so when they take over, they remember you.

Alan Shimel: They’ll remember it.

David DeSanto: But no, I’ll actually say back, “That’s interesting, but have you thought about this? And here’s why.” And then I see that it actually learns from it because we constantly fine tune models based off that feedback. Right?

Alan Shimel: I agree.

David DeSanto: So, absolutely. Please be kind to the chatbots. GitLab Duo will always be chat to you.

Alan Shimel: Be kind to your chatbots. And be kind to everyone else, right?

David DeSanto: If it is-

Alan Shimel: Especially in this day with everything in our world going on.

David DeSanto: If it’s anything, you should be polite. There you go.

Alan Shimel: If you can be anything, be polite. Non-AI stuff, what’s your impressions of the show this year?

David DeSanto: I’ve enjoyed it so far. RSA conference used to be my favorite conference to go to. I think KubeCon is now tied for first and might sometimes edge it out. And the main reason why is that here is one of the few times I feel like it reminds me of the Black Hat Conference back in the day.

Alan Shimel: Back in the day.

David DeSanto: You’ve got all the, it is not meant to sound negative, but the doers here, right?

Alan Shimel: Yeah.

David DeSanto: You’re having real conversations with developers who are trying to understand operations better, security professionals who are here trying to make sure they’re supporting developers’, operations. Same thing with operations. So you get this really good mix of people and it just reminds me of almost like a large startup, if that’s a good way to look at it.

Alan Shimel: Yeah, no, there’s an energy that’s palpable, that I think works.

David DeSanto: But I do want to just make sure RSA, I still love you.

Alan Shimel: We’ll be there, May 6th-

David DeSanto: I’ll be there as well.

Alan Shimel: Is our DevSecOps. It’s going to be all about AI in the future of security, our event as well as the larger AI event all week. Or the larger RSA event all week. What about re:Invent? You guys are going to be at re:Invent?

David DeSanto: We will be at re:Invent. I will personally not be there.

Alan Shimel: No?

David DeSanto: No. I actually, I hit the point where this is my last whole week of the year. I’ve been gone three weeks a month for this entire year. I want to stay married.

Alan Shimel: I hear you.

David DeSanto: I want to spend some time with my dogs. And so I’m taking December and most of January off from travel.

Alan Shimel: Good for you.

David DeSanto: Yeah.

Alan Shimel: I’m getting a new dog Friday.

David DeSanto: What kind of dog are you getting?

Alan Shimel: I guess I could share it. So we’ve had bulldogs for about almost 30 years.

David DeSanto: Okay.

Alan Shimel: Our last one passed away in May. She was 14 and a half.

David DeSanto: Actually, I think you and I talked about that.

Alan Shimel: Yeah. So it took a little while for us to get back in the, I need a dog, but I need a dog. So it’s a new bulldog puppy. Her name is Kaia, K-A-I-A, which means sea in Hawaiian. Her father’s name is Ocean.

David DeSanto: Oh, wow.

Alan Shimel: And yeah, I’ll post pictures.

David DeSanto: Okay. I think I’ve shared this to you before, but we have two rescues. They’re both Chihuahua mixes.

Alan Shimel: Oh, yeah. Yeah.

David DeSanto: One’s really dumb and the other one’s really smart, so [inaudible 00:18:47].

Alan Shimel: It’s good mix. Yeah.

David DeSanto: I will tell you, when I get home, they’re so excited to see me and they get really sad when I’m packing, so.

Alan Shimel: There’s nothing like the love of a dog.

David DeSanto: I completely agree.

Alan Shimel: No doubt.

David DeSanto: But about the conference.

Alan Shimel: Yeah, we went off there, but go ahead.

David DeSanto: Completely derailed us.

Alan Shimel: Yes.

David DeSanto: So for GitLab, a couple things. So if people are watching and they’re here, they want to see it. If not, check it out after the conference on our website. We brought our product analytics feature to market. We already have some customers adopting it and we’re demoing it. And I wanted to share it here because KubeCon’s also about visibility and you can’t close the SDLC without user feedback. And so similar to how we have observability, just about the application running in production, the value stream analytics and value stream management. This is now user feedback. So as part of GitLab CICD, we can embed telemetry into the application. So when it’s deployed, it can connect back to GitLab and start giving you data about your monthly active, daily active usage, the return rate of those users.

Alan Shimel: This is available now?

David DeSanto: It is available now.

Alan Shimel: Or you’re just demoing?

David DeSanto: No, it’s available. It is available.

Alan Shimel: What do you call that?

David DeSanto: Well, we love our boring names at GitLab, it’s one of our values. So it’s just called GitLab Analytics.

Alan Shimel: GitLab Analytics. Okay.

David DeSanto: Yeah, GitLab Product Analytics to be specific.

Alan Shimel: All right.

David DeSanto: But yeah, we started using it earlier this year for our handbook and we’re able to learn about how our users use the handbook, our employees and team members. And so I’m excited how make this available because other people want to understand how their apps are being used. Long term, we’ll be able to pull in things like retention rate, user adoption journey metrics. But today it’s just those raw metrics like the active usage, return rate, the graphs of how the usage is going. But we’re very excited to be demoing it here. It’s really cool.

Alan Shimel: Absolutely. Very cool. GitLab user analytics.

David DeSanto: Yep.

Alan Shimel: David, it’s always a pleasure, my friend.

David DeSanto: Love our chats.

Alan Shimel: You know what? I spoke to you. We’re going to do another chat with David before you leave for two months with the dogs.

David DeSanto: Yeah. I will be working, for everyone. I’m not taking time, I’m just staying home. I’ll be-

Alan Shimel: Okay. You’re just not on the road.

David DeSanto: Yeah, I’ll be working from home that entire time.

Alan Shimel: I was going to say that’s a lot of vacation time.

David DeSanto: No, no, no. I did have my first big vacation since the pandemic though.

Alan Shimel: Really?

David DeSanto: Yeah, we went to Bar Harbor for two weeks and hiked Acadia National Park.

Alan Shimel: Oh, that’s beautiful.

David DeSanto: Yeah.

Alan Shimel: And when was this?

David DeSanto: End of August. Last two weeks of August.

Alan Shimel: Oh, so it’s still nice there.

David DeSanto: It was very beautiful, but-

Alan Shimel: Not really peak color season there yet. But beautiful time, summer.

David DeSanto: But we’ll definitely can connect because I’m working. I’m just not on the road.

Alan Shimel: But we’re going to have you on Techstrong TV because you guys have more news.

David DeSanto: We do.

Alan Shimel: That we can’t talk about yet.

David DeSanto: Yeah, that’s a good teaser. Everyone tune in.

Alan Shimel: That was my, that’s what we call it.

David DeSanto: For the big news. It’s the hook.

Alan Shimel: That’s what we call it in the industry. My hook.

David DeSanto: Going back to our marketing friends. That’s the hook.

Alan Shimel: All right. Hey, we better take a break here. We’re getting a little loony. We’ll be back. We’re live in Chicago at KubeCon with our friends at GitLab. We’ll be right back.

December 19, 2023
KubeCon 2023: Elevating Observability

Speaker 1: This is Techstrong TV.

Alan Shimel: Hey everyone. We’re live back here at KubeCon. I hope you’ve been enjoying our coverage today, Mitchell Ashley, our CTO and a GM of Techstrong Research. And I have been kind of splitting the duties. Just we’re that booked with people. I don’t know, there’s over 10,000 people here. I’m going to guess there’s 12 to 15,000 people.

Alex Burkhardt: Yeah, there’s a lot of people.

Alan Shimel: … At the event. Maybe more I’ll know more. I’ll find out tonight. But anyway, let me introduce you to our next guest. His name is Alex Burkart. Alex is with Observe Inc. Alex, welcome to Techstrong TV. Thanks for being here with us at KubeCon.

Alex Burkhardt: Yeah, thanks Alan. I appreciate you guys taking some time to talk to me today.

Alan Shimel: Absolutely. So let’s start with this. Let’s start with Alex.

Alex Burkhardt: Yeah.

Alan Shimel: What do you do at Observe?

Alex Burkhardt: Yeah, so at Observe I run our technical customer facing team. We call it field engineering. And we work with customers from the first interaction when they’re in the sales cycle to figure out if observes a great solution for them, all the way to success and renewal and helping them realize value from their investment in our partnership.

Alan Shimel: Okay. I mean, so you’re at that role, but let’s tell a little bit about more your personal journey.

Alex Burkhardt: Oh yeah. So I started as a computer scientist actually in the Navy.

Alan Shimel: Really?

Alex Burkhardt: Yeah. I went to the Naval Academy, got a computer science degree, and they said, that’s great, go drive some ships.

Alan Shimel: Such is life in the Navy, what do you expect?

Alex Burkhardt: And then my journey brought me to Silicon Valley after I did some cybersecurity work for the Navy. And what I love more importantly than anything else is helping people find a way to use technology to solve a problem that makes their life better.

Alan Shimel: Excellent. Now, when did you come to Observe?

Alex Burkhardt: I’ve been at Observe for more than three years now. Yeah, I was employee 28. I think if my numbers are right, pre customers, in fact.

Alan Shimel: Really early.

Alex Burkhardt: I think when I started, we signed our first customer.

Alan Shimel: Good for, good for you. Good for them. So we don’t have to assume, I know for a fact there are people out here who don’t know, Observe from, have never observed Observe. Tell them. How would you describe what Observe is and does to our audience?

Alex Burkhardt: That’s a great question, Alan. So at Observe, what we realized is observability is a data problem. So we started by building a data company. What we wanted to figure out is can we bring a solution to market that allows customers to send any data they’d like to correlate it and interact with it in a way that allows them to get more value out of it more quickly. And what we’ve done is we’ve brought a solution to market that unifies the observability tooling into one platform that allows you to send logs, metrics, traces, and any other type of data structure or unstructured that you’d like to keep in your observable universe into one tool, one data store.

Alan Shimel: Love it. And before we jump into news and stuff, for people who want to just say, hey, I’d like to just see what their website is, what’s the URL?

Alex Burkhardt: Yeah, our website is www.observeinc.com.

Alan Shimel: So it’s observeinc.com.

Alex Burkhardt: Observeinc.com. We are Observe Inc technically. So observeinc.com.

Alan Shimel: Makes sense to me. All right, we’ve got all that out of the way, Alex, let’s jump in. Now, you guys recently announced some new product feature releases. Why don’t we jump in right there and see what’s that about?

Alex Burkhardt: Our last release was called Hubble, and Hubble is significant for a couple of reasons. One, naming after the Telescope, one of the things that we want to do is help people elevate their observability. And that came in two specific forms.

Alan Shimel: I get it. I just got to ask, is the next release called Web?

Alex Burkhardt: We have considered other satellites, and in fact, we had Erica on our launch. She was actually a NASA scientist.

Alan Shimel: Very cool. All right.

Alex Burkhardt: One of the things that we know is very important to our customers is if we bring a solution to market and it’s very, very powerful, is it easy to use and are we taking advantage of the latest and greatest technology that’s emerging in the market? On the ease of use side, one of the things that this Hubble launch and we did, we call it a launch included, was the recognition that when we introduced our logs in our metrics and our tracing explorer, we’ve seen an enormous increase in users engaging in the platform. And we supercharge that by adding one additional layer, which is how we leverage GPT or AI in our platform. And that happens in four specific locations. We have a chat bot that allows you to get guidance on how to use the tool, will actually allow the AI to write any of our query language for you if you’d like to do that. We call that copilot.

We also have two cool functionalities in terms of making your data more actionable. You can click on a field and observe and ask Ollie or Ollie GPT specifically to explain what an error means and it will actually return an answer that helps you stop having to copy and paste into Google and do outside investigations. The last thing that’s most interesting is we leverage GPT to allow users to separate out their data and do those hard parsing and Reg X challenges that no one likes writing Reg Xs and anyone that has written them knows that regx101.com is their friend, and we wanted to kind of bring that into the product and make that easy for customers to use.

Alan Shimel: Very cool. Very cool. Now this was released not here at the show, it was released earlier in the month.

Alex Burkhardt: October 4th.

Alan Shimel: What’s been the feedback?

Alex Burkhardt: Well, we’ve more than doubled our monthly active users since we’ve released that.

Alan Shimel: Really?

Alex Burkhardt: Yeah.

Alan Shimel: Since October 4th?

Alex Burkhardt: Technically since late September. But yes.

Alan Shimel: Wow.

Alex Burkhardt: It’s really simple. We listen to our customers and we really care about what they say and how they experience ourselves on our platform. And when we say we’re focusing on ease of use, we mean it.

Alan Shimel: So the entrepreneur in me just has to ask you.

Alex Burkhardt: Okay.

Alan Shimel: What were you waiting for?

Alex Burkhardt: It’s very easy to make very quick, bad decisions. It’s a lot harder to take a data-driven approach to how to build a product better. And when we approach any problem at Observe, and it’s built into our culture as we first of all figure out this is an important problem, how can I measure the impact I can make on this problem? And that’s how we measured usability. Now for AI, we kind of knew that it was going to be something special and it could help. We’re still figuring out exactly how to measure the impact there, but every decision we make at Observe is grounded in what’s best for our customers and how do we help make the market better.

Alan Shimel: So how much of this phenomenal growth in such a short period of time do you think is just attributed to riding the AI wave, if you will?

Alex Burkhardt: That increase in active user growth actually wasn’t tied to the AI release. It was more to the ease of use functionality that we brought. And I think that’s important for any product, but more specifically, one as powerful as ours. When you’re solving big data problems, people get exposed to big data. And one of the things we thought very deeply about is how do we take the experience that a user has to have to get to the outcome they want and narrow that down and give them an obvious path to go through so that they don’t have to deal with all of the problems if they just want to come in and check their logs and see what’s not working. Sometimes it’s the simplest question of, hey, is it easy to do this in the tool? And when we decided ourselves that it wasn’t easy enough, then we started making some really serious changes and that was backed by every single one of our customers agreeing with us back in the active user growth.

Alan Shimel: Sure. That’s fine. That’s phenomenal, man. Alex, I can’t look for those out here. This is impressive. Let’s talk a little bit about KubeCon here now. I mean, it’s only day one of the expo floor open and everything. What are you hearing from the crowd, from the attendees?

Alex Burkhardt: Yeah, that’s a great question. This is my second KubeCon. I was new to it last year when we were in Detroit, and I really love this conference, Alan.

Alan Shimel: Yeah, it’s great. It’s a great community.

Alex Burkhardt: It’s a great community. It’s a great conference. And frankly, when people come up to our booth and want to talk to us, they want to talk about what we do. There’s not a lot of tire kickers. Everyone that’s here seems to be operators, people that are experienced and steepen the problem. And I love whenever someone comes up and talks to us. I think the other thing I’ve seen in this particular venue specifically, the room is packed. It’s crowded, so crowded that I think that we’re going to have to have a bigger footprint next year.

Alan Shimel: Observers or the whole?

Alex Burkhardt: Both.

Alan Shimel: Yeah. Well, the problem is there’s a pretty big convention center. I mean, short of breaking into sort of a two different exhibit halls, which RSA used to do that. Now it’s one big continuous one. It’s hard. The other thing I will tell you, so we do the North American and the European. So in Amsterdam in the spring, they actually said, look, I think it was 12,000 was the number. At 12,000 they stopped selling tickets. They did a waiting list and a lot of people didn’t get to the show. They were on the waiting list. As anti-business as that sounds, I wouldn’t be surprised if they did something similar.

Alex Burkhardt: Yeah, that makes sense. I mean, the quality of conversations and the quality of attendee keep the quality super high. And you asked about some of the conversations we’re having when people come by. It’s a variety of things and a couple of themes that I see. I’m curious if other people that have come on the show have said the same, but people continue to talk to us about saving money. They want to do more with less.

Alan Shimel: That’s the big thing today.

Alex Burkhardt: [inaudible 00:09:23].

And I think they also want to figure out, do we need all of the tools? Is there a way we can both get some hard dollar savings and some soft dollar savings. By compressing some tooling and aligning teams we’re also seeing a lot of push and the DevOps teams are getting more involved in security conversations as well. Which I guess-

Alan Shimel: No, no, that there’s no doubt.

Alex Burkhardt: As a former security practitioner, if you had asked me five years ago if I thought these two markets would converge, I would not have said yes. Now I think it’s inevitable.

Alan Shimel: I think it’s already happened, right? So there’s a lot of convergence going on. There’s security with DevOps into what we call DevSecOps. But there’s also, there was a time, and I’ve been going to these conferences now before Covid, so I don’t know, four or five years. There was a time where cloud native was very developer-centric, not as much centric, but it was very distinct from DevOps. There was DevOps and there was cloud native and then there was security. So you look at a company like ours, right? We have devopsy.kinsta.cloud, cloud native now, security boulevard.

And I always knew there was an inherent overlap between them, but we’ve seen much more than an overlap now. We’ve seen a conversion around this with security being a primary concern of people. And you don’t do cloud native today without doing DevOps.

Alex Burkhardt: Agreed.

Alan Shimel: And everything getting pushed out today, especially Greenfield, not Brownfield stuff. It’s predominantly probably 85% or better cloud native.

Alex Burkhardt: Yeah, I think that’s another thing I’ve seen too as well. Many, many customers are adopting the cloud native terminology, setting goals in those languages and words.

Alan Shimel: Now, multi-threaded, no doubt. Container based, the whole cloud native thing. And now what I think we’re starting to see and we see, look, you’re naming your company’s Observe. It’s not just the architecture and development being cloud native, but the cloud native aspect of the operations of ops. Forget dev, forget dev ops, ops.

Alex Burkhardt: It even touches revenue. So one of the things that we see very often is do the nature of how our platform can process data. We take technical telemetry from a customer’s application. We also take business data. Sometimes customers ask us, how can you Observe, help us give our customers a better experience? Well, one of the ways is we can tell you when a particular customer is hurting, when a customer has a challenge or help you reframe all these very deep technical jargon and things that are happening into the context of how does this impact the customer’s experience? How am I able to get proactive? Is what I’m doing in my infrastructure plan having a net positive impact on my customers, on my users?

And those are questions that previously companies I don’t think they thought they could answer. And when they start working with us, they start seeing a path to that. And I love that. We have some customers even completely away from the DevOps side, that send us shipping data just because they want to know, can I make a support dashboard for my low level support employees so that they can be more efficient with their time and our data? It’s such a cool convergence. I agree with you. I love that word convergence.

Alan Shimel: It really is. Let’s talk a little bit about observability though too. So over the last two years, so there was a KubeCon in LA during around Covid time that was a little dicey. Then there was the one in Europe, then got canceled. Then there was Detroit, then Amsterdam here. We’ve really seen the observability market just explode, right?

Alex Burkhardt: Yeah.

Alan Shimel: Prometheus. What’s the other, I’m drawing a blank. The other big observability open source. OpenTelemetry.

Alex Burkhardt: OpenTelemetry. Yes. Everyone-

Alan Shimel: I think of the second and third biggest projects of the gazillion projects in CNCF now. Right?

Alex Burkhardt: That’s such a good point. I remember when OpenTelemetry was OpenTracing and it was still kind of a fractured project. If you asked us three years ago if we thought that open telemetry would be the way, we weren’t super sure a year into that. So two years ago we were like, yeah, this is the direction. It’s solid.

Alan Shimel: No doubt about it. You look and you can’t see this at home guys because all you’re seeing is here, but there’s a-

Alex Burkhardt: All our beautiful faces.

Alan Shimel: … Big floor out there, but so much of it is based now on this. Really good stuff, really good stuff.

Alex Burkhardt: I think the other thing, observability as a vernacular is kind of emerging even at the higher level in the business. By definition observability is, can I tell something about a system by looking at its outputs? And one of the things as we’re moving closer to cloud native is more and more systems have outputs and that kind of builds on that data problem I mentioned and why we were founded. So I look forward to seeing how this problem space changes in the next year.

Alan Shimel: Oh, I think we’re just, look, when you start, you guys are already doing it with gen AI and stuff. You start adding gen AI to this stuff, we start putting more focus on it. We’re in for an interesting times. What’s the Irish proverb? May you live in interesting times.

Alex Burkhardt: Yes.

Alan Shimel: Definitely interesting times. Anyway, Alex, thanks for joining us here live at KubeCon. This is Observe Inc. So let me again observeinc.com. Check it out. Hey, they’re doing amazing things. This new release, something that gets twice as many new visitors right? In a couple of weeks, a month. It’s got to doing something right.

Alex Burkhardt: Yeah.

Alan Shimel: All right, we’re going to take a break. We’re live at KubeCon in Chicago. I think we have one or two more videos before we wrap for today. We’ll be right back.

December 18, 2023
KubeCon 2023: Telemetry and Data Management

Speaker 1: This is Techstrong TV.

Alan Shimel: Hey everyone. We’re back here at KubeCon and it’s bustling, man. It’s a crazy big floor with a lot of people walking around, so we hope you like this. This is a little different than we usually do. Usually people can’t see the background because the cameras face this way, but we usually have sort of the typical background that you see at some of these other booths. But we wanted to give people kind of a flavor that we’re alive here.

Tucker Callaway: We’re in the middle of it.

Alan Shimel: We’re in the middle of it. So kind of like if you ever watch Sunday night football, they always have that. So that’s what we were shooting for. But anyway, let me introduce you to Tucker Callaway. Tucker is the CEO of a company called Mezmo. Now, some of you may have heard of, I think it was Log DNA.

Tucker Callaway: Before. Yep.

Alan Shimel: And they pivoted. Was it about four years ago?

Tucker Callaway: About two years ago now.

Alan Shimel: Two years ago.

Tucker Callaway: I’ve been here for four, but big change was two years ago, renamed.

Alan Shimel: Renamed to be Mezmo and a slightly different mission, let’s call it. And then I had a chance to catch up with Tucker at RSA last, I guess it was last April.

Tucker Callaway: April. Yeah.

Alan Shimel: This year it’s May. So I think it was around then last year. And for those of you who want to catch that interview, it’s actually available on Techstrong TV. If you look up RSA 2023, it’s there. But so Tucker, before we get into that, let’s back up. Mezmo. Not everyone out here. Look, not everyone out here knew Log DNA either, so don’t worry about it.

Tucker Callaway: Fair enough. Yeah.

Alan Shimel: Let’s start there. Let’s talk about the mission.

Tucker Callaway: Yeah, so the mission of Mezmo is essentially to help people with their telemetry data. So we’ve found that there’s really kind of three main problems in the telemetry data space. There’s too much of telemetry data. It’s not in the right format. It’s not in the right location. So that was kind of one of our founding kind of principles of solving.

Alan Shimel: Yeah, I think that.

Tucker Callaway: Solving the problem.

Alan Shimel: Those were three rock solid.

Tucker Callaway: Hard to debate.

Alan Shimel: Hard to debate. That’s the good way of putting that. And also, quite frankly, all three problems are like they compound each other.

Tucker Callaway: They do.

Alan Shimel: So it’s like you have too much data. That’s a big problem, but we have too much data that we don’t know how to categorize, so that exponentially makes that problem worse. So these are-

Tucker Callaway: Compounding problems. No question about it.

Alan Shimel: No doubt about it. So when we were at RSA, you felt like you were kind of on the cusp of a realization, right? You were going to help customers. Why don’t you? Well, you tell the story better than me.

Tucker Callaway: So as we were talking about earlier, we had just launched this new product capability, the telemetry pipeline at RSA. We’ve got a lot of great customers and great experience since then. When we think about the core value of what it provides, it helps people with cost, it helps people get better insights and helps people enforce compliance. What we were surprised by though in the last couple months, is how little people actually understand of their data.

In fact, we’ve put a lot of time and effort as an industry into getting control of our applications and getting control of our infrastructure, but we haven’t really gotten control of our telemetry data yet, and that’s like the big opportunity that we see. But with that, in order to get that value I described, people didn’t need to understand their data better. And so that was a big revelation for us.

And we just launched our data profiling capability that helps people categorize and understand baseline, to do the schema management for their data, which is a really strong foundation for data ops principles applied to telemetry data. Then the next thing we found after we solved that problem was now that people understood their data and they were able to optimize it because they understood it. They also realized that the context and telemetry data changes rapidly. So for example, you don’t want to store all this data because you don’t need it until you need it, and then you really need it.

Alan Shimel: I’ll take a little, they do want to store the data because people are data hoarders.

Tucker Callaway: The data hoarder. Yeah.

Alan Shimel: It’s when they get hit with the bill for storing all that data, they say, “Wait a second, I don’t need all this data. Not at that price.”

Tucker Callaway: Something has to give somewhere.

Alan Shimel: Exactly.

Tucker Callaway: And so what we realized though was if you take the bookend of this value, we think of as understand, optimize and respond, we talked about understand and optimize the response stage was a really important one for us. So when new context comes in, the pipeline can change its behavior and change its optimizations to account for the current flow of data and the current needs. So if you’re sampling down to 20% and you see an event, you see performance, you can rehydrate, reprocess, dynamically change the responsiveness of the pipeline and get all the data to the right location for the right people, which helps address the cost problem, but also gives you the full visibility that you need.

Alan Shimel: If one was going to do a business school case study on this, someone who’s not from this industry would say, “Hey, just the fact that you discovered that most of these organizations don’t even know how much data or what data they have would be enough to build a company around.”

Tucker Callaway: Yeah, I’d like to think so.

Alan Shimel: No, it’s logical. It makes sense, but it’s not, it’s the threshold. Because I think you’d hit the nail on the head here, Tucker, which is once they recognize that, now there’s a whole new vista of realization for them of, “Holy mackerel, I got all this data, now I want to start understanding it. Wow. I’m seeing stuff I never thought I’d see. Maybe I intuitively thought I had, but I got the goods now.”

Tucker Callaway: We like to think of that as being mesmerizing, right?

Alan Shimel: Okay, I love it. Mesmerized by Mezmo.

Tucker Callaway: I couldn’t not take the shot, but that was just-

Alan Shimel: Yeah, that was your shot.

Tucker Callaway: That’s the derivative of the name.

Alan Shimel: I feel used. I feel used.

Tucker Callaway: I got back into it a little bit.

Alan Shimel: So now you’re mesmerized and now like, “Oh my God, what can I do with this?” And that really becomes the business. And I guess that’s now where you are.

Tucker Callaway: The next step for us is clearly that. Yeah, and I think there’s two plays on that, too. There’s a, “What do I do with it? Help me, tell me what to do. Give me the best practices that from all of your customers, what should I do?” And so we’ll be coming out probably later in the spring with something that actually allows you to simulate how that data might look when optimization’s applied to it so you can start to make those decisions more effectively.

But then the second phase of that, too, is that also won’t be sufficient for certain organizations that want to look at their data as a strategic advantage. And they’re going to be looking for ways to take actions and drive more insights out of that data. And so the way we see that, we see that through recipes. We’ll give you the standard offerings, but then you have the ability to go in and edit as code and go do the things you need to do to go drive more value out of that data. If you’re ready for advanced yoga moves in the data space.

Alan Shimel: Got it, got it, got it. My background is security.

Tucker Callaway: Yep.

Alan Shimel: Started a security company in 2001, and it was right when we were moving from IDS to IPS. So intrusion detection to intrusion prevention. Same thing with vulnerability management. We were moving from just finding vulnerabilities to patching, remediating, not always patching, remediating. Seemed like who wouldn’t want that? No brainer, right? Just don’t tell me I’m getting attacked. Block the thing. By the time you tell me, the attack went through. Don’t just tell me you found a vulnerability, make sure I’m not getting exploited. But a funny thing that I learned in that was a lot of people say, “Go slow here. I can’t afford, because sometimes the vulnerability or the attack or the data that you want me to act on can affect something that I consider more valuable.”

Tucker Callaway: Yeah, fair enough.

Alan Shimel: And I like to go slow when it comes to letting a program or an application or a product, just do things. Just give me my menu and I’ll decide what I want to do. Now, of course, that was before the world of AI and ML and a lot of the automations. And quite frankly, the speed of business was probably a little slower then. Do you see a way station where people are going to want that? Just give me best practices and I’ll decide when, how, and where I want to implement it. Or do we move right to, “Hey man, make it happen for me.”

Tucker Callaway: I think there’s a way station, when we think about the data management, telemetry, data management in general, the word that’s the most important to us is trust, right? So it is one thing to optimize the data, but you have to trust that data is constantly being optimized and handled in the right way for all those varying needs you described.

So I do see that the first step is a suggestion with a human in the loop. You want to hit that button still to say “go”, and then as you build trust in that data and you know that the algorithms are working, then you’ll let that go. Probably with some backstops on the side, I’m going to let it go, but I’m [inaudible 00:09:52] just in case. And then you’ll start to optimize it more and more. And I think naturally, almost like a realtime data platform, operating system will start to evolve.

Alan Shimel: So really the key there is trust.

Tucker Callaway: Key is trust.

Alan Shimel: To build trust in the next. So as the CEO, how do you build that trust?

Tucker Callaway: Well, trust is always a tough.

Alan Shimel: I’m interested, you tell me.

Tucker Callaway: Yeah. I think like anything else in life, you deliver trust through consistent delivery. And so that’s where I think that human in the loop step is important. It has to be sustaining. It can’t be a moment in time, it can’t be the very first implementation. It’s something that you earn over time where people can count on you or could count on the data or count on the ways that you treat data to get you to the outcome that you want to go through. So it’s really only through the delivery of outcomes to the customer that they will trust the systems and all those things.

Alan Shimel: Makes sense?

Tucker Callaway: Yeah.

Alan Shimel: All right. Got to do a little housekeeping.

Tucker Callaway: Okay, let’s do it.

Alan Shimel: People who want to know more about Mezmo.

Tucker Callaway: Come to the website. We’ve got an offer out there to profile anyone’s data for free right now.

Alan Shimel: Do you really?

Tucker Callaway: Yeah. Come to mezmo.com or stop by our booth.

Alan Shimel: M-E-Z-M-O.com.

Tucker Callaway: M-E-Z-M-O.com

Alan Shimel: Out there in TV land or if you hear a coupon.

Tucker Callaway: Come by the booth. I forget the number, but it’s over there.

Alan Shimel: You know what, if you look on the, I don’t have it. If you look on the back of your ID thing, you could actually look stuff up like that.

Tucker Callaway: Yeah, it’s back there. If you connected to the wifi here at KubeCon, it’s Mezmo Data.

Alan Shimel: I’ve noticed that.

Tucker Callaway: Is the wifi.

Alan Shimel: I was like, “Wow, what a cool thing.” Yeah.

Tucker Callaway: You have see us. Come see us. Profile your data will give you insight and understanding into that and talk to you about the next steps.

Alan Shimel: All right, check it out at Mezmo. Tucker, thanks.

Tucker Callaway: Thanks for having me.

Alan Shimel: Actually, we’ll see you. Are you going to be at AWS?

Tucker Callaway: Yeah, we’ll be there. Yeah, I’ll be there. Yeah.

Alan Shimel: We’ll be doing videos, not on the show floor. It’ll be a little quieter in a private suite. And then of course you’ll be at RSA.

Tucker Callaway: We’ll be at RSA.

Alan Shimel: We’ll be there as well.

Tucker Callaway: We might not be on the show floor at AWS just because of-

Alan Shimel: It’s a little crazy there isn’t it? A little pricey.

Tucker Callaway: Yeah.

Alan Shimel: Yeah, I hear you. That’s why we’ll be at the wind in the studio.

Tucker Callaway: I’ll see you there.

Alan Shimel: Come on up. I’ll have coffee.

Tucker Callaway: Sounds good.

Alan Shimel: But RSA will be at broadcast alley and we’ll be doing our DevSecOps thing on Monday. And the usual kind of RSA craziness.

Tucker Callaway: Looking forward to it.

Alan Shimel: Absolutely.

Tucker Callaway: Okay.

Alan Shimel: Check out Mezmo.com.

Tucker Callaway: Thanks everybody.

Alan Shimel: Tucker Callaway here on Tech Drunk TV. We’re going to take a break. I guess it’s almost lunchtime here, but it’s still busy.

Tucker Callaway: Near enough.

Alan Shimel: Stay tuned. We’re here all day. We’ll be back. Bye-Bye.

December 18, 2023