devopsy.kinsta.cloud

Category: Blogs

  • Copado Expands Beta of Generative AI Tools for Salesforce DevOps Platform

    Copado Expands Beta of Generative AI Tools for Salesforce DevOps Platform

    Copado today announced it has expanded a beta program through which it provides application development teams building applications for the Salesforce software-as-a-service (SaaS) platform access to generative artificial intelligence (AI) capabilities enabled by ChatGPT.

    David Brooks, SVP of Evangelism for Copado, said the company, via the usage of vector databases, has exposed instances of ChatGPT to everything in its knowledge base that has been collected over the last 10 years. That approach enables Copado to extend the large language model (LLM) used to train ChatGPT without exposing any data that might be used to one day train the next version of the generative AI platform.

    The goal is to enable DevOps teams to generate code and tests faster while simultaneously reducing the time required to handle support calls, said Brooks.

    In addition, Copado is using ChatGPT to enable impact analysis and conflict detection to reduce the level of friction encountered when deploying applications in a production environment. That latter capability is critical because, in many instances today, DevOps teams don’t have a firm understanding of how code needs to be deployed, resulting in unnecessary rollbacks of application deployments, noted Brooks.

    Generative AI will also automate the creation of documentation, such as release notes for every application deployed, to reduce the overall level of toil DevOps teams experience, noted Brooks.

    Copado also plans to provide governance tools that will enable DevOps teams to ensure the code written by an LLM is not based on a hallucination that results when trying to reconcile conflicting data, added Brooks. There will, of course, always be a need for a human to review code before it is deployed in a production environment, he added.

    In the longer term, Copado will make it possible for organizations to invoke multiple LLMs to address various functions as they best see fit, said Brooks. In fact, DevOps teams should expect to soon be employing multiple copilots trained to address specific tasks such as writing code, deploying applications, assessing cybersecurity and addressing compliance mandates, he added.
    Ultimately, application development and deployment efforts that today require weeks to complete will soon be accomplished within the same day, said Brooks.

    At the same time, organizations will also be able to better manage application environments that today operate at levels of scale few IT teams can manually track. Generative AI capabilities, in effect, will make it simpler for DevOps teams to effectively manage application environments at much higher levels of scale, said Brooks.

    Each organization will naturally need to determine to what degree they are prepared to absorb that level of innovation, but it’s clear the pace at which applications are built and deployed is about to exponentially increase. The issue organizations will increasingly encounter is that business processes will not be able to absorb the rate at which software can be built and updated.

    It’s not clear just yet to what extent generative AI will transform DevOps, but as advances continue to be made, many of the manual tasks and bottlenecks that today conspire to slow down application development and deployment are about to be eliminated in ways that few would have thought possible a little more than a year ago.

  • Survey Surfaces Significant Platform Engineering Gains

    A survey of 100 software engineers working at organizations in the U.S. and Western Europe published today found nearly all (99%) have embraced platform engineering to some degree as a methodology to manage DevOps workflows at scale, with more than half (53%) having done so in the last year.

    Conducted by Port, a provider of a proprietary internal developer portal (IDP) platform, the survey also found 83% of respondents have also incorporated GitOps workflows into their platform engineering practices.

    The survey also found 85% are working for organizations that have either started deploying IDPs or plan to do so in the coming year. However, what constitutes an IDP is not exactly clear, with more than a third (35%) that have implemented one reporting they are relying on spreadsheets to manage their IDP. A little over half (53%) of respondents, in contrast, are using an IDP to provide developers with self-service capabilities for setting up environments to write code that either was custom built, is based on open source Backstage software originally developed by Spotify or a commercial IDP platform.

    Among the 85% of respondents using or planning to use an IDP, the main measure of success is to improve developer productivity (56%), followed by reduced time to deployment (25%). Despite those initiatives, only slightly more than a third (34%) said IDPs are helping DevOps teams enforce software engineering standards.

    Roni Floman, chief marketing officer for Port, said overall, the survey suggests developers are wasting a lot of time on tasks that have little to do with writing code. For example, the survey finds that prior to embracing platform engineering, developers spent three to four hours a day on non-core activities, resulting in weeks being required to eventually deploy software in a production environment.

    The biggest challenge organizations face when embracing platform engineering is convincing developers that a centralized team has their best interests at heart. Many application development teams embraced DevOps as a best practice in the first place to escape the tyranny of a centralized IT team. The issue is that, as a result, many of them now find themselves managing tasks that have little to do with writing code. Platform engineering seeks to strike a balance between giving developers the ability to adopt new tools when they see fit and the benefits of having a dedicated platform engineering team that automates processes on their behalf.

    Unless platform engineering teams find a way to get developers to buy into the effort, however, it’s unlikely they will succeed, noted Floman.

    Each organization will need to determine for itself what level of platform engineering makes sense for them to implement, given their unique culture. In most cases, a platform engineering initiative will start small before increasing in size and scope as momentum is gained. In the meantime, the most important thing any platform engineering team clearly needs to do in the short term is engage developers. After all, the best way to get support for any change to a DevOps workflow is, as always, to convince developers it was their idea in the first place.

  • DevOps and Databases: The Key to Faster Deployment

    DevOps and Databases: The Key to Faster Deployment

    With DevOps, we learned that the biggest factor in streamlining deployments is to make things automated and minimize communication. However, we didn’t apply that principle to other areas. While security gets some traction with DevSecOps and machine learning has MLOps, we lack a solution for database management. In this article, we propose a new approach that unlocks the power of DevOps engineers to own their databases and lets them self-serve deployments, maintenance and troubleshooting.

    Why Database Deployment and Maintenance is Slow

    In the last few years, we moved from deployment being a big and challenging event to deploying many times daily. We moved from manual deployments to automated CI/CD pipelines. We built tools for deploying infrastructure and configuration changes. This led to a tremendous increase in the complexity of our systems. We somewhat learned how to handle that in deployments, infrastructure, configuration, security or even machine learning.

    However, database complexity increased significantly as well. We now use many database engines with each application. We use SQL and NoSQL databases as well as databases tuned for specific scenarios like machine learning or vector search. Since we deploy changes often and asynchronously, modifications to database schema or background tasks may happen at any time and affect the performance. When this happens, the business is directly impacted as the database issues quickly spread throughout the ecosystem. However, developers and DevOps engineers can’t fix the issues on their own and need help from other teams, specifically operations and database administrators. This makes the process slow and error-prone as things are not automated but require manual human intervention. Recommended reading: Why DevOps should own their databases and how to do it.

    The problem with database maintenance is the lack of solutions that would present the full and actionable story. We have many tools that can alert us about spiking CPU or increased latency, but we don’t know what’s the reason behind these issues. To find out, developers need to ask database administrators to check the logs and metrics to identify slow queries and whether the CPU spikes are caused by changes in the environment (like updating the operating system), slow background tasks that can be postponed (like vacuuming or index rebuilding) or due to inefficient application code that doesn’t use an index and performs a full table scan.

    Since we don’t know the reason, we need to involve multiple teams to investigate. We need to first identify the points of contact in each team, assign tickets or work items, sometimes page people at night, and coordinate the troubleshooting process. To make things faster, we need to fix two aspects: reduce the amount of manual work and reduce the number of people involved in the investigation. Let’s see how.

    Reducing the Manual Work with Observability

    Many things can go wrong when dealing with databases. Let’s see some of the areas that can break and are not automatically fixed today.

    Observability for the Code Changes

    Every time developers change their codebase, there is a risk of breaking the correctness and performance. We can verify the correctness with automated tests (unit tests, integration tests, end-to-end tests, etc.) and do it regularly in our CI/CD pipelines. However, we can’t verify the performance impact. Our tests focus on what we extract from the database and not how we do it. We may use N+1 queries, we may scan tables instead of using indexes, and we may have slow queries with CTEs or not use searchable arguments (a query that is not sargable). All these things may result in CPU spikes or latency degradation and we can’t automatically explain what happens. We need to have observability that gives the story like “the query execution within a given REST endpoint doesn’t use an index and leads to slow performance.”

    Performance of Schema Changes

    When we modify a schema, we risk that tables will be locked for rewriting. This may take minutes or hours and effectively make our systems unavailable. However, our CI/CD pipelines do not test the performance of schema migrations. Tests run against the latest schema and migrations are fast because databases in pre-production environments are small. We don’t check how long these migrations will take in production and if they’ll lock tables. We need to have tools that can warn us if a slow migration is being deployed and will indicate how to make it faster.

    Understanding of Execution Plans

    Databases grow over time. Queries change their execution plans because statistics get outdated or because indexes are modified. However, automated tests won’t capture these issues as they focus on the correctness of the data and they don’t run on the production database. We don’t see how things evolve and that the query degrades gradually over time. We need to have observability systems that provide an understanding of all the moving pieces around. They need to give us a story explaining that “the query we deployed six months ago stopped using an index because the statistics are out of date as we injected a big batch of data last night”.

    We need a story explaining what happened, like SQL stopped using an index or SQL query is not sargable. Other reasons can be schema changes, mismatched query fields, index fragmentation or significant changes in data volume affecting the query optimizer’s decision-making.

    How to Reduce the Work

    Taking all we saw above, we need to have systems that can understand how our environment evolves and how these changes affect performance. They need to alert us when some slow changes are being deployed to production, understand how the deployments affect the performance and automatically explain the issues. Troubleshooting should be as simple as just getting the notification with links to the places that we need to fix (like configuration, a particular line of code in our application, or the cloud console) with an explanation of how to do it. Fixing should be merely approving a pull request or confirming the configuration change.

    Reducing the Number of People Involved With Self-Servicing

    Having database observability is the first step. The second step is the ownership. Developers and DevOps engineers need to own their databases the same way they own their code and deployments. They need to be able to self-serve the issues and do that without any help from operations or database administrators. This will reduce communication and make things much smoother. There are three things that we need to introduce to let developers and DevOps engineers build their ownership.

    First, we need the tools. Just like we explained in the previous section, we need tools that can explain the story. We can’t just put more responsibilities on developers and DevOps engineers without making the work simple and automated.

    Second, we need new processes. We need to have playbooks and operational procedures explaining how to use the tools, how to self-serve the maintenance, and when to escalate. Developers must be familiarized with the procedures and must know how to follow them even outside of working hours. This way we can replace some work (communication, coordination of teams, manual investigation) with some other work (self-servicing) that we can do much faster.

    Finally, we need to change the mindset. Developers and DevOps engineers need to take on new responsibilities and become true owners of their databases. Even though this sounds like more work, we can make it much less time-consuming by building good observability tools and replacing slow human communication with automated and well-defined self-servicing. It’s not about shifting the work from one place to another. It’s about making the work much smaller and much more automated so the developers and DevOps teams can do it without involving other teams. Since we reduce the cross-team collaboration, the increase in the scope of work of developers and DevOps engineers will lead to doing the work faster.

    Summary

    There are three aspects that we need to work on now. First, tools like Metis must be created. Second, Platform Engineers must use these tools to define processes. Third, developers and DevOps engineers need to take ownership. While it may seem challenging at first, we already saw with the DevOps movement that minimizing communication and owning the full scope of the system is beneficial for the business and for the engineers. We need to restructure our teams and reassign responsibilities to unlock the potential and make organizations work faster.

  • Data Observability and its Importance: Everything you Need to Know

    Data Observability and its Importance: Everything you Need to Know

    In today’s tech-driven world, companies rely on almost incomprehensible amounts of data to dictate their business operations and decisions. Enterprises are focused on building multiple data repositories and data pipelines to process, store, manage and utilize data from various sources. Given the ever-growing size and complexity of the enterprise data environment, providing the accuracy and completeness of data is becoming increasingly challenging. So how can you understand how the data is performing across the entire IT infrastructure, all at once? The answer is data observability.

    What is Data Observability?

    Data observability is a process that aims to alert you to your data’s reliability and health while also delivering the insights and analysis required to identify and resolve issues before they affect your entire organization.

    Monitoring operations in the database serves as a proactive defense mechanism against potential security threats.
    This ensures accurate, complete, secure and valuable data and eliminates data downtime. Let’s dive deeper into the observability infrastructure and explore some of the best data observability platforms that can help you optimize and secure your data operations.

    Data Observability Framework

    We know that observability has three pillars: Logs, traces and metrics.

    However, data observability has five pillars, which, together, provide key insights into the reliability and quality of your data.

    Incorporating each pillar can help you craft an effective observability strategy.

    1. Recency: Also referred to as “freshness,” recency involves confirming if the data is up to date. It also analyzes if there are unusual temporal gaps in the data tables. This helps prevent timeliness issues in data pipelines.

    2. Volume: Volume involves checking if the amount of data intake in the database meets the expected thresholds. This ensures that data sets are complete.

    3. Distribution: This measures the quality of data at the field level and confirms if the data values are within expected ranges. Unexpected fluctuations in the distribution patterns are indicative of a data issue.

    4. Schema: This involves monitoring and auditing changes to data tables and data organization to look for signs of broken data. Schemas are extremely important as changes in the source data’s structure are often the cause of data downtime.

    5. Lineage: Lineage collects metadata and provides a complete picture of your organization’s data landscape, including upstream sources, downstream, and which teams can access the data at which stages. This process helps data teams troubleshoot where breaks occur in the data.

    Data Observability Benefits

    Data observability provides better visibility into your IT system’s internal state, including its behavior, performance and interactions with other systems. This can be beneficial in the following ways:
    ● Facilitates Root Cause Analysis: With end-to-end data visibility and monitoring across multi-layered IT infrastructure, data observability enables data teams to quickly spot issues in data sets with less effort. This also increases the chances of identifying new issues regardless of where they originate.

    ● Faster Mean Time to Detection and Resolution: As data observability monitors a wide range of output, data teams can actively triage and debug their systems. By providing valuable insights into how the data interacts and moves within the IT architecture, data observability helps teams spot problems they didn’t know about, resulting in quicker mean time to detection (MTTD) and mean time to resolution (MTTR).

    ● Automates Security Management: Data observability not only provides real-time visibility into the security posture but also makes it easy to automate parts of the triage process. This helps detect data health issues or data downtime instantly.

    Data Observability Challenges

    Depending on their existing IT architecture, organizations may face the following challenges when it comes to data observability:
    ● Data Silos: Due to the presence of several agents, silos monitoring tools and disparate data sources, it becomes difficult to comprehend interdependencies among applications, digital channels and various clouds.

    ● Integration with Entire Data Ecosystem: For data observability to work, the tool requires insights into the complete data pipeline and the servers, databases, software and applications involved. However, some organizations may find it challenging to connect all of the systems to a data observability platform.

    ● Manual Instrumentation and Configuration: Data observability tools aim to standardize telemetry data and logging guidelines to efficiently correlate information. However, as large organizations maintain several data sources (hundreds or even thousands), data from these sources might have varied standards. This requires manual effort to standardize data.

    Data Observability vs. Data Governance

    In today’s digital-first landscape, where data security is a global concern, there’s a growing focus on data governance. Data governance assists in the formation of policies and procedures required to keep a check on how an organization collects, analyzes, stores, shares and uses its data.

    A strong data governance program ensures data availability, integrity, usability and security. It eliminates data integration issues, data silos and poor data quality, thereby resolving the challenges of data observability.
    With data sets now scaling with more tables, more data sources and more complexity, data engineers and developers are under pressure to keep up with the data consistency, availability and security requirements. Any amount of downtime can lead to wasted resources and time while deteriorating confidence in decision-making.

    Data observability, along with data governance, helps organizations manage data security and quality problems in a streamlined manner.

    Data Observability vs. Data Quality

    Data quality measures the completeness and accuracy of data sets to determine if they can be used in analytics and operational applications. Data observability, on the other hand, allows organizations to detect and fix issues in the data pipeline efficiently and quickly.

    For effective data management, an enterprise must take both into account. Earlier manual checking and cleansing of data sets helped determine data quality. But today, many of these tasks have been automated, thanks to modern data stacks.

    As a result, there’s been a shift in focus from data quality to data observability. With data observability, businesses can effectively monitor and troubleshoot their data pipeline. Without it, they are at the risk of relying on incomplete or inaccurate data to make decisions. This can lead to expensive mistakes.

    Finding the Right Data Observability Tools

    Undoubtedly, data observability is a critical feature of any enterprise that uses data. However, not all data observability tools are equally beneficial to your business. Look out for the following traits when choosing a data observability platform:
    ● Compatible: The tool must be compatible with your data lakes, databases and cloud storage solutions.

    ● Autonomous: Autonomous technology responds to stimuli without any human intervention. This is essential in a data observability tool as it helps in the early detection of anomalies and an instant response to alerts.

    ● Timely: A data observability tool must help you identify errors as early as possible. The best platform constantly monitors data health from the moment the data is added to the ecosystem to the end of its lifecycle. Early detection of errors stops issues before they become critical.

    ● Sophisticated: The best platforms leverage machine learning (ML) and artificial intelligence (AI) to identify hard-to-find issues.

    ● Other features: The tool must be able to collect, sample, review and process telemetry data across several data sources. It should serve as a centralized data repository, offer comprehensive data monitoring services and provide data visualization.

    Eventually, the right data observability platform depends on your organization’s observability engineering needs and unique IT architecture.

    Top Data Observability Tools

    Data observability platforms are still a budding product category. The good news is that over a half-dozen data observability companies now offer commercial tools with excellent features. These include the following:

    Observability Vendors, Overview,  Pros and Cons

    Monte Carlo Data is headquartered in San Francisco. Monte Carlo is the creator of the industry’s first end-to-end data observability tool.

    ● Provides comprehensive data observability capabilities.
    ● Offers a high level of features, including automated alerting, data catalogs, etc.
    ● Supports fully automated setup.

    ● High data volumes can lead to user interface issues.
    ● Huge amounts of variables restricted by different constraints can lead to computational inefficiency.

    Bigeye is an industry-leading data observability platform that allows teams to improve, measure, and communicate quality data clearly and quickly at any scale.

    ● An easy-to-use interface that facilitates data configuration while ensuring consistency and accuracy.
    ● Provides powerful API integration capabilities.
    ● Features a versatile dashboard with real-time tracking and monitoring of data quality metrics by multiple people.

    ● It can be expensive for smaller organizations.
    ● The tool might crash at times, requiring performance improvements.

    Acceldata offers tools for Hadoop, cloud services, and companies which include end-to-end data reliability, data pipeline monitoring, and multi-layer data observability.

    ● Provides fully automated data reliability checks.
    ● Offers a drag-and-drop interface to analyze data pipelines across several layers and platforms.

    ● Initial setup can be complex and difficult.
    ● Node addition and node removal require human intervention.

    Databand is an IBM company that offers proactive capabilities to identify and resolve data issues in the early stages of the development cycle.

    ● Provides cross-stack visibility. This means you can get an overview of all the data tasks from start to end.
    ● Offers standardized DataOps and end-to-end data lineage, ensuring data reliability and accuracy.

    ● The program requires a significant amount of space, which makes it difficult to install it on the user’s system.
    ● It requires constant software updates making it much heavier.

    Datafold has a unique ability to proactively detect, investigate, and prioritize data quality errors before they affect production.

    ● Allows you to turn SQL queries into smart alerts, keeping you updated on any issues that may arise.
    ● Automates regression testing by integrating the CI process through GitLab and GitHub.

    ● Limited integration options.
    ● Does not provide any support for data analysis and data science.

    Closing Thoughts

    Data observability is the backbone of data engineers’ ability to be agile with their products. If you want to modernize your data management practices and improve your data quality, data observability is the way forward. Without it, your data team cannot rely on its tools and infrastructure, as issues can’t be detected efficiently and quickly.

  • 5 Reasons to Move Beyond SRE to Observability

    5 Reasons to Move Beyond SRE to Observability

    Recently, I was asked on a podcast to explain the relationship between site reliability engineering (SRE) and observability and why I believe organizations need to move their focus from the former to the latter. Those are great questions, but to answer them accurately, I first need to point out that many organizations claim to be doing SRE or claim to be doing observability but aren’t.

    One big thing that SRE and observability have in common is that they are both often erroneously equated with monitoring.

    SRE ≠ Monitoring

    Google is credited with pioneering the SRE movement with the publication of the “Site Reliability Engineering” handbook in 2016. As the SRE movement gained momentum, organizations of all sizes pored over the handbook and began applying its principles. However, very few organizations are of the size and sophistication of Google regarding the scale of their IT operations and engineering resources.

    So, as these “normal” organizations realized how difficult it was to follow the Google SRE approach in its entirety, they often opted instead to simply apply what they could. For many, the chapter on monitoring became the focus, so much so that monitoring has become synonymous with SRE in far too many organizations today.

    Let me be clear: The role of a site reliability engineer is not to monitor alerts. The role of an SRE is to define how the engineering team should take ownership of their service. SREs are responsible for establishing a culture and creating engrained processes that are focused on the quality and reliability of infrastructure.

    SREs guide the engineering team on how an application or service should be observed and monitored, including what parameters should be looked at, what alerts they should have, and what routing path the alerts should go through. An SRE instructs on best practices, explores the tools that are being used and determines how to gather reliable data with consistency throughout the organization.

    Many organizations we work with say they want to do SRE this way, but they’re not there yet. They are still stuck on monitoring every single metric they can find.

    Observability ≠ Monitoring

    Similarly, a lot of companies I meet say that they do observability, but what they are doing is just monitoring. They monitor every single CPU of every node of every pod of every machine that is running. They have alerts for some of these, and they may even have a playbook for some of them. This is not how SRE is supposed to work, and it’s certainly not what observability is all about.

    More importantly, it’s not scalable as an organization grows to hundreds or thousands of developers and different teams that all share the same IT environment.

    Two Viewpoints: Horizontal and Vertical

    Now that we’ve established that SRE and observability are alike in that neither should be equated with monitoring, let’s contrast the two. SRE and observability are different in that they have different perspectives on the IT domain.

    SREs see the world horizontally. They conceive of their IT domain on a horizontal plane where they can observe the capacity of resources being used. They see the Kubernetes cluster, and they see the cloud utilization. And they care about ensuring that what is deployed into the production environment is secure.

    Although they see the pieces they manage on the horizontal infrastructure plane, they don’t see the ultimate impact on the application or customer on the planes “above.”

    Observability is looking at the world vertically—that is, seeing how an application is or isn’t meeting customer needs. The whole goal of observability is to know if my application is serving my customers at the service level that I agreed to. With a vertical view from application up to customer needs and business impact, I don’t care how many pods are being run, how many nodes are being deployed or what comprises the cloud infrastructure underneath my application, as long as it works.

    I do care about security insofar as I want to avoid introducing security vulnerabilities into the organization. But beyond that, all I need to know is that the application can meet the customer’s expectations and the service level objectives (SLOs) that we have established are being met, as well.

    Therein lies the heart of the matter: For a company to make the transition to observability, it needs to build the observability system around establishing and meeting SLOs.

    The Challenges of Transitioning to a Vertical Perspective

    Companies must move beyond an SRE and DevOps organization to being an observability and SLO organization. Only by doing this will organizations be capable of understanding the trade-offs within their IT environments between cost, security and availability and the ultimate impact those trade-offs will have on business objectives.

    Today, making this transition — moving beyond SRE to observability — is difficult for a wide variety of reasons, not the least of which are:

    Alert Fatigue. Companies today are monitoring too many things they shouldn’t care about, and as a result, engineers are suffering from alert fatigue. With this, you face the danger of a higher probability of missing the alerts that you do care about and making sure that you address them promptly.

    Ideally, observability solutions eliminate the irrelevant and unimportant alerts, add context to alerts that might need investigating, and correlate response data and docs to accelerate and coordinate the appropriate response of on-call responders.

    Tool sprawl. Many of the companies we work with use a wide variety of separate tools for observability. Observability requires access to the data all of these tools produce, and problems can persist if the tools operate in data silos.

    However, the problem can be solved if there is unified data collection across the toolset, ideally using OpenTelemetry. Cross-tool and cross-stack insights are particularly important for security purposes. Another issue with tool sprawl is that true observability requires that these tools, which each typically address just one aspect of observability, somehow all work together.

    Unfortunately, current systems and processes lack the “connective tissue” to offer a consolidated observability solution.

    Complexity. As we’ve seen in the results of our annual DevOps Pulse survey, the mean-time-to-resolution (MTTR) is going up instead of down, despite the number of tools that are available and the advancements made by the industry in recent years.

    Complexity is a large part of the problem, specifically concerning Kubernetes. In our 2023 DevOps Pulse Report, we found that almost 50% of respondents cited Kubernetes as their main challenge to gaining full observability into their environment.

    The adoption of Kubernetes is happening at lightning speed—even faster and higher than the adoption of cloud technology. But it’s not just the adoption of one Kubernetes—there are so many different flavors of Kubernetes, whether it’s Kubernetes running on managed services like AWS EKS or AKS or Kubernetes running on serverless with AWS Fargate. And that’s just to name a few of many, many types of Kubernetes out there.

    All of these options create flexibility, but wherever you create flexibility, you also create complexity. Complexity in the infrastructure increases the time it takes to troubleshoot and resolve issues.

    Cost. Most of us have figured out that products that include every feature under the sun are a waste of money. We don’t need expensive and extraneous clutter. Likewise, gathering and processing too much irrelevant monitoring data adds significantly to costs. Investing in observability platforms that are overloaded with bells and whistles you simply don’t need is similarly costly.

    The ideal observability platform taps AI and automation to help you easily see what’s most important to the business and respond quickly to core issues with precision and advanced insights.

    Culture change. Going from monitoring to observability is akin to making a cultural quantum leap. Observability requires a different organizational structure and assigns different responsibilities to the teams. The transition requires change management skills and patient, thoughtful execution.

    Though these challenges are significant, the observability industry is making rapid progress and organizations can expect to see solutions and technology providers that overcome these challenges shortly. So, be on the lookout for great opportunities coming down the pike.

    In the meantime, I challenge you to change your perspective from horizontal to vertical. Set your organization on the path to move beyond DevOps and SRE to true observability, where your teams will not just be alerting and chasing issues for troubleshooting but working to establish real SLOs and driving toward those to enable the strategic goals of the business.

  • KubeCon 2023: Dell, DevOps and DevRel

    KubeCon 2023: Dell, DevOps and DevRel

     

    Speaker 1: This is Techstrong TV.

    Alan Shimel: Hi everyone. Hey, we’re back here live in Chicago, KubeCon + CloudNativeCon, day two, continuing our coverage, we’ve got some great people lined up to bring you today. We started just now with Dan Garfield from Argo and Codefresh, and my next guest is my friend Brad Meltzer…

    Brad Maltz: Maltz.

    Alan Shimel: I screwed this up… He’s my friend, and why do I think Meltzer?

    Brad Maltz: I don’t know, it’s a good New York name.

    Alan Shimel: No, I knew a Richard Meltzer.

    Brad Maltz: There you go.

    Alan Shimel: I’ll tell you a great story about him off camera, he was a tech entrepreneur, a miserable failure of a tech entrepreneur.

    Brad Maltz: Okay.

    Alan Shimel: His wife though, invented the things, you know how you’ve got holes in Crocs?

    Brad Maltz: Yes.

    Alan Shimel: His wife invented the things that go into those holes. He closed down his venture backed startup, his wife sold those to Crocs, and they’ve lived happily ever after.

    Brad Maltz: And I hope he’s watching this.

    Alan Shimel: Richard Meltzer. He’s from Boulder, Colorado. Hey man, how are you, Meltzer?

    Anyway, that took me down a rabbits nest. Brad is with us… Actually shout out, right? Dell Technologies is sponsoring our broadcast this year from KubeCon again, as they did in Amsterdam last year, and a large part of it is due to Brad, Brad is a director…

    Brad Maltz: Senior director of-

    Alan Shimel: Senior director.

    Brad Maltz: Of the DevOps portfolio and DevRel.

    Alan Shimel: There you said it. Now a lot of you may be asking at home, wow, I didn’t know Dell was involved in DevOps and DevRel, or in CNCF.

    Brad Maltz: Yep.

    Alan Shimel: I got a Dell, right? I got a Dell box-

    Brad Maltz: You’ve got your laptop.

    Alan Shimel: I got the Dell server and stuff like that, but there’s more to today’s Dell than the boxes. So Brad, I don’t want to embarrass you, but I’m going to put you on the spot here.

    Brad Maltz: Go for it.

    Alan Shimel: Talk to us about, I want everyone at home to understand what your group does and how involved you are, not just in CNCF, but in the DevOps community, the DevRel community.

    Brad Maltz: Yeah, so basically over the past year and a half, we’ve been making sure to kind of expand our community outreach, specifically around the DevOps stuff. When I took over the role in product management to help kind of build out further our container strategy, our infrastructure as code strategy, we didn’t realize that we needed a DevRel-like function to help kind of expand our community outreach, our advocacy back into Dell.

    And the reason for that is, what a lot of people don’t know is, I mean, we play across the entire ecosystem of CNCF, right?

    Alan Shimel: Absolutely.

    Brad Maltz: We bring Containers and Kubernetes solutions to market, we play in the AIML space, the security spaces. We’re enabling ecosystems around us with our technology.

    So because of that, having DevRel was extremely important. We spun up podcasts, we have what we call our DevOps Dispatch, which we’re actually recording here at CNCF, and you can get that on YouTube and Spreaker. We have developer.dell.com which we relaunched last year, and now it’s kind of taken off, hands-on labs and blogs and a whole bunch of stuff on there. So for us, the evangelism’s important, but the advocacy for our end users is more important back into Dell.

    Alan Shimel: Got it. So we talked about the… I don’t want to use the word infrastructure, but the infrastructure of how you’re reaching out.

    Brad Maltz: Infrastructure matters.

    Alan Shimel: Absolutely. But I want people at home to understand that behind that infrastructure though is real solutions.

    Brad Maltz: Exactly.

    Alan Shimel: Right? Because part of the whole Dell Technologies thing, it’s solutions. It’s not just a PR marketing kind of… Though we see it here on the show floor, and the podcast and all these things. Let’s talk about the solutions you guys bring.

    Brad Maltz: Yeah, so I mean, a great example is, and this show is actually a big one for us, we just recently have launched our APEX Cloud platforms, and we did one with Azure Stack, we just did one with Red Hat with OpenShift, and that’s actually one of the big things here.

    And what you’re going to see more and more of from us is the ability to take our compute, with our storage, our networking, integration with our ecosystem partners, but give you more of that easy button experience, give you more of the turnkey experience, or even the DIY. We’re always been good at the DIY.

    Alan Shimel: Yeah, that was DNA…

    Brad Maltz: But right now, can we get you more of those easy buttons, right? And that’s exactly where something like ACP for Red Hat here, is if you just want to be able to get OpenShift up and running from the factory as quickly as possible with the least amount of hands as possible, you’re looking at things like our solutions like ACP. And the trick is when you look at solutions, are they just white papers, [inaudible 00:04:57], which are really invaluable to certain people?

    Or is it a factory delivered end-to-end platform experience that delivers that Cloud-like experience and developer experience, on top of the infrastructure, plus plus.

    Alan Shimel: Guys, let’s not minimize that, that makes life a lot easier. I mean, I think back to the first DockerCon… It wasn’t the first, but it was the first one in Austin, because before that DockerCon was in Seattle, this is going back a while. And I saw Kubernetes there, I think it was maybe 0.8 was the release, it wasn’t-

    Brad Maltz: It was early.

    Alan Shimel: It was early. I came home, because at the time, we hadn’t launched Cloud Native Now, and before that it was Container Journal, we hadn’t launched it yet, we were still coming up with the names, and we were toying around with names with Docker in it, which would’ve been a mistake… Well on multiple levels.

    But I came home and told the team, I said, “Look, everybody at DockerCon is talking about this thing called Kubernetes, but it’s never going to catch on. It’s so God damn hard, I don’t know how anyone would use it.”

    Brad Maltz: Why do you think you didn’t bet on that?

    Alan Shimel: Well, this is why I still work and I’m not retired, Brad.

    Brad Maltz: Okay.

    Alan Shimel: Yeah… Another brilliant insight from Alan Shimel… So now with that being said, I’ll stand by my original point, Kubernetes is still hard.

    Brad Maltz: Yes,

    Alan Shimel: It is. I don’t care, I’ll work till I die, I guess, but it’s hard.

    Brad Maltz: Kubernetes is hard, and I think… So Kubernetes hit a maturity point, right? So definitely it won.

    Alan Shimel: No doubt.

    Brad Maltz: And everybody needs it. It’s leading the Cloud Native application kind of abstraction battle, so it’s there, but that doesn’t mean you don’t need to be a jack of all trades to be able to understand all the nuances in the abstraction. And you basically have to be able to operate everything under the covers of Kubernetes to make Kubernetes work properly.

    Alan Shimel: Absolutely.

    Brad Maltz: So what is the real long-term easy button? That’s I think an open question right now for Kubernetes. Opportunity.

    Alan Shimel: Absolutely, I don’t want to get [inaudible 00:07:10], maybe the easy button is something other than Kubernetes?

    Brad Maltz: That is always a potential.

    Alan Shimel: Yeah. But let’s get back to our point here though, so now you get Red Hat OpenShift, right?

    Red Hat OpenShift is probably, I guess the most, certainly in the top two Kubernetes platforms, if you will, if you’re using Kubernetes. And it’s still a little hard, right? I mean, you could go download it from Red Hat-

    Brad Maltz: You can get it running, but you’ve still got to have some knowledge behind it to do the basics.

    Alan Shimel: But this is where the easy button comes in.

    Brad Maltz: Yes.

    Alan Shimel: And also, I want to make clear, when we talk about this easy button, a lot of people say, look, why do I get it from Dell? I don’t want hardware, I’m hosting it in the cloud.

    Brad Maltz: But are you? That’s the question. So when people talk about-

    Alan Shimel: I wouldn’t have asked you if it was the… Okay…

    Brad Maltz: With cloud, it’s always, yeah, you have the super easy button in the public cloud, they’ve done an amazing job there. But you get to deal with things like egress fees, you got to deal with things like costs for ongoing costs for a lot of services behind that. And at some point people start to become cost conscious, so that’s one angle that you deal with.

    The second angle, in this new AI world that we’re now officially in as of 2023, you do start to wonder where’s your data living? Where do you want your data to live? And you’ve got the governance compliance side of it. Not security as much, but it’s more the ownership governance. And we’re seeing a lot of people say, you know what, with all those GPUs, there’s a cost and a governance angle to hosting it in my data center, in a Colo, Cloud adjacent and Cloud aware.

    Alan Shimel: Yep.

    Brad Maltz: So that’s where I see things like ACP for Red Hat 100% making sense.

    Alan Shimel: I agree with you 100%. I think there’s another angle here though, and that is this: Unless you’re really in it, and you may not realize this, but Kubernetes on bare metal, Kubernetes in a data center, not in the public cloud, has always been a big component of the Kubernetes footprint.

    Brad Maltz: Yes.

    Alan Shimel: Everybody just assumed, puts the words Cloud Native and Kubernetes Cloud Native, that it’s all in the big three clouds, right?

    Brad Maltz: Yep.

    Alan Shimel: Well, even beyond Oracle, IBM and the rest, but there’s always been a Kubernetes on-prem.

    Brad Maltz: There always has been, and there always will be.

    Alan Shimel: It’ll continue, it will be-

    Brad Maltz: I think it’s going to grow.

    Alan Shimel: Right, well, I think for the reasons you’ve outlined, right? People are worried about control, they are worried about compliance, they are worried about how’s AI play in all this and cost containment and FinOps and everything else.

    So I think that again is an insight that if you’re not really wired into the Kubernetes community, you don’t-

    Brad Maltz: You don’t think about it.

    Alan Shimel: Recognize… Yeah, excellent. Let’s talk about the show a little bit, so you guys are podcasting here live as you said, but what about conversations? I don’t know, I heard today there’s maybe eight, maybe up to eight to 10,000 people or something like that.

    Brad Maltz: Feels like that, yep.

    Alan Shimel: Conversations with people; what are you hearing? What are you seeing?

    Brad Maltz: A lot of the conversations right now are actually… So I’ve had a lot of AI discussions, which-

    Alan Shimel: So do we.

    Brad Maltz: I mean I expected it, but they’re kind of interesting because they’re not just about how do I build AI things, it’s how do I use AI operationally?

    And I think that’s the nuance that I’m seeing CNCF, maybe in the forward-looking view of the world, is how do we apply AI in the operational side of things like Kubernetes and security and all of that. That’s been a handful of, not a large percentage of conversations. There’s always… Actually the easy button thing, honestly, that’s probably been one of the biggest things.

    People are just, they don’t have enough skills out there, and actually one of the other things is Platform engineering. So one of the things you can see on my shirt, right? We have this-

    Alan Shimel: I saw it, I saw it when you came in.

    Brad Maltz: This is our logo that we have here, at Amsterdam, we kind of have this DevOps operating model yin yang where Dev and Ops have to play well together, cats and dogs have to come and be nice.

    Well enter Platform engineering, and these folks building the platforms that are like products inside of the end user environment, they need to adopt and embrace the DevOps operating model in their world. Platform engineering has been one of the buzzwords, I think it has been a big conversation for us here as well.

    Alan Shimel: Absolutely. Hey, just a quick plug for Techstrong, if you don’t mind, on the topic of operationalizing AI.

    We actually, I mentioned to you off camera, we did this hackathon about two months ago at our office with some of the founders of the DevOps movement, around operationalizing AI. And we recorded it-

    Brad Maltz: Oh, that’s awesome.

    Alan Shimel: We recorded all the sessions and we’ve just about got done editing now to make it manageable, and it’ll be out on Techstrong TV, I think in the next week or so. So if operationalizing AI is something you are into, go check that out. Edited, created totally by our Techstrong video team and starring some really cool people, so-

    Brad Maltz: That’s awesome.

    Alan Shimel: Looking to hear that about it. All right, enough of my own plugs. Brad, what else have you got for us?

    Brad Maltz: I mean, right now I think it’s just an exciting time to be in CNCF, in the community, in the industry, right?

    I mean, what’s interesting, I had seen, funnily enough a meme, that popped up in one of my social media threads, it talked about over 2000 years, the acceleration was like: The horse and buggy to the horse and buggy and everything was very flat, and all of a sudden the last 100, 150 years… Right now it feels like this year, and the past of one or two years, technology is accelerating at such a fast rate that we as an industry, can we keep up with it skills wise and people wise and career-wise?

    I feel like going into the next few years, we’re definitely going to have this skills challenge, and I think that’s one thing that I’m going to be focusing on a lot is how do we enable the industry, as technology just keeps evolving around us? I think that’s a big thing personally for me.

    Alan Shimel: So I will tell you, I’m a little older than you, a little… I don’t disagree with you except I think it’s even bigger than… It’s not just about this industry.

    Brad Maltz: Yep.

    Alan Shimel: I think the kinds of changes we’re seeing now is almost akin to when the internet first went public, right? So this is how I divide things, there are technology innovations that have a profound impact on the technology industry. I’ll give you a perfect example, the cloud. The cloud changed a lot of how we do tech, right?

    I mean, your grandma may say, “Where’s your pictures, grandma?”

    And she says, “They’re in the cloud…”

    Whether they were in the cloud or in the server [inaudible 00:14:33] or whatever, it didn’t make a difference to grandma, but it made a difference to us in this industry, we had to know about cloud security and deployments and everything that goes along with cloud and it kind of rocked our world.

    Then there are technology innovations that rock civilization: the internet rocked civilization, think about life before the internet. It’s a very different-

    Brad Maltz: Cell phones.

    Alan Shimel: Cell phones rocked civilization. So there are things that transcend technology markets, and I think we’re in one of those layers right now where things like AI and quite frankly, look, quantum is going to be real-

    Brad Maltz: At some point, it’s just going to magically happen to everybody.

    Alan Shimel: Boom. I read an article last week the very first time they broke RSA 256.

    Brad Maltz: Yeah, I saw that.

    Alan Shimel: With quantum. That’s crazy stuff, if you’re not up on it out there. But I feel like all of these things are converging to create another civilization changing and it couldn’t come at a better time because God knows we need it.

    Brad Maltz: We do. I’m with you, AI is going to be the next… It’s not even going to be, it is the next thing. And one last note on that for me, when we talk about in product management and Dell Technologies land, like our end users are people? Not anymore… The end users of our technology might actually be the AI, so we have to figure out what is the personality of an AI in the future? There’s a lot of things to think about.

    Alan Shimel: What is the AI wanting and looking for?

    Brad Maltz: That’s it.

    Alan Shimel: Nuts. All right. Hey Brad, you know what we didn’t mention? Hey, people who want to go visit the website, what’s the url?

    Brad Maltz: Obviously at dell.com, we have developer.dell.com now, so please focus on developer.dell.com. Go there, you can get all the latest events, newsletters sign up, hands-on labs, you name it. And you can reach out to me on LinkedIn, and if you have any questions, we’ll help you out.

    Alan Shimel: Fantastic. All right, we are live here in Chicago. We’re going to be back with our next guest in a second in KubeCon. Go check out developer.dell.com, and many thanks to Dell Technologies for sponsoring us here at KubeCon. We’ll be back in a minute.

  • KubeCon 2023: CTO.ai’s Developer Control Plane

    KubeCon 2023: CTO.ai’s Developer Control Plane

    Speaker 1: This is Techstrong TV.

    Alan Shimel: Hey, everyone, we’re back. We’re here in Chicago at KubeKon. We’re wrapping up our day two coverage, our last guest for day two. We’ll be back tomorrow, though. But let me introduce you to Kyle Campbell, right?

    Kyle Campbell: That’s right.

    Alan Shimel: Kyle is the founder of cto.ai and we’re going to find out about cto.ai and a little bit about what they’re doing here at KubeKon. But before we do that, Kyle, first of all, welcome.

    Kyle Campbell: Thank you.

    Alan Shimel: Second of all, let’s hear a little bit about Kyle.

    Kyle Campbell: Yeah, thanks.

    Alan Shimel: Tell us your kind of journey.

    Kyle Campbell: Yeah, well, first of all, great to meet you in person. I’ve talked in the past. Yeah, so my journey, I’ve told this story before, a little unconventional. I grew up in Nova Scotia in Canada, a small town. Been on the internet since the age of eight and just had no interest in the formal past. So I’ve been building software from the early days of the .com boom. I may not look at it, but I got some of the scar tissue. But I was self-taught software engineer, so open source was the key to my success and good developer tools.

    Alan Shimel: Sure.

    Kyle Campbell: And I came up through the cloud and open source era and then started founding developer platforms in 2014. The first company I built was a developer platform, the real estate space. Zillow acquired it in about eight months, which was interesting.

    Alan Shimel: Very.

    Kyle Campbell: And then I bootstrapped a DevOps agency quite successfully and started to find that there was a lot of opportunity for next generation developer platforms, which led me to cto.ai.

    Alan Shimel: Excellent, man. What a great story too. You still up in Nova Scotia?

    Kyle Campbell: I’m not. I moved to the other side of the country. I live in British Columbia now.

    Alan Shimel: Good for you.

    Kyle Campbell: Love the outdoors. Spend a lot of time with my son camping, fishing, and trying to get outdoors and just enjoy the beautiful-

    Alan Shimel: Loving it. Yeah, no, it’s beautiful. I mean, not that Nova Scotia’s not beautiful. It’s brutal in the winter, but it’s a beautiful country, part of the country.

    Let’s talk cto.ai now. So look, I’ve founded multiple companies myself. Every founder I’ve ever interviewed or spoken with in 30 years, they don’t just say wake up and say, “Oh, I feel like founding a company today.” There’s kind of like Richard Dreyfuss in Close Encounters of the Third Kind, right? There’s something driving you like, “I got to do this. This needs to get done.” What was driving you that needed to get done here with cto.ai?

    Kyle Campbell: Yeah. I mean, as I described my past, a lot of my journey was self-taught and stand on the shoulders of giants. And really important thing for me was developer experience and ease of use and tooling early on in my career because that enabled me to really drive my competencies as a developer and keep up with these people that had computer science degrees and master’s and all these things, right?

    Alan Shimel: Certainly.

    Kyle Campbell: So when I thought about that and I also thought about where the future’s going and my passion for platform engineering, it became pretty obvious to me that what was missing in the market was a set of tools that were designed to embrace the future of developer experience and how AI can impact that from code to cloud.

    So in 2016 or so, I started experimenting with the idea, and through 2020, I decided to formally launch cto.ai as a developer control plane is what we call it. The way to think about it is it’s a modern CI/CD platform where teams can compose their workflow across build, deployment, test, and preview. And as they work with these tools, they can interact with them in the CLI Slack, GitHub, talk to these workflows through sort of a prompt based model. And we collect telemetry data that allows them to then measure that against DORA metrics, which is-

    Alan Shimel: It’s standard.

    Kyle Campbell: … yeah, it’s a standard and I think, frankly, an empirical way to measure the developer experience. We don’t try to measure developer productivity. We think that’s the wrong question to ask. The question is how do I measure the experience the developer has in the same way that I would measure the experience my users have with my product? And if what we’re doing is building platforms to enable developer experience, we need a natively integrated way to measure that. And we also think that that measurement is a way to pave a future between how the developers experience those tools and how AI can support the developer experience and enhance developers with, frankly, superpowers over time.

    Alan Shimel: So I was recently at a couple of user conferences, big DevOps companies, and it was interesting. Three conferences all use the same metric, which is that developers only spend about 30% of their time developing.

    Kyle Campbell: State of DevOps Report 2018, I think?

    Alan Shimel: But it was in there and it’s been kind of verified in several others. What do you think about that? Is it good thing, bad thing, something to be proud of, something we should be working on? What’s the deal?

    Kyle Campbell: Yeah. Well, I think a pretty practical point of view in that as a software engineer, my goal is to release features that customers love and drive business value. And if I can do that at a higher velocity while maintaining quality, I mean, I think that that is a way that I, as an individual, can contribute to the success of the business and the team.

    But I think what often happens is we get really obsessed about the individual developer. And I think any developer who looks at the idea that they only spend 30% of their time adding value isn’t going to like that very much. And I think we need to reframe the conversation away from developer productivity towards developer enablement and look at the tooling and the process that the developer experience promotes and how developers go from code to cloud and ask ourselves as a business leader, as a CTO who we work with a lot, is the tooling and the workflow that we’re supporting our team with and that developer experience, what they’re experiencing, is that driving results?

    And I think DORA metrics is an empirical way to measure that, obviously, through anecdotes and surveys, but what we’ve really innovated on is creating a vertical integration with the tool chain that allows you to measure that in real time and then iterate on the tools quickly. And some of the teams can really own that themselves. And what the businesses should be doing is zooming out and asking themselves, “Yeah, how do we maximize the amount of time developers spend without individualizing that consideration?” There’s an innerloop and there’s an outerloop. And what DORA is really good for is measuring the outerloop of how we work in aggregate of teams. We need next generation platforms that make this data and this context more accessible to business leaders.

    Alan Shimel: I don’t disagree with anything you said there, so we’re there with that. What about have you guys released any news or anything? What do you got going on around the show?

    Kyle Campbell: Yeah, so for the last while, we’ve been focused on really building a rock solid workflow and tooling to basically set the premise of that next generation composable CI/CD vision. We’ve fed that data into DORA Metrics. You can now report on DORA metrics in real time, save those reports, share them with whoever one-on-ones, retros, so kind of up to you. And we’re starting to experiment with some data science, but something that’s really exciting that we just kind of put into production last week. We haven’t really officially announced, so I guess this is a first is we’ve released our first kind of AI-

    Alan Shimel: Heard it here first.

    Kyle Campbell: … yeah, heard it here first. Our first AI feature set, which is AI code review. And what we’re doing is we’re letting teams start with these sort of base models for how they can leverage AI in the code review process to get developers’ feedback earlier. But then, we want them to be able to do is enhance that model to really customize it to their preferences on their own kind of hardware, to customize those models to take into consideration their own specialized requirements and obviously protect proprietary information that’s so core to their beliefs. So we launched that into production, announcing it here first.

    Alan Shimel: Really?

    Kyle Campbell: And we’re looking for early adopters who can kind of test it out and help us stress test it and figure out how do we further enhance the context of that model with some of the information that is derived in these DORA metrics as well.

    Alan Shimel: So here, we’re talking to this camera. Developers out there. You’re looking for them to kick this around a little bit. Kick the tires.

    Kyle Campbell: That’s right. Yeah.

    Alan Shimel: How do they do it?

    Kyle Campbell: You’re a developer and you’re interested in how AI can support your CICD workflow, specifically code review, come over to cto.ai, sign up, send a message. I’d love to talk to you personally, software development yourself, and love to hear what you think, what you think are the limitations and hesitations, and more importantly, how do you think we can enhance this with other use cases? Because I think there’s a whole exciting set of use cases for AI and software delivery that is going to help software developers.

    Alan Shimel: Absolutely.

    Kyle Campbell: We embrace-

    Alan Shimel: I had this conversation in an earlier interview today. Look, for people who aren’t tech, you show them an AI interface and some of the kind of parlor tricks it could do and they think it’s magical.

    Kyle Campbell: Yes. Arthur C. Clark.

    Alan Shimel: Right.

    Kyle Campbell: Yeah.

    Alan Shimel: Now, we know it’s not magic. It’s just putting one word in front of the other or one… but there are some uses that AI really shine certain. So it’s not meant to replace Google Search nor is it meant to replace software developers.

    Kyle Campbell: No.

    Alan Shimel: But it can empower software developers to be 10x more effective. And one of the ways it could teach you to code, right? You could put code in there and say, “Explain it to me.” It could review code, right? So either it’s writing code or it’s reviewing code. You shouldn’t have it doing both probably, but…

    Kyle Campbell: It’s true.

    Alan Shimel: Right. But if it’s using it for review, what a great use of the technology.

    Kyle Campbell: Yeah. We’ve seen that the number one thing that slows down time to market in feature sets for developers is waiting for code review. And while I’m not sure that it’ll be the same thing as you and I pair programming and getting into the nitty-gritty details, if we can make sure that every developer can get a code review instantly just by adding a label and then that we can tailor the quality of that code review with more context that is supported by how the team thinks about quality. I think this is an important example of how we can accelerate the needs of developers and the developer experience with AI that still leaves all the control in the hands of the developer to decide, “Is this rational? Is this a hallucination? Is this the appropriate time?” But the feedback loop that we can get from this is, I think, a really great beachhead and why we chose to start there.

    Alan Shimel: Absolutely. And we’ll see. I don’t think we scratched the surface yet on how we’re going to use AI, but this is certainly a real definitive first step that I see us going with, right?

    Kyle Campbell: I think so. And I think the call to action for other software vendors out there is to think about reinstrumenting what they’re offering to prepare for this because I think there’s a necessary hesitance around AI. I think rightly so. But if we can think about how we can take control of it, how softwares can take control of it. Software engineers are perfectly suited to be some of the first stewards of these problems. Just like we see AI and code generation, I think the next natural step is to support it within code review. And then we’ll start looking at how smarter deployments, smarter rollbacks, and obviously, operations can be enhanced with AI. And this place is a perfect example of people trying to solve that problem.

    Alan Shimel: Absolutely. Absolutely. And here’s the other thing. I’ve been in technology a long time. You don’t put these genies back in their bottles.

    Kyle Campbell: Right.

    Alan Shimel: Once they’re out, they’re out. And so like it or not, they’re here. And I think you could… if you can’t beat them, join them.

    Kyle Campbell: You can’t stop Moore’s Law. I mean, this the pathway that the world is on.

    Alan Shimel: No, you’re not. You’re just not going to stop it. That’s the way it is. It’s great stuff, man. I love the attitude. I love having you on here. Cto.ai. Again, if you’re looking to help Kyle out, kick the tires on this AI code review product they got coming on, it’s fantastic. So let’s check it out.

    Kyle Campbell: All right. Thank you so much.

    Alan Shimel: All right. Hey, Kyle, enjoy the rest of your KubeKon. cto.ai wrapping up day two in Chicago at KubeKon. We’re going to be here tomorrow morning. I think we’re on at 10. We’re only here till two tomorrow because it wraps early tomorrow. But we’ll be back with a full load. We hope you’ve enjoyed today. On Demand is available at Techstrong TV. And so if you missed anything, do check it out. This is Alan Shimel. We’re out.

  • Atlassian Delivers on Generative AI Promise for DevOps and ITSM

    Atlassian Delivers on Generative AI Promise for DevOps and ITSM

    During a virtual Unleash event, Atlassian today announced its generative artificial intelligence (AI) capabilities are now generally available across its Jira and Confluence suite of tools for managing IT and DevOps workflows.

    In addition, Atlassian also committed to adding generative AI capabilities to its Bitbucket continuous integration/continuous deployment (CI/CD) platform to enable DevOps teams to review pull requests and leave comments automatically with suggested changes around syntax and code conventions via a natural language interface. Developers will also be able to autogenerate pull request descriptions from commit messages.

    Matt Schvimmer, head of products for the Agile and DevOps division of Atlassian, said the capabilities provided by Atlassian Intelligence will reduce the level of toil and stress DevOps teams experience at a time when the velocity at which applications are being developed and deployed only continues to increase.

    Atlassian reported nearly 10% of its more than 265,000 customers have already leveraged Atlassian Intelligence since the launch of the beta program. Organizations, for example, can instantly create user stories within Jira Software tickets, change the tone of a customer response within Jira Service Management, create summaries, launch workflow requests via prompts and generate a starting point for a test plan in Confluence.

    Natural language capabilities, currently available for Confluence, will shortly be generally made available for Jira. An ability that promises to help demystify company-specific concepts, jargon or acronyms is also available now in beta, with support for Jira Software and Jira Service Management to shortly follow.

    There is little doubt at this juncture that AI will be pervasively applied across both ITSM and DevOps workflows. As those advances are made, it should also become feasible to reduce the level of toil these teams regularly encounter. At the same time, the level of scale at which ITSM and DevOps workflows can be effectively managed should also increase substantially.

    Each organization will need to decide how quickly to incorporate AI into those workflows, but hopefully, the level of burnout experienced by IT personnel will be sharply reduced as more tasks are automated. Less clear is the impact AI will have on the size of IT teams required to provide those services, but for the foreseeable future, there will always be a need for some level of human supervision.

    In the longer term, the war for IT and DevOps talent that has been waged now for multiple decades should diminish as managing these workflows becomes more accessible, noted Schvimmer. Organizations will not need to rely so much on the expertise of a handful of specialists, he added.

    Organizations, however, would be well-advised to make sure AI is embraced from both the bottom up and the top down to ensure optimal adoption, said Schvimmer.

    In the meantime, IT teams should take an inventory of the processes that are likely to be automated by AI today with an eye toward restructuring teams as more tasks are automated. Ultimately, the goal should be to let machines handle the tasks they do best to enable the IT staff to provide services that deliver more value to the business.