devopsy.kinsta.cloud

Tag: DevOps

  • Is ChatGPT Helping or Hurting Your Developers’ Productivity?

    Is ChatGPT Helping or Hurting Your Developers’ Productivity?

    ChatGPT’s ability to translate natural language into working code has sparked tremendous interest in the programming community. Developers are exploring ways to use ChatGPT to reduce redundant tasks, from creating code snippets to analyzing and debugging programs. This also allows them to focus on more complex tasks like data analysis and monitoring with the help of a strong full-stack observability platform. Despite ChatGPT’s impressive capabilities, developers and their employers are split on whether the AI chatbot significantly boosts developer productivity.

    We will explore how to use ChatGPT to benefit your developers’ productivity and go over the advantages and disadvantages of ChatGPT to help you make the right decision for your business.

    How to use ChatGPT for Better Productivity

    ChatGPT has quickly become the most popular intelligence chatbot, with over a million user signups in its first five days and over 100 million in the first two months. Here are a few ways ChatGPT, developed by OpenAI, can help boost productivity in your organization.

    Improve Their Code
    Sometimes manually written code snippets consume additional CPU resources. Using ChatGPT, developers can optimize their functions for better performance. Additionally, ChatGPT can also write test cases and spot security vulnerabilities in their code, helping developers work faster.

    Simplify Documentation
    ChatGPT can give a simple explanation for the layman, avoiding technical jargon to a large extent. For instance, a developer at Twitter fed ChatGPT their code and it responded with a pretty detailed explanation. Using ChatGPT to generate the first draft of a company’s internal documentation would make knowledge transfers easier. New hires could quickly get up to speed on the company’s codebase. Further, ChatGPT could also be used for external-facing documents where other developers can learn how to use the company’s APIs and frameworks.

    Test and Understand Code
    ChatGPT can write automated tests for code that is fed into it. Although many developers consider testing boring and stressful—and sometimes a waste of time—it’s a critical step in ensuring that published applications are bug-free.

    With ChatGPT, developers can output reliable, well-tested code much more quickly and easily. ChatGPT can also give high-level and line-by-line explanations of code and even teach developers how to use external modules and APIs in their own code, helping them build much faster.

    Debug Code
    ChatGPT makes a great debugging tool for developers. It can take in error messages and output information on the likely cause of the error and how to fix it. This is typically a lot more time efficient than browsing forums and blogs for a solution.

    The tool can also suggest helpful code alternatives. Many developers claimed that ChatGPT can be much faster and less mentally challenging than the conventional approach of searching the web for a solution.

    As the CEO of Replit, Amjad Masad, put it, “ChatGPT could be a good debugging companion; it not only explains the bug but fixes it and explains the fix.”

    Code Comprehension
    ChatGPT’s terabytes of training data come from various sources, including common crawl and WebText2. This training data makes it easy for ChatGPT to simplify explanations of complex pieces of code for developers. Therefore, developers can save time deciphering any code’s underlying logic and structure.

    For instance, Stanford instructor and well-known developer Matt Harrison used ChatGPT to build a simple graphic design tool. He explained, “I’m using ChatGPT to create a GUI program for drawing lines. I haven’t used QT [a development framework] in years, yet I can throw this together really quickly.”

    Generate Documentation
    Writing code documentation is often considered a mundane task by developers. With ChatGPT, developers can significantly cut down on the amount of time needed for documentation. For instance, they can expedite the creation of troubleshooting guides, tool user manuals and test cases by asking ChatGPT to perform code analysis and generate detailed technical reports. Accelerating this documentation process allows for easier onboarding of new developers and faster product release times.

    Writing Tests
    ChatGPT can analyze code snippets and automate testing for them, saving developers lots of time and helping them output reliable code. Test coverage is an essential metric for most enterprises, and ChatGPT could help streamline the process.

    ChatGPT Disadvantages

    While many developers have praised ChatGPT for increasing developer productivity, others have criticized it as unreliable. Let’s understand some key areas where the tool falls behind.

    Outputting Buggy or Unusable Code
    Developers have complained that the chatbot would sometimes output plausible-looking code that doesn’t work. This might result from misunderstanding the user’s requirements or simply being unable to come up with a correct answer—then faking it.

    Programming Q&A forum Stack Overflow even issued a temporary ban on ChatGPT-generated answers. The ban was because the chatbot generated an influx of answers whose average accuracy was pretty low. ChatGPT sometimes uses nonexistent commands and outdated modules in its code, so while they theoretically might make sense, they don’t work in practice.

    Writing Outdated Code (and Forgetting Previously Written Code)
    Since ChatGPT’s training data cut off in September 2021, the chatbot has no knowledge of the recent developments in programming languages and modules after that. As a result, ChatGPT often needs to use outdated commands, modules and paradigms in its code.

    ChatGPT also occasionally forgets the context within which it is working, affecting code output. Some users have reported that ChatGPT sometimes forgets about the task at hand and begins generating incompatible code.

    Security Concerns
    Security concerns are the biggest drawback to having developers work with ChatGPT. Open AI uses the data users input into ChatGPT to train the underlying AI model.

    Research by cybersecurity firm Cyberhaven has shown that 11% of the data employees input into ChatGPT is confidential. This presents a significant risk, as such data can be used in the chatbot’s next responses. Corporations like JPMorgan and Verizon have even gone as far as to block employees’ access to ChatGPT because of these concerns.

    Lacks Problem-Solving Skills
    A developer’s job is to understand the business problem and develop customized solutions to address it. Although AI/ML tools like ChatGPT help developers code faster, they can’t help in problem-solving or implementing a software application.

    Furthermore, when developers become overly reliant on AI-generated code, they’re discouraged from upskilling on new programming frameworks and languages. This can hurt the organization in ways that might not be evident immediately.

    To ChatGPT or not to ChatGPT

    As Google’s head of developer experience Bret McGowen said, “While AI will transform software development in many ways, human judgment, intuition and creativity will remain essential to building great products.”

    While ChatGPT may not be a perfect solution for every aspect of software development, it can be a useful addition when combined with human problem-solving skills. However, companies should be careful while allowing the usage of AI in day-to-day processes. Guidelines educating in-house developers on the fair usage of AI are a must to protect sensitive information and maintain a high-quality control process.

  • Are LLMs Leading DevOps Into a Tech Debt Trap?

    Are LLMs Leading DevOps Into a Tech Debt Trap?

    Everyone thought AI would free us from toil. Unfortunately, that’s not true. What it will do, however, is lead to an explosion of technical debt. Some of the most alluring uses of LLMs have the potential to lead to some of the worst outcomes for enterprises and their DevOps and platform engineering teams.

    SK Ventures and Adrian Cockcroft raised the alarm bells in their warning posts about the tipping points LLM introduced into work and society. And in my own Gluecon 2023 presentation, I challenged just how powerful and disruptive the new generation of AI/ML will be for ITOps and DevOps efforts.

    Working Faster is not Working Smarter

    There is no doubt that LLMs are powerful and will change how we think about expertise and knowledge work.  While they are not truly innovating, their ability to draw on such a vast pool of human expertise makes it difficult to distinguish from true creative work. Since they are unbounded, they will cheerfully use the knowledge to churn out terabytes of functionally correct but bespoke code.

    It’s easy to imagine a future where LLMs crank out DevOps scripts 10x faster. We will be supercharging our ability to produce complex, untested automation at a pace never seen before! On the surface, this seems like a huge productivity boost because we (mistakenly) see our job as focused on producing scripts instead of working systems.

    But we already have an overabundance of duplicated and difficult-to-support automation. This ever-expanding surface of technical debt is one of the major reasons that ITOps teams are mired in complexity and are forever underwater. Generating even more scripts, even if they were better written, does not reverse the trend.

    Can AI/ML Avoid This Technical Debt Trap?

    It depends on how we use the expertise in the models. Instead of asking it to generate new code, we could ask it to interpret and modify existing code. For the first time, we have tools to take down the “not invented here” barriers we’ve created because of the high cognitive load of understanding code. If we can help people work more effectively with existing code, then we can actually converge and reuse our systems. By helping us expand and operate within our working systems base, LLMs could actually help us maintain less code.

    Imagine if the teams in your organization were invested in collaborating around shared systems! We haven’t done this well today because it takes significantly more time and effort. Today, LLMs have thrown out those calculations.

    Taking this just one more step, we can see how improved reuse paves the way for reduction of the number of architectural patterns. If we improve our collaboration and investment in sharing code, then there is increased ROI in making shared patterns and platforms work. I see that as a tremendous opportunity for LLMs to improve operations in a meaningful way.

    It comes down to whether we ignore complexity by replacing it or embrace complexity by understanding it. I see this as a choice between independence or collaboration, as illustrated by the table below.

    LLM Driving Independence

    LLM Driving Collaboration

    Create new code

    Interpret existing code

    Replace existing code

    Maintain existing code

    Design new architectures

    Be a guide and mentor

    Build new stacks

    Evaluate alternatives

    Bypass documentation

    Improve documentation

    Can AI Help us Collaborate?

    We keep taking the same hardware and software components and then building unique systems. That variation makes it impossible to leverage each other’s work. At its heart, the reusability problem lies in the difficulty of understanding systems, and that makes it nearly impossible for us to work together, collaborate, reuse and accelerate.

    Breaking this cycle has been our mission at RackN for nearly a decade. We’ve seen tremendous ROI from availability, reliability and speed when customers are able to leverage standardized infrastructure pipelines. We’ve seen firsthand that it is possible to guide teams into collaboration with sufficient guidance, mentoring and training. Collaboration creates 10x outcomes even without AI, but it takes building expertise, deliberate effort and leadership discipline to implement.

    Why does collaboration create 10x ROI?  It works because true innovation actually comes from understanding and building on top of systems rather than rebuilding them from scratch over and over again. The key is being able to leverage LLMs to better understand existing automation and platforms instead of creating yet another bespoke stack.

    Enterprises Should use LLMs to Drive Collaboration

    I believe that the most effective enterprises will use these tools to elevate their IT leaders and architects to focus on collaboration and reuse. They must actually direct them to produce less bespoke automation; instead, they can use expertise in these tools to find and maintain existing systems. LLM presents options, but collaboration requires new thinking and strong leadership.

  • How AI Transforms DevOps Infrastructure

    How AI Transforms DevOps Infrastructure

    In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that the elastic infrastructure pillar involved automated provisioning and management of computing resources, often leveraging cloud-based solutions for scalability and resilience. This includes practices like infrastructure-as-code (IaC).

    In this article, I explain how AI can help manage cloud resources for DevOps by predicting future needs based on usage trends and automatically adjusting resources to optimize cost and performance.

    Here are some common DevOps use cases that IaC practices aim to address, along with potential AI tools that can assist in each scenario:

    Private and Public Cloud Agnosticism:
    • Use Case: Needing to deploy and manage infrastructure across multiple cloud providers or environments without vendor lock-in.
    • AI Tool Example: AI-powered cloud management platforms (e.g., Turbonomic, CloudHealth) can analyze resource utilization, performance and cost across various cloud providers to optimize workload placement.

    Reducing Infrastructure Configuration Bottlenecks:
    • Use Case: Avoiding manual and error-prone configuration processes that delay deployment and cause inconsistencies.
    • AI Tool Example: Intelligent configuration management tools (e.g., Puppet, Chef, Ansible) can automate the provisioning, configuration and management of infrastructure resources.

    Infrastructure Cost Optimization:
    • Use Case: Optimizing resource allocation and minimizing infrastructure costs.
    • AI Tool Example: AI-driven cost optimization platforms (e.g., ParkMyCloud, Cloudability) can analyze usage patterns, recommend resource resizing or right-sizing and suggest cost-saving opportunities.

    Infrastructure Sharing:
    • Use Case: Sharing infrastructure resources securely across multiple teams or projects.
    • AI Tool Example: AI-powered resource scheduling and sharing tools (e.g., Kubernetes with cluster autoscaling) can dynamically allocate and release resources based on demand and workload requirements.

    Infrastructure Quality:
    • Use Case: Ensuring consistency, reliability, and adherence to best practices in infrastructure deployments.
    • AI Tool Example: AI-based infrastructure validation tools (e.g., Terrascan, Checkov) can scan IaC templates, provide security and compliance checks and offer recommendations for improvement.

    Infrastructure Security:
    • Use Case: Integrating security controls and policies into the infrastructure deployment process.
    • AI Tool Example: AI-driven security tools (e.g., Aqua Security, Sysdig Secure) can analyze infrastructure configurations, detect vulnerabilities and enforce security policies during deployment.

    Dynamic Orchestration:
    • Use Case: Needing to dynamically manage and scale infrastructure resources based on workload demands.
    • AI Tool Example: AI-powered orchestration platforms (e.g., Kubernetes with horizontal pod autoscaling) can automatically scale resources up or down based on metrics such as CPU utilization or request latency.

    Integration and Control of Infrastructure with CICD Pipelines:
    • Use Case: Seamlessly integrating infrastructure provisioning and deployment with CI/CD pipelines.
    • AI Tool Example: AI-enabled CI/CD platforms (e.g., Jenkins with ML plugins, Harness) can leverage machine learning algorithms to optimize pipeline execution, provide intelligent recommendations and automate release processes.

    Monitoring Infrastructure Performance:
    • Use Case: Monitoring and ensuring the optimal performance of infrastructure resources.
    • AI Tool Example: AI-powered monitoring solutions (e.g., Dynatrace, Datadog) can leverage machine learning to detect anomalies, predict performance issues and provide actionable insights for infrastructure optimization.

    Rapid Restore of Infrastructure:
    • Use Case: Quickly recovering and restoring infrastructure in the event of failures or disasters.
    • AI Tool Example: AI-driven backup and recovery tools (e.g., Veeam, Rubrik) can automate backup processes, intelligently prioritize data restoration and leverage machine learning for predictive data recovery.

    Challenges With the Transformation to AI-Engineered Infrastructure

    An organization may face a number of challenges when transitioning to AI tools for infrastructure, as follows:

    Lack of Expertise and Skill Set:
    • Challenge: Organizations may lack the necessary expertise and skill set to implement and operate AI tools effectively.
    • Solution: Invest in training and upskilling programs for employees to acquire the required knowledge and skills. Partnering with external consultants or hiring experts in AI and infrastructure can also bridge the expertise gap.

    Data Availability and Quality:
    • Challenge: AI tools heavily rely on high-quality data for training and accurate decision-making, but organizations may face challenges in obtaining relevant data and ensuring its quality.
    • Solution: Implement robust data governance practices to ensure data availability, quality and consistency. Invest in data collection, storage and processing frameworks that support AI initiatives. Data cleansing and preprocessing techniques can be employed to improve data quality.

    Integration Complexity:
    • Challenge: Integrating AI tools into existing infrastructure and workflows can be complex, especially when dealing with legacy systems and heterogeneous environments.
    • Solution: Plan for seamless integration by conducting a thorough assessment of existing systems and infrastructure. Leverage APIs, automation frameworks and standardized protocols to enable smooth integration. Adopt modular and scalable architectures that facilitate the incorporation of AI components.

    Ethical and Legal Considerations:
    • Challenge: AI tools introduce ethical and legal considerations, including privacy, security, bias and regulatory compliance, which can pose challenges during infrastructure transformation.
    • Solution: Develop clear guidelines and policies around data privacy, security and ethical considerations. Perform rigorous testing and validation to detect and mitigate biases in AI models. Engage legal and compliance teams to ensure alignment with relevant regulations and standards.

    Change Management and Cultural Shift:
    • Challenge: The adoption of AI tools often requires a cultural shift within the organization, including changes in mindset, processes and collaboration between teams.
    • Solution: Develop a change management strategy to communicate the benefits of AI tools and address any concerns or resistance. Foster a culture of experimentation, learning and collaboration. Encourage cross-functional teams to work together and share knowledge. Provide ongoing support and training to ensure successful adoption and adaptation to the new tools and practices.

    Summary

    Incorporating AI into IaC practices for DevOps brings transformative benefits that drive efficiency, agility and scalability. By leveraging AI tools, organizations can optimize resource allocation, streamline deployments, enhance security and improve performance monitoring. Embracing AI for IaC empowers teams to automate and intelligently manage infrastructure, resulting in faster time-to-market, cost savings and increased productivity. Unlock the full potential of DevOps by embracing AI and revolutionize your infrastructure management with the power of intelligent automation.

    It’s important to note that challenges and solutions are to be expected when transforming to the use of AI, and the specific context and requirements of each organization may vary. Therefore, it’s advisable to assess the organization’s unique needs and constraints to tailor the solutions accordingly.

  • Why Your Data Lake Strategy is Broken for Observability

    Why Your Data Lake Strategy is Broken for Observability

    Someone once said, “Life is better at the lake.” That may be true in the physical world, but when it comes to using data lakes for observability, that’s not typically the case.

    Just about every organization in every industry has a digital presence, whether it’s a website, an app or another digital service. This makes observability a universal need; it helps teams monitor software performance, optimize performance, detect potential security issues and quickly monitor for bugs if and when they occur. These responsibilities typically fall on engineering teams and require as close to real-time response as possible.

    Some organizations also have business intelligence (BI) needs, aimed at generating insights from multiple data sources for business decision-making. These responsibilities typically fall on business decision-makers; they are not real-time decisions, but rather made by looking back over long time periods.

    All-In on a Data Lake Strategy

    Companies that go all-in on a data lake strategy may ignore the needs of the engineering teams working on the real-time mission-critical aspects of the business and force all of the company’s data, queries, dashboards, etc. into a data lake solution. That doesn’t actually meet the needs of the engineering teams. The result? Engineering teams use unsanctioned solutions, fracturing the company’s data strategy from the ground up.

    By using a standards-based observability solution built on open source InfluxDB 3.0, companies can give their engineers the observability tools they need while preserving their data lake strategy.

    Here are three main challenges that teams come across when using data lakes for time-series, and how to solve the problem with InfluxDB 3.0.

    Problem One: Inefficient and Slow Ingest
    Data sources generate time-series data at an incredibly high rate, easily producing hundreds or thousands of data points every second; some sources even do so as quickly as every nanosecond. Data lakes can store massive volumes of data, but they aren’t optimized to quickly ingest and make it readable on a millisecond time scale.

    Data lake ingest jobs can be measured in minutes or even hours, which is far too late for any meaningful interventions that can prevent catastrophes such as downtime. Customers will notice the outage before the data is even ingested into the data lake, much less acted upon.

    Problem Two: Time-Series Life Cycle
    Full-fidelity data is necessary for real-time analytics and observability, but the value of the full-fidelity data fades over time. Storing the full-fidelity data in a data lake may be convenient, but it is costly and not necessary for typical BI purposes.

    InfluxDB is designed for the time-series data life cycle. This life cycle entails:

    1. The leading edge of data. That is, data written in the last two hours or so. This is the data that is most likely to be queried, so the full fidelity data is kept in memory ready to query instantly.
    2. Compacted data. That is, data older than the leading edge that is still likely to be queried and requires full fidelity is compacted off to disk in object store, which still permits fast querying but does not incur the costs of storing data in memory.
    3. Retention policies. That is, data that has lost its value in its full fidelity form. For example, for observability data, data older than a few weeks can be aggregated into a much smaller data footprint. Then, this aggregated data is ingested into the company’s data lake while the full fidelity data is automatically dropped from InfluxDB 3.0.

    Without such a system, it is necessary to store the full fidelity data in the data lake and incur those massive costs without a reasonable way to manage the life cycle of the data. With such a system, the correct amount of observability data can be ingested into your data lake to support your BI needs.

    Problem Three: Slower Query Performance
    Engineers can experience a high degree of frustration when they are troubleshooting an issue in real-time, but their dashboards won’t load or their queries won’t return in a reasonable amount of time. Data lakes simply are not designed to produce fast results for observability, and so query performance is a primary complaint of engineers trying to use a data lake for observability. Waiting minutes for a query to return when you are running a BI report may be annoying, but it could spell extended downtime for an engineering team.

    Fortunately, InfluxDB is built on the Apache Arrow standards, which means that it can be directly queried by your engineering team. Via protocols such as Delta Sharing and Iceberg, anyone can query into InfluxDB 3.0 from their data lake and join the real-time observability data stored in InfluxDB 3.0 with the data lake data. This is akin to having your cake and eating it too.

    The Bottom Line

    If you are trying to use a data lake strategy to fulfill your engineering team’s observability needs, you are going to frustrate those teams because the data lake is not designed for data ingestion, the data life cycle, or the query needs of those teams. This will cause those teams to create rogue solutions that are inconsistent with your company’s data lake strategy.

    By providing those teams with open source InfluxDB 3.0, engineering teams will have a first-class observability platform that is designed to interoperate sensibly with your company’s data lake. This enables the critical mission of your observability platform while maintaining your overall data lake strategy for your BI needs.

  • How AI Addresses DevOps Monitoring and Observability Challenges

    How AI Addresses DevOps Monitoring and Observability Challenges

    In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that the continuous monitoring pillar involves monitoring observable systems and application performance in real-time so that teams can detect and react to problems quickly, often before they impact users. It’s crucial for maintaining application health and informing future improvement efforts.

    In this article, I explain how AI can analyze logs and metrics to predict potential system failures or performance degradation, allowing for proactive maintenance and issue resolution.

    Continuous Monitoring and Observability Use Cases

    CI Anomaly Detection: AI can analyze historical data to detect anomalies during the continuous integration phase. Any unusual change can be flagged for review before it proceeds to the next phase. Tools like IBM Watson Anomaly Detection can help identify these anomalies by using AI to detect patterns and irregularities.

    Code Quality Assurance: AI can be used to analyze the code in the development stage to ensure its quality, which can help reduce bugs and vulnerabilities. Tools like DeepCode and Codota use AI to identify potential problems and suggest improvements based on a learned database of code and solutions.

    Test Case Optimization: AI can help optimize the selection of test cases in continuous integration (CI). Using historical test data, AI can identify which test cases are most likely to find new defects. Tools like Testim.io can help with this by using AI to prioritize testing based on risk and change impact.

    Predictive Analytics in CD: AI can analyze historical deployment data and predict potential issues during continuous delivery (CD). This can help preemptively solve problems, reducing downtime. Tools like Splunk use AI and machine learning to provide predictive analytics for operations data.

    Automated Rollbacks: In the case of continuous deployment, AI can be used to automatically roll back deployments that are causing issues. Tools like Harness use machine learning to understand typical application behavior, automatically reverting to the last stable state if anomalies are detected.

    Infrastructure Optimization: AI can help optimize the usage of resources in cloud environments. Tools like CAST.AI and Turbonomic use AI to continuously optimize your infrastructure, ensuring better performance while reducing cost.

    Incident Management: AI can help automate the incident management process, from detection to resolution. Tools like BigPanda and Moogsoft AIOps use AI to aggregate, correlate and analyze alerts from various sources, reducing noise and speeding up incident resolution.

    Log Analysis: AI can analyze logs and identify patterns that would be difficult for humans to spot. Tools like Logz.io use AI to provide cognitive insights into log data, providing a deeper understanding of the data.

    Security Threat Detection: AI can analyze patterns and detect security threats more effectively. Tools like Darktrace use machine learning to detect unusual behavior in real-time, thereby detecting potential threats before they cause damage.

    Network Monitoring: AI can predict network outages by analyzing traffic patterns. Tools like Kentik use AI to proactively identify potential network issues before they affect users.

    Challenges When Transforming Continuous Monitoring to use AI

    Here are some challenges organizations might face when transitioning existing CI/CD pipelines to incorporate AI into continuous monitoring and observability, along with possible solutions:

    Data Quality and Availability: The effectiveness of AI-engineered tools largely depends on the quality and quantity of the data they’re given. Insufficient or poor-quality data can result in inaccurate insights or predictions. Implement effective data governance and management practices to ensure data quality and accessibility. Data should be thoroughly cleaned and properly labeled to facilitate the training of AI models.

    Skills Gap: Adopting AI-engineered tools requires new skills that the existing IT team may not possess. There might be a lack of understanding of how to use these tools effectively. Provide comprehensive training to your DevOps team to bridge the skills gap. Also, consider hiring AI specialists or working with an experienced vendor to help implement and manage the AI tools.

    Resistance to Change: As with any significant transformation, resistance to change can be a substantial barrier. Employees may be concerned about job security or the perceived difficulty of adapting to new tools. Communicate clearly and transparently about the benefits of the AI transition, both at an organizational and individual level. Ensure staff that AI is there to assist them, not replace them. Organize workshops and training sessions to ease the transition.

    Integration with Existing Systems: AI tools need to integrate seamlessly with existing DevOps tools and workflows to ensure that they add value without disrupting operations. Choose AI tools that are compatible with your existing infrastructure or consider implementing integration middleware. Conduct a proof-of-concept (PoC) to ensure the new AI tools integrate smoothly.

    Cost of Implementation: Deploying AI tools can require a significant upfront investment, both for the tools themselves and for necessary infrastructure upgrades. Conduct a thorough cost-benefit analysis to understand the return on investment (ROI) that the AI tools can deliver. Consider starting with lower-cost or open source tools or use cloud-based AI services to reduce initial investment in infrastructure.

    Summary

    As the world of DevOps evolves, the integration of AI in monitoring and observability becomes increasingly important. Whether it’s during the phases of continuous integration, continuous delivery or continuous deployment, or for applications, infrastructure and pipelines, AI can provide exceptional benefits. From anomaly detection in CI, code quality assurance and test case optimization to predictive analytics in CD, AI can transform your operations, delivering rapid and more reliable results.

    However, transitioning to an AI-optimized DevOps environment is not without its challenges. Issues such as data quality, the skills gap, resistance to change, system integration and cost implications must be considered and addressed. But fear not, solutions are at hand. With effective data governance, comprehensive training, transparent communication, smart tool selection and thorough cost-benefit analysis, you can navigate these challenges and reap the rewards of AI integration in your DevOps journey. So, are you ready to embrace the future of AI-driven DevOps? There’s no time like the present to start exploring the possibilities.

  • Harnessing AI in Continuous Delivery and Deployment

    Harnessing AI in Continuous Delivery and Deployment

    In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that the continuous delivery pillar is an approach where code changes are automatically built, tested and prepared for release to production; this may be followed by continuous deployment where an approved release is automatically deployed to the production environment. The practices of the CD pillar aim to make releases and deployments less disruptive and more frequent, increasing speed and efficiency.

    In this article I explain how AI can help continuous delivery and deployment processes.

    Continuous Delivery Use Cases

    Orchestration of Test Environments: Teams need a reliable way to prepare and manage various test environments. This includes setting up and tearing down environments, managing versioning and configuration and handling data and resources. AI tools that can help include Harness, and IBM’s UrbanCode, which can automatically spin up and down environments for testing purposes and handle configuration as code.

    Execution of Various Tests: This includes system acceptance tests, regression tests, performance tests, user acceptance tests and security tests. The AI tool that could help here is Parasoft’s SOAtest. Its AI can generate test scenarios, ensure full coverage and automatically adapt to changes in the code base.

    Performance Monitoring of Release-Candidate-Artifact: Tools need to assess the performance of release candidates, identify bottlenecks and compare performance against previous versions. Dynatrace is an AI-powered tool that provides automatic and dynamic baselining of application performance, helping teams to recognize when performance is lagging.

    Automation of Policies for Artifact Acceptance: Rules and policies need to be defined and enforced regarding when an artifact is ready for release. Tools like Harness use machine learning to analyze past deployments and test results to predict the success of future deployments and automate the approval process.

    Continuous Deployment Use Cases

    Orchestration of Deployment Environments: Teams need to manage deployment environments, including setup, versioning, configuration and data management. Spinnaker is an open source tool that uses AI to manage multi-cloud deployment strategies.

    Execution of Deployment Strategies: This includes executing strategies such as Blue-Green, Canary and Feature Flag gradual rollouts. A tool like LaunchDarkly can utilize AI to manage feature flags, analyze usage data and roll out features gradually.

    Testing in Production: Testing the new release in the live production environment is crucial. A tool like Sentry can use AI to monitor application use in real-time and identify and alert teams to issues faster.

    Restoring Production to a Prior Version: When a problem is detected with a new release, teams may need to revert to a previous stable version quickly. StackStorm is an event-driven automation platform that uses AI to define workflows, allowing you to quickly roll back to a previous version in case of failure.

    Updating Documentation and Configuration Management Databases: It’s crucial to keep records up-to-date. A tool like Guru uses AI to automatically update and keep track of documentation, ensuring that it’s always accurate and up-to-date.

    Challenges When Transforming CD to use AI

    Here are some challenges organizations might face when transitioning their existing CI/CD pipelines to incorporate continuous delivery, continuous deployment and AI tools, along with possible solutions:

    Lack of understanding of AI capabilities and uses: One of the first challenges that organizations might face is the lack of understanding of what AI can and cannot do. Some team members may have unrealistic expectations or fear that AI will replace their jobs. Regular training and workshops can help teams understand how AI can enhance their roles rather than replace them. Clear communication about the goals and benefits of incorporating AI can also help allay fears.

    Data privacy and security concerns: Using AI tools often involves handling a large amount of data, some of which may be sensitive or private. There are also concerns about the security of AI tools themselves. Establish a robust data governance policy that includes procedures for handling sensitive data. Also, when selecting AI tools, prioritize those that are known for their robust security measures.

    Complexity in integrating AI tools with existing systems: Not all AI tools will seamlessly integrate with existing systems and infrastructure. This could lead to technical debt and instability in the pipeline. Prioritize AI tools that have wide integration capabilities. Engage the tool’s support team or hire consultants if needed to ensure the integration is smooth and stable.

    Resistance to change: The transition to a new way of working can be met with resistance, especially if team members are comfortable with the existing systems and processes. Change management strategies can help ease the transition. This can involve regular communication about the benefits of the change, training and providing support during the transition.

    Cost of AI tools and training: AI tools can be expensive, and there’s also the cost of training team members to use these tools. Start with a cost-benefit analysis to understand if the transition is worth the investment. Look for AI tools that offer a good balance between cost and features. Consider phased implementation to spread the costs over time.

    Dependence on vendor support: Given the complexity of AI, there may be a high dependence on the AI tool vendor for support. This could become a problem if the vendor is unresponsive or ceases to support the tool. Choose vendors who have a good track record of providing strong customer support. Also, consider tools that have a strong community around them, which can provide additional sources of help and support.

    Summary

    Navigating the landscape of continuous integration, continuous delivery and continuous deployment (CI/CD) pipelines can be complex, but it’s a vital process that’s being revolutionized by the introduction of AI tools. From orchestrating test and deployment environments, managing testing and deployment strategies, to automating delivery tasks and quality checks, AI is playing an increasingly critical role in streamlining and enhancing these processes.

    However, as with any significant change, transitioning to AI-enhanced CI/CD pipelines is not without its challenges. This includes understanding AI’s capabilities, data privacy and security concerns, technical integration difficulties, resistance to change, cost considerations and vendor support dependencies. By identifying and addressing these challenges head-on, organizations can effectively leverage AI’s capabilities, bringing increased efficiency, reliability and value to their software delivery pipelines.

    With proper planning, continuous learning and strategic use of AI tools, organizations can not only overcome these challenges but also thrive, gaining competitive advantages in their software delivery processes. The future of CI/CD is undeniably entwined with AI, and embracing this evolution is an exciting journey that holds the promise of transformative benefits.

  • How Platform Engineering Protects Profit, People and our Planet

    How Platform Engineering Protects Profit, People and our Planet

    Platform engineering is emerging as a way of evolving DevOps, with 94% of respondents to the recent State of DevOps report agreeing that the practice helps their organization to reap the benefits of DevOps. The business arguments for platform engineering are clear: In that same report, respondents stated that platform engineering improves efficiency (59%), speeds up delivery time (58%) and improves workflow and process standards (57%).

    But in addition to the huge benefits organizations are now realizing in terms of business value, platform engineering is also pretty crucial for a business’s long-term viability. And by that, I mean that platform engineering can be inherently sustainable.

    How Can Platform Engineering Be Sustainable?

    First, it’s important to note that ‘sustainability’ here doesn’t just mean ‘green.’ Rather, sustainability means that an organization is able to meet the needs of the present without compromising the ability of future generations to meet their needs, too. These are needs that come in three different varieties: People, planet and profits.

    This means that to be truly sustainable, platform engineering needs to deliver lasting and stable returns on things like return on investment year-over-year, improved awareness of and reduction in an organization’s carbon footprint and better governance and optimization through monitoring and analytics.

    Any approach which supports business growth while simultaneously empowering employees and being kind to the planet is the dream for pretty much every organization. But how exactly can departments and wider organizations unlock all of these benefits? The answer is: There’s no magic bullet.

    Sustainable platform engineering is about treating your platform as an iterative cycle: It isn’t the actual creation of the tool that matters, as much as it is the maintenance, upkeep and usability of the platform as your business moves forward. This, naturally, will take time, effort and money—all of which, it’s safe to say in the current climate, are in short supply. But it is crucial that businesses act strategically, looking for areas for improvement and paths that will all add up to a more sustainable business in the long term.

    The Three Paths to Success

    These paths can be divided into three main areas of focus, and the first is GitOps or infrastructure-as-code (IaC).

    A tweak that every organization should start making is using Git as a single source of truth for deployments, enabling developers to work faster by empowering them to use their own code without hands-on involvement from ops teams. This could be combined with optimized infrastructure, moving toward IaC to enable faster and more efficient deployments.

    These principles form the foundation of sustainable platform engineering as they protect profits, allowing the business to keep moving forward and investing in the other areas crucial for a sustainable operation. Combining IaC with GitOps ensures speed and simplicity while maintaining a high-quality end product.

    Creating an optimized infrastructure is important, but just as important is empowering employees to feel good about the work that they are doing. That’s why implementing a self-service tool alongside an optimized UX is the second area of focus. This removes the pressure on those in the tech department to be infrastructure experts while erasing the need for endless tickets to be raised for issues.

    By freeing up DevOps engineers and platform experts to spend more time doing what organizations need them to do, businesses can keep innovating to maintain an edge over their competitors. Self-service capabilities combined with an accessible UX are a useful combination for a much-improved developer experience (DevX).

    Finally, it’s important to keep in mind that self-service isn’t just going to benefit end-users; it also has major upsides for improved governance, as well as keeping control of cloud spending and carbon footprint impact. Optimizing and iterating your platform engineering tool means that a business can keep up with the fast pace of the global tech market while also continuing to implement the latest tweaks and upgrades. It all adds up and builds on the organization’s platform engineering solution.

    Reaping the Rewards of Sustainability

    If an organization follows the above three paths, it is well on its way to a more sustainable business powered by platform engineering. By focusing on targeted, achievable projects to build a solid foundation, organizations can achieve big benefits for people, the planet and profit.

    From an economic perspective, sustainable platform engineering ensures legacy infrastructure is modernized, silos are broken down and production is accelerated, all ensuring the business doesn’t risk lagging behind competitors. A stable and secure return on investment is key to sustainability in the medium to long term, and sustainable platform engineering ensures a business is able to weather future challenges and keep a healthy profit margin.

    As we all know, underpinning any great business is the people who work there. Techs get stressed by having to interact with infrastructure they know nothing about, DevOps and specialists get stressed when those techs desperately raise tickets in an attempt to get help, and platform engineers get stressed when the weight of providing a solution to these problems rests squarely on their shoulders. Implementing a UX-strong self-service portal relieves the pressure, allowing employees to focus on delivering real value to the business through innovation. A better DevX ultimately leads to better business outcomes.

    And, of course, it’s ultimately no good having a successful business if the planet we all share continues to suffer from the effects of the climate emergency. Just like a business that hemorrhages money is unsustainable, so is a planet that wastes its finite resources. By getting control of cloud usage and controlling cloud climate impact, businesses will not only be empowering their people and improving their bottom line, but they will also be making a tangible difference to our shared environment, supporting our planet as it recovers from years of climate neglect.

    Platform engineering offers lots of tangible benefits for businesses, but sustainable platform engineering can be even better, not just for a business, but employees and our shared environment. It might just be time to upgrade DevOps and start thinking about building a sustainable organization that supports profit, people and the planet.

     

  • How Can DevOps Evolve? Platform Engineering

    How Can DevOps Evolve? Platform Engineering

    Kaylee Van De Voorde co-authored this article.

    Has your team adopted a DevOps mindset? Are your engineers using tools like Docker containers, Kubernetes and Terraform? Over the last decade, many engineering teams that adopted DevOps culture and pivoted to cloud-native applications that required rapid scaling may face a new set of problems. 

    DevOps

    DevOps practices have brought operations and software engineering teams together throughout the entire development life cycle, from initial concept through the engineering process to production support. This collaboration paved the way for iterative development: Improving velocity, providing rapid feedback and consequently improving application quality by uncovering bugs and environment requirements earlier without user impact. DevOps automation created a more “blameless” culture that improved trust, collaboration and innovation, which boosted team morale and increased engagement. 

    That said, DevOps teams have encountered many obstacles, including fears of job obsolescence and steep learning curves for every member. Teams that learned how to implement DevOps practices on their projects may have moved more slowly at first while learning how to work together in new ways and adopting new tools.

    What is Platform Engineering?

    So, what is platform engineering? Platform engineering bridges the existing gaps between software, hardware and infrastructure that come with adopting DevOps practices: Automated horizontal scaling, service discovery and cost optimization. Platform engineering makes it even easier and simpler for engineers produce high quality applications quickly by standardizing CI/CD deployments, ensuring that infrastructure is auditable and monitored, automating deployment methods and processes, providing accurate documentation and incorporating FinOps.

    Platform engineering teams can make these improvements available to their teams by creating tools such as an internal developer platform (IDP) that includes APIs that expose internal tools and features within the platform. 

    The Next Evolution

    Evolution does not mean starting from nothing.

    The core tenets of DevOps practices still hold their value; aligning software engineering and operations teams to better create applications that embody business and user functionality and run smoothly within an incorporated infrastructure, automation, security and dedicated site reliability engineering (SRE). Many DevOps teams may already be moving toward an overarching platform engineering culture and simply need to refine their standards. Distinct application teams may already be building similar features to provide platform functionality; a strong indication that a platform engineering team would be beneficial.

    Choosing to create a dedicated platform engineering team has tradeoffs: Building a platform engineering team pulls resources from building applications and new features that the business needs, but application teams could experience an increase in productivity if a separate platform engineering team is created. A dedicated platform engineering team can also provide clear, unified direction and nuanced goals for application teams; this is incredibly important when creating standards and internal tools.

    A platform engineering team is just one way that to advance and improve engineering culture. DevOps teams that may not require platform engineering can continue their growth by refining their existing practices and patterns in their everyday work. 

  • How IT Services Can Embrace Platform Engineering

    How IT Services Can Embrace Platform Engineering

    We are all familiar with DevOps as a newer approach to software development. The concept is designed to enable developers and IT operations teams to work together. Platform engineering, on the other hand, is a more mature, older approach that has become new again.

    Platform engineering, at its core, is the concept of productizing your internal development platforms to make it easier for developers to work. It is an emerging technology approach that can help accelerate the delivery of applications and the pace at which they produce business value. More recently, companies have grown their complex software architectures which have created silos for the teams that manage these various architectures. There may be multiple teams with various specialized skill sets and a single DevOps engineer who takes care of the continuous integration (CI) jobs to deploy and release to production.

    Now let’s imagine that you have 10 squads that focus on building and maintaining different applications. Now all of these teams are building and operating 10 different platforms to run their applications, which creates inefficiency across the teams and reinforces silos. In this scenario, teams may spend half of their time building and maintaining the platforms instead of delivering business value. This creates a large cognitive load on developers.

    This model becomes very hard to scale. Even though you have these squads managing their own infrastructure and platforms, you may find gaps because there is no centralized standard. So how do platform engineering concepts help with these complex landscapes and boost efficiency?

    The Consulting Mindset

    Platform engineers take all of the tools used to run an application across your various teams and standardize their usage. This enables self-service capabilities for your engineering organizations. Platform engineering can help centralize how you are deploying and running your applications across a complex software landscape. This includes not only the standardization of tools being used but also documentation and processes.

    Establishing platform teams requires a consulting mindset and thinking about what resources, services and components can be centralized to better serve the rest of the organization. Some may refer to this as the center of excellence (COE) model, or simply IT for IT. This boosts efficiency and cuts down the time to delivery by providing a central set of tools and platforms for your engineering organization. Many may see platform engineering as a cost center, but the ROI is higher-quality releases, a standardized way of developing and delivering software and shorter delivery times.

    Applying This Concept to IT Services Firms

    In my consulting days, I worked for firms that focused on delivery for the Salesforce platform. We often had complex projects that we needed to deliver for large enterprise customers who had multiple applications integrating into their CRM. Each project team often had a different way of delivering and developing based on the customer’s needs. This created specialized skill sets, but we had no standard way of developing and delivering. Investing in a platform engineering team to support the delivery organization can add immense benefits for large consulting firms, enabling them to standardize the tools and platforms being used to run and deliver applications at scale.

    Having a centralized place for your developers to go for process, documentation and tools to help them build and run applications can increase the speed at which they deliver. The efficiencies gained in having a smoother self-service flow for your developers and cutting down the delivery time are worth the investment. It brings significant long-term value that the customer will experience long after the engagement is completed, which can greatly impact future considerations for your firm.

    IT services firms should find ways to align and centralize their technologies with platform engineering concepts. You may not be able to exactly build out an internal developer platform, but adopting some of the core concepts will help you be more efficient as an organization. For example, if you are an IT services firm specializing in delivering applications on the Salesforce platform, look for extensible DevOps platforms that can support your development organizations.

    Also, look for ways to enable a self-service workflow to make it easier for your developers to work and scale. This may include investing in a platform engineering function to support the rest of the delivery organization. By establishing platform engineering concepts, you will be able to cut down the delivery time and create consistency in how you deliver and deploy applications for your customers.

  • Must You Collect All That?

    Must You Collect All That?

    It is interesting that we no longer consider teams that super-tool their apps as being slightly ‘off’ or, working in a field where systems were mission critical, even life-and-death. Now, we all are collecting and reporting data points in real-time across not just the SDLC, but across the entire environment. It is wild the amount of data available to the average DevOps team about what is going on with their applications. But it’s not all being used.

    No, seriously, it is unreal. Let me offer two anecdotes that explain why I know you’re not using it all.

    Most of my regular readers know that I worked at F5 for years, the first couple on the DevCentral team, doing the Dev part. Their flagship product, the BIG-IP, collected an incredible amount of super-granular data. I am not exaggerating when I say an incredible amount. They had data points from the wire up to the traffic routes through the load balancing algorithm to nodes. And it was (and likely still is) all available to users via APIs. Whatever data was needed about traffic passing through the BIG-IP or the nodes behind the BIG-IP and the connections in between users and those nodes, you could get.

    One of my projects was to offer a simplified interface to the APIs. They were complex and granular, and customers wanted fast and easy, so I was publishing code that worked as an intermediate layer.

    Note: F5’s APIs, like everyone else’s, are far more advanced today than they were then, and it is easier to do what you need to do because they took the “create a user layer” part seriously. It’s complex machinery so it still has complex APIs, but accessibility is way up from those early days.

    Anyway, BIG-IP collected so much data that I could not name all of the fields, let alone when each one was pertinent. I gave up trying after a while, because if a board-level engineer needed a data point, the idea at the time was “Why not expose it?” so ‘number of connections to a given node’ under this algorithm was hidden among things like ‘microseconds to connect to DNS on that connection’ (I’m making those up; it’s been years). Some were terribly useful to end users and others were not. All were accessed in the same way, and learning by experimenting was the only real way to tell the difference.

    Users did not need all of that data. Users did not need the complexity and obfuscation created by supporting all of that unnecessary data.

    My other example is a massive system of interconnected IoT devices that were centrally connected/controlled with a private, specialized network to manage them (actually, there were several different networks on several different mediums, and that matters where data points are concerned).

    When setting this system up, we estimated about half a million IoT devices with capabilities that ranged from passive monitoring to active controllers of physical devices. Four different communications mechanisms, a couple dozen different devices, every major (and a couple minor) databases and command-and-control software on every major OS, managing from a handful to hundreds of thousands. And all of these were super-tooled because the IoT network was mission-critical. Our databases and the infrastructure to support/protect them were a major part of our data center budget because of the amount of data.

    The amount of data was a flood. The management software was developed by different companies with different transports and endpoints in mind, meaning each had a different dataset. Once all of the networks were running satisfactorily, our next immediate project was to create a unified dataset for reporting and troubleshooting. I was in charge of IT, but the top-level person–because each of those half a million devices was a physical install–was a physical engineer. We fought non-stop about what was important. I was trying to map and convert datapoints between systems; he was trying to maximize data available for reporting up. He often said, “Well no, we don’t need that today, but we might.” This put us in a zone where “number of devices on this system” was on par with “attenuation of the communications line to the nodes on this physical subnet.” Totally unworkable, and our compromise was to put together a small IT team to put a layer over all that raw data and offer an intelligent interface side-by-side with data dumps.

    We are there again today. I hear many of my friends in the enterprise space saying, “Because of ML, we might need that data and storage is cheap.” I disagree. Storage is an overhead that is wasted if you are not actively using the data. We are past the “all data is good data” craze; it’s time to adapt. Useful data that expands insights is all you need tooling for. Report data that will help solve problems, and if the team finds tomorrow that it needs a data point that is not currently collected, it can be added in.

    There is room for debate here–the rate of change for ML systems (please stop calling them AI; they’re not, yet, and we’ll need that word when they are cognizant) means that there is a reasonable argument for “all of the data.” And I’m not proposing limiting data collection. Honestly, application security specifically and enterprise IT security overall has benefitted from datapoint sharing between formerly separate market spaces. If the SCA scan shows X framework is used, then the IAST can narrow down tests to those that look at X and not its competitors, for example. But honestly, don’t drown yourself in a data lake when all you need is a fish tank where you can see all the guppies.

    And keep rocking it. Even if you entered IT two years ago, you are now a seasoned vet and things have changed–beyond all of our expectations, I’d say. Yet you’re still plugging away, keeping the enterprise running. Don’t stop—just try to keep the data hoarding to a reasonable level and make sure the data you have is being used, whether as useful feeds to an ML tool or as consumable information for other people/systems.