Category: DevOps Practice

  • In DevOps, Chatbots are a People Problem

    In DevOps, Chatbots are a People Problem

    By now, you are undoubtedly aware that you can call up a chatbot or install an AI assistant into your IDE and generate entry-level code and deployment scripts.

    Indeed, if you just go to a site like ChatGPT and enter “generate Python code to do X” where X is something you need to be done–or an example like “read a file and print out the contents one line at a time,” it will do it. And if you keep it simple, it will do it well. If you say “again, in Java,” it will comply and do it well.

    Then say “new chat,” and tell it to “write a bash script to deploy an app named X written in Java and using Gradle to a cluster named Y,” it will do that also, informing you of the names of the deployment and service YAML files. Then you can say, “generate the deployment file mentioned,” and it will. And then you can say, “parameterize the Java version,” and it will do that, too. This iterative revision can continue until the deployment code, containers and deployment files are complete. If you have not yet, I urge you to spend the half hour going through these steps once required, so the potential is obvious.

    It is not yet to the point where I would (or you should) trust it with complex systems, but all of that busy work we’ve been trying to overcome with templates and preconfigured containers? We can actually get around the bulk of it now. The same is true for testing of all kinds. There are tools that will auto-generate test scripts for a given set of source code. They will also generate test execution code. That means that the only step left—and the one that has held testing back because of the volume of work—is reviewing results … But wait, there’s more! In security testing, AI can help eliminate false positives. In performance or QA testing, it can filter out all but the most egregious issues (as defined by the org or by a larger pool of apps).

    The problem we need to address today is the people issue. What we have traditionally used entry-level people for—and trained them in Dev/Ops/DevOps with—is no longer necessary. Because the AI can do it. That is stunning and really very cool, if you think about it.

    But it heralds a danger that every org needs to be aware of. What we do and how we do it is changing. For the better, but change always brings uncertainty, and the foreseeable bit we need to confront is, “Now that we don’t need entry-level people for these steps, how do we recruit and train them?” I do not yet have a definitive answer for this question, because I am a product of my time, so I see things in terms of learning the bits that make up the whole—advising people interested in DevOps to learn at least one Linux command shell, to understand how networking works in containers, to write the scripts to get containers (and/or public cloud instances) up and running, etc.

    I do think that every org should start using these tools at a pace that makes them comfortable because it allows us to continue our “more with less” growth without significant pain. But we need to make certain we are training the next generation of DevOps engineers in the process. For the foreseeable future, we’ll still be the ones bug fixing and troubleshooting, so we need to understand the environment and the applications. We are starting to get some sweet tools to help us at a higher level, though. Anyone who has inherited complex systems knows that the learning curve of tons of source files that make up many subsystems and all of the spaghetti code that these can be comprised of is painful. I don’t normally mention brand names here, so I’ll just say there is at least one tool out there that you can ask to “describe what this code does” and it will run with it and give you an answer in plain English. This might be the training tool of the future, with the ability to compare what you see in code with what the AI describes in English.

    But for now, even if you don’t hunt down app description AIs, having entry-level people review the files that the AI generates will serve two purposes: First, to validate what the growing AI space is capable of and second, to get entry-level engineers into the entry-level bits of the systems.

    And keep rocking it. Make sure you have a path for DevOps in the AI future, but remember that the creation of the calculator did not statistically change the number of mathematicians, just made the bulk of them more productive. That’s all we’re doing here, just a bit more flexibly … But in the end, like a calculator, the AI has an equation that it fills and reports back with.

  • Vercel Adds Observability Tools to Web Application Framework

    Vercel Adds Observability Tools to Web Application Framework

    Vercel today announced it has added a suite of observability tools to its platform for building web applications using Next.js, an instance of the open source React framework based on a JavaScript library.

    Vercel CTO Malte Ubl said the Vercel Monitoring tools make it simpler for developers to troubleshoot applications without relying on a DevOps team to surface data. Instead, developers can take advantage of Vercel Monitoring tools to access metrics that track user interface and application programming interface (API) issues, he added.

    That capability is not intended to replace the need for observability tools employed by DevOps teams. Instead, the goal is to provide metrics that are specific to issues that developers encounter as an application is being built or after it has been deployed so they can be addressed.

    Developers can select from pre-made queries provided by Vercel or create their own by defining what metrics they want the Vercel Monitoring tools to track, including bandwidth and web traffic spikes and requests by bots that are indicative of a cyberattack. In total, there are more than 500 potential errors that developers can track. Logs then make it possible to drill down into errors and issues once they are identified to pinpoint the root cause of an issue.

    As more responsibility for applications shifts left toward developers, there’s a clear need for tools that provide more visibility into the applications they develop. Many of the issues that DevOps teams encounter today could have been resolved if developers had been aware of them earlier.

    The Vercel platform employs caching, routing and a React framework to optimize application performance in a way that reduces the dependency on backend infrastructure to optimize application performance. That approach puts less strain on backend infrastructure as more requests are automatically processed using a framework that spans clients and servers. In effect, developers can take advantage of frameworks such as React to treat the underlying IT infrastructure as if it were serverless whenever possible with tools that have a familiar JavaScript construct. The overall goal is to increase developer productivity at a time when many organizations are much more focused on the issue.

    As a result, DevOps teams will need to make some adjustments as more applications capable of providing richer experiences are built and deployed without relying as much on backend infrastructure. That shift has implications for everything from the amount of network bandwidth consumed to the performance of web applications. Frameworks such as Next.js also tend to increase the overall rate at which web applications can be built and deployed.

    One way or another, it’s clear that the way web applications are being built is fundamentally changing. The only issue now is determining to whether DevOps teams are prepared to absorb that level of change across an ever-increasing portfolio of applications that still need to be deployed, secured, updated and optimized.

  • The Economic Downturn and DevOps Hiring Trends

    The Economic Downturn and DevOps Hiring Trends

    An analysis of more than 494,000 interview requests for software engineers coupled with a survey of more than 1,300 software engineers and 120 hiring professionals found a lot more employers prefer to hire DevOps professionals who work in the office—but resistance to working in an office (rather than working remotely) remains high.

    The survey also found that, despite the preference for hiring local software engineers, more than half of hiring professionals (52%) are filling positions on fully remote teams while another 40% are focusing on hybrid teams.

    The interview requests analysis conducted by Hired, a provider of a platform for vetting potential employees, found that nearly three-quarters of interview requests (72%) were for software engineers with more than six years of experience. Backend engineers received 59% of all interview requests.

    Hired CEO Josh Brenner said the survey makes it clear that organizations are less inclined to hire less experienced talent. In fact, there’s a decided shift toward DevOps professionals that have degrees versus individuals that are largely self-taught, he added.

    Hiring those individuals, however, remains challenging. More of them are willing to consider other employment options given the current state of the economy, but more than two-thirds of engineers (68%) said they are not worried about losing their jobs in the next six months.

    However, enterprise IT organizations are now finding it easier to hire DevOps engineers because competition from startup companies and technology vendors such as Google and Microsoft slackened in the wake of a series of ongoing layoffs, noted Brenner.

    Competition for software engineers is also impacted by geographic region, with the Los Angeles area seeing the largest negative impact on local salaries, decreasing by 6% to $152,000. Philadelphia had the greatest amount of growth, with local salaries increasing by 7% to $150,000. Despite demand for remote engineering talent, growth in salaries for these positions has flattened. The San Francisco Bay Area had the highest salaries for remote roles at $180,000, followed by Seattle ($175,000) and New York ($169,000). The percentage of active engineering positions “open to remote” fell to 69%, the survey found.

    The highest-paying markets for in-office jobs, in contrast, were San Francisco ($180,000), Seattle ($169,000) and New York ($162,000).

    Software engineers, as always, are motivated to work for organizations based on new challenges and continuous learning (69%), building products/solutions and problem-solving (66%) followed by earning potential and career stability (60%), the survey found. When learning a new skill, the survey found the biggest motivator remained the simple joy of learning new things (40%) followed by the fact that their current job required it (25%).

    Regardless of the state of the economy, it’s clear that demand for DevOps expertise continues to outstrip available supply. However, software engineers may be unable to command as high a salary as they did a short while ago. Of course, no one can be sure what lies ahead, but economies do eventually rebound. In the meantime, DevOps professionals would be well-advised to continue to invest in their own skills to maximize their earning potential, no matter which direction the economic pendulum swings.

  • Day in the Life of a Chief Developer Experience Officer (CDXO)

    Day in the Life of a Chief Developer Experience Officer (CDXO)

    Developer experience (DX) has become essential to modern enterprise software development. As more companies become software companies, more are opening up their software both for internal reuse and externalized consumption. As part of this process, making developer-facing tools consumable and friction-free becomes more necessary to both perform well and stand out in the market.

    To oversee developer experience quality within an organization, an entire new role is beginning to emerge — the chief developer experience officer (CDXO). A CDXO is in charge of ensuring the intuitiveness of developer-facing toolsets and being an advocate for engineering needs. Such a focus could improve internal platform usability, like within platform engineering initiatives. Or, it may involve improving the developer experience for public or partner APIs through quality documentation, SDKs, libraries, forums, tutorials and more. A CDXO might interface with many departments to monitor and improve DX across the organization.

    Since the role is in its very early stages, few CDXOs exist. But I tracked down a few to gather insights on the emerging position—I had the unique opportunity to sync with Alessandro Cauduro, chief developer experience officer at Azion and Ivan Burazin, chief developer experience officer at Infobip. They both shared some fantastic insights on why DX is so important these days and what qualities make a good developer experience leader. Below, I’ll distill their wisdom and take a peek into the life of a CDXO.

    Why DX is Important

    First, it’s good to reiterate that developer experience is increasingly important for several reasons. Organizations want to build and ship applications faster and more securely. Yet, it can be difficult for programmers to keep up with new technology trends. “Technology is always changing, and developers are always having to try new things,” said Cauduro. “As a result, you rarely become an expert on a single platform.”

    Developer experience helps you get up and running quickly with new tools. The mindset is similar to user experience (UX) but more applicable to different interaction points like APIs, CLIs, SDKs, VSCode plugins, libraries or other developer-facing technologies. Improving usability for these packages helps ease the daily grind, increases productivity and can be a competitive advantage, said Cauduro. He added that a benchmark of great developer experience is when you don’t even have to read the documentation to understand what you have to do.

    “I think that developers are the lifeblood of innovation,” said Burazin. “They are the ones creating solutions and implementing transformative technologies. Yet, they are often let down when it comes to the tools they use to achieve this innovation, so providing a great developer experience is paramount if we want to foster that innovation as much as possible.”

    CDXO Roles and Activities

    So, what does a day in the life of a CDXO officer look like? What are some of their roles and responsibilities? According to Cauduro, the overarching goal is to put himself in the developer’s shoes—he constantly thinks about common developer workflows and considers how to create a seamless experience throughout the entire development life cycle.

    Next is spreading awareness throughout the company about DX principles and how to increase DX within their offerings. A CDXO will likely answer directly to executive leadership but might interface with many departments. A CDXO may direct teams to construct developer-specific tools, like libraries, documentation, SDKs and self-service environments. “DX is a mindset,” said Cauduro. “The whole company needs to be engaged in it.”

    “As with any C-level position, your job is on the one hand to make your team’s life easier in any way you can,” said Burazin. “And on the other to convey the developers’ issues or ideas to the company in hopes of nudging the company in the correct direction.”

    A CDXO may also oversee developer relations efforts, which focus on fostering a developer community. There are many ways to interface with partners and clients to exchange ideas on how to build against the platform, Cauduro explained. This includes promoting open source projects, encouraging user meetings or interacting on Discord and forums to provide answers to community questions.

    Qualities That Make a Good CDXO

    The CDXO position isn’t for everyone. So, what personality traits make a good candidate for the role? Here are some of the necessary qualifications for the type of work:

    • Experience as a programmer. A CDXO should have past experience as a professional developer. Engineering knowledge will help them understand the persona and empathize with their needs.
    • Leadership qualities. The role also requires leadership expertise, as a CDXO must have the ability to coordinate and influence many different areas of the company.
    • Creativity. Since the role is pretty nascent without a written path, it will require creativity. Having the ability to experiment, accept feedback and reiterate is also important, said Cauduro.
    • Empathy. Communication skills and empathy also go a long way. “Deep engineering knowledge crossed with great people skills is the mix you would need for such a task,” said Burazin.

    Developer Experience in Practice

    At Azion, Cauduro is interested in how its tools can help developers move solutions from the cloud to the edge more seamlessly. To that end, they’ve found that Jamstack fits well with the needs of edge computing. Thus, some of his efforts focus on making the process of deploying a Jamstack app to the edge as seamless as possible for engineers.

    While DX efforts have helped address development bottlenecks at Azion, the role of CDXO may not be necessary within all companies, admitted Cauduro. It’s more of a fit for API-first or SaaS companies that target developers as a primary consumer base. That being said, other companies can still benefit from a developer experience focus to enhance their internal IT platforms.

    At InfoBip, Burazin explained that developer experience efforts center around helping external developers consume the InfoBip API, an API for all communication channels, such as SMS, voice, WebRTC and more. Sitting under the CTO, Burazin helps run three teams and DX has its own department. Impressively, he reports revenue on self-service APIs has increased fivefold in the past two years.

    Burazin, also the co-founder of Codeanywhere, explained that his role is to “convey the worries or needs of the developer customers to management and help steer the ship in the right direction.” To discover those needs, he recommends ‘dogfooding’ what the customer is experiencing and streamlining the onboarding process to be as self-service as possible. He also recommends having measurable insights on metrics you can directly impact, like decreasing time from discovery to ‘hello world.’

    Final Thoughts

    Developer experience is becoming a unique selling point for technology companies—so much so that it’s entered the C-suite. “Whoever has the better DX will have the leading edge,” said Cauduro. For him, it’s about finding small things to optimize that remove pain points from the developer’s process.

    To summarize, the role of CDXO is still evolving and not set in stone. And, granted, many different labels are being applied to describe similar objectives. But to get an idea of what the CDXO role entails, some common activities include:

    • Considering the perspective of the developer.
    • Engaging the entire company to prioritize DX.
    • Overseeing the construction of DX-related assets and resources such as tutorials, documentation and guides.
    • Collecting feedback and reiterating platforms.
    • Overseeing developer relations and advocacy teams.

    Looking to the future, developer experience will likely become more of a necessity as developer-driven purchasing habits become a real revenue driver. “This bottom-up go-to-market motion will help awareness and increase sales,” said Burazin. And, to helm this movement, more companies may adopt DX within a C-suite title. But of course, the role may look different from company to company as DX is applied in different ways.

    “If we look at the largest technology companies, almost all of them have a developer experience department in their organization. And this is due to the fact that so much of a developer’s productivity is directly linked to their experience while working,” said Burazin. Things like internal developer portals and standard cloud deployments will help improve developer experience and help them focus on what they do best, which is coding, he said.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role, it creates an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Monster.com

    LongTail Ad Solutions
    New York, New York
    Senior DevOps Engineer
    $170,000

    LinkedIn

    TuneIn
    New York, New York
    Staff Infrastructure Automation Engineer
    $166,000 to $249,500

    SimplyHired

    The Hartford
    Remote
    Senior Staff Software Engineer
    $123,120 to $184,680

    Indeed.com

    Volunteer Corporate Credit Union
    Nashville, Tennessee
    Senior DevOps Engineer
    $109,000 to $139,000

    Dice.com

    MRoads
    Phoenix, Arizona
    DevOps Engineer- Associate
    $100,000 to $120,000

  • Six Mainframe DevOps Predictions for 2023

    Six Mainframe DevOps Predictions for 2023

    DevOps, or the automation of application development and hand-off to operations, is more prevalent than ever on the mainframe. As we begin 2023, below are six predictions for what the coming year will bring. The composite themes will undoubtedly be speed, alignment and experience.

    1. Enterprise DevOps Will Break Down Silos Across Core Systems

    DevOps practices will continue to expand beyond cloud and distributed systems to include more core systems than ever before. Core platforms, including the mainframe, are the functional backbone of mission-critical applications that drive the world economy. In a recent IDC survey, 82% of organizations reported taking steps to prioritize using the same application development tools across distributed and mainframe teams. 2023 will continue to see a rise in enterprise DevOps that will bring down the silos between platforms. As core system workloads increase, organizations will see the benefit of aligning platforms such as mainframe and distributed to realize the full benefit of their DevOps initiatives.

    2. Growth in AI/ML as Key Components for Measuring DevOps Performance Metrics

    The value of analytics will increase as organizations emphasize the use of key performance indicator (KPI) data to measure the performance and maturity of DevOps pipelines. In this way, organizations will not only gain more insights into their pipelines, but will also be able to proactively manage the data in real-time. They will be able to adjust loads as needed and create smart pipelines with advanced error handling. Organizations will leverage benchmarks within the analytics to see how they compare with their peers.

    3. Cross-Functional Pipelines Will Create Hybrid Automated Everything

    This will enable the cloud, core systems and data to deliver a more holistic view of “platforms, processes and people.” Silos will finally disappear. Automation will become a key priority in this effort as organizations seek to free up time for developers to innovate and achieve greater velocity, quality and efficiency. A single integrated and connected pipeline will emerge that automates the creation and testing of applications in a single flow. The rationale of prioritizing this alignment between distributed and core systems includes the reuse of best practices, workflow simplification, cost-effectiveness, application integration and streamlined training.

    4. DevOps Will Embrace Platform Engineering and Site Reliability Engineering (SRE)

    Platform engineering is the next evolution of DevOps, taking a DevOps platform and turning it into a self-service product to improve the developer experience. It treats DevOps as a product and allows organizations to create an end-to-end offering that serves developers, operations and platform teams. SRE focuses on the “Ops” side of DevOps, specifically how to automate operations capabilities. This is vital to the DevOps mission since it provides the data that allows organizations to manage what they can measure.

    5. DevSecOps Will Play an Increasingly Central Role

    Security must become a central part of the toolchain and a “first-class citizen” in the pipeline. Static application security testing (SAST), also known as white box testing, along with dynamic application security testing (DAST), also known as black box testing, will be further integrated into processes to enable security teams to scan large loads at rest or in real-time quickly and efficiently.

    6. Git-Centric Enterprise Source Code Management (SCM) Strategy Will Grow

    Git has become the de facto standard for SCM for distributed application workloads. In a recent IDC survey of industry professionals across 11 countries and multiple industries, 87% said they will migrate all or some of their mainframe source code to Git over the next three years. This means Git and Git-native development will become important capabilities for mainframe DevOps companies to support. Organizations will increasingly prefer implementation approaches and tools that offer flexibility in both scope and pace.

    The techniques highlighted in these predictions are, naturally, related. They point to an ever-increasing capacity for efficiency and quality that will enable core and distributed technologies to work better together.

  • DevOps Use Cases for AI-Assisted Kubernetes

    DevOps Use Cases for AI-Assisted Kubernetes

    As indicated in my prior blogs Optimizing Cloud Costs for DevOps With AI-Assisted Kubernetes and Optimizing Cloud Costs for DevOps With AI-Assisted Orchestration, an AI-assisted Kubernetes orchestrator is needed to optimize cloud costs for DevOps, DevSecOps and SRE. This blog describes DevOps-specific use cases for an AI-assisted Kubernetes orchestrator. The blog also describes a roadmap for implementing an AI-assisted Kubernetes orchestrator and the benefits of a solution using an AI-assisted Kubernetes orchestrator for DevOps.

    Use Cases for AI-Assisted Kubernetes

    An AI-assisted Kubernetes orchestrator can offer many benefits to organizations running containerized applications on Kubernetes clusters. Here are some use cases for an AI-assisted Kubernetes orchestrator:

    1. Auto-scaling: An AI-assisted Kubernetes orchestrator can help automate the process of scaling up or down the number of pods based on the traffic or usage patterns of the application. The AI can analyze the performance metrics of the application and determine the optimal number of replicas needed for the application to function efficiently.
    2. Load Balancing: Load balancing is a critical component of any Kubernetes cluster. An AI-assisted Kubernetes orchestrator can optimize the load balancing by analyzing the network traffic and determining the best way to route traffic to the different pods in the cluster.
    3. Predictive Maintenance: An AI-assisted Kubernetes orchestrator can help identify and diagnose issues before they become critical. The AI can analyze the logs and performance metrics of the applications to identify patterns and anomalies. Based on this analysis, the AI can predict potential issues and notify the operations team.
    4. Optimization: An AI-assisted Kubernetes orchestrator can optimize the resource allocation of the Kubernetes cluster by analyzing the usage patterns of the application. The AI can identify the optimal amount of resources required for each pod and allocate them accordingly.
    5. Self-Healing: An AI-assisted Kubernetes orchestrator can automatically detect and recover from failures within the Kubernetes cluster. The AI can analyze the logs and performance metrics of the pods and take corrective actions to ensure that the applications continue to function properly.

    DevOps-Specific Use Cases for AI-Assisted Kubernetes

    An AI-assisted Kubernetes orchestrator can provide several use cases specifically for DevOps teams. Here are some examples:

    1. Automated deployment: DevOps teams can leverage an AI-assisted Kubernetes orchestrator to automate the deployment process of their applications. The AI can analyze the code and configuration changes, build container images and deploy them to the Kubernetes cluster without any human intervention.
    2. Continuous integration and continuous deployment (CI/CD): An AI-assisted Kubernetes orchestrator can facilitate the CI/CD process by automatically building, testing and deploying new code changes. The AI can monitor the code repository for new commits and trigger the necessary actions to build and deploy the changes.
    3. Security and compliance: DevOps teams can use an AI-assisted Kubernetes orchestrator to ensure that their applications comply with security and compliance standards. The AI can monitor the security posture of the cluster and identify vulnerabilities or non-compliant configurations. The AI can also implement remediation actions to address the issues.
    4. Disaster recovery: An AI-assisted Kubernetes orchestrator can help DevOps teams to recover from disasters quickly. The AI can analyze the backup data and restore the data to the Kubernetes cluster. The AI can also create a disaster recovery plan and test it periodically to ensure that the recovery process is reliable and efficient.
    5. Resource optimization: DevOps teams can use an AI-assisted Kubernetes orchestrator to optimize the resource usage of the Kubernetes cluster. The AI can analyze the performance metrics of the applications and identify resource-intensive workloads. The AI can then allocate resources more efficiently to ensure that the applications run smoothly and cost-effectively.

    Roadmap

    Implementing an AI-assisted Kubernetes orchestrator for DevOps involves a series of steps to ensure a successful deployment. Here’s a feasible implementation roadmap for an AI-assisted Kubernetes orchestrator for DevOps:

    1. Define your use cases: The first step is to define the use cases for the AI-assisted Kubernetes orchestrator that align with your DevOps team’s goals. Identify which areas of your DevOps process can benefit from automation and optimization using AI.
    2. Choose a platform: There are several AI-assisted Kubernetes orchestrator platforms available. Research the options and choose a platform that aligns with your use cases and technical requirements. For example, CAST AI provides an AI-Assist for Kubernetes solution that is specially targeted to reduce cloud costs by as much as 60%
    3. Plan your deployment: Plan your deployment by defining the architecture, infrastructure and resource requirements. You need to ensure that you have the necessary resources, such as compute and storage, to support your deployment.
    4. Prepare your data: The success of your AI-assisted Kubernetes orchestrator depends on the quality and accuracy of the data. Gather and prepare the data needed for your AI algorithms to train and make decisions.
    5. Train your AI models: Train your AI models based on the data you’ve collected. Ensure that you test and validate the accuracy of the models to avoid introducing errors in your deployment.
    6. Integrate with your DevOps toolchain: Integrate the AI-assisted Kubernetes orchestrator with your existing DevOps toolchain, such as CI/CD pipelines, monitoring and logging tools and configuration management tools.
    7. Test your deployment: Test your deployment in a staging environment to ensure that it meets your requirements and use cases. Run a series of tests to verify that the AI-assisted Kubernetes orchestrator is working as expected.
    8. Deploy to production: After testing, deploy the AI-assisted Kubernetes orchestrator to your production environment. Monitor the performance and health of the AI-assisted Kubernetes orchestrator and make any necessary adjustments.
    9. Continuous improvement: Once deployed, continue monitoring and optimizing the performance of the AI-assisted Kubernetes orchestrator. Collect feedback from your DevOps team and improve the AI models, infrastructure and deployment processes.

    Benefits

    There are many possible benefits of an AI-assisted orchestrator for DevOps, including:

    1. Increased efficiency: An AI-assisted orchestrator can automate many of the repetitive and time-consuming test environment and deployment orchestration tasks in the DevOps process, allowing teams to focus on more critical and complex tasks.
    2. Improved accuracy: AI algorithms can analyze data and make decisions more accurately than humans. By using an AI-assisted orchestrator, DevOps teams can reduce the risk of human error in their provisioning and re-provisioning processes.
    3. Faster innovation: With an AI-assisted orchestrator, DevOps teams can automate many of the deployment processes, resulting in faster and more reliable deployments. This can help organizations to deliver new features and updates to their customers more quickly.
    4. Better resource utilization: An AI-assisted orchestrator can analyze resource usage and optimize resource allocation, resulting in more efficient resource utilization. This can help to reduce costs and improve performance.
    5. Enhanced security and compliance: An AI-assisted orchestrator can monitor security and compliance issues in the DevOps infrastructure orchestration process, identify vulnerabilities and implement remediation actions. This can help to ensure that applications are secure and compliant with relevant regulations.
    6. Improved scalability: An AI-assisted orchestrator can help to manage and scale Kubernetes clusters more effectively, ensuring that applications are available and performant as demand increases.
    7. Predictive analytics: An AI-assisted orchestrator can use predictive analytics to identify potential infrastructure issues and recommend solutions before they become critical. This can help DevOps teams proactively address issues and avoid downtime or other service disruptions.

    What this means

    As indicated in my prior blogs Optimizing Cloud Costs for DevOps With AI-Assisted Kubernetes and Optimizing Cloud Costs for DevOps With AI-Assisted Orchestration, an AI-assisted Kubernetes orchestrator is needed to optimize cloud costs for DevOps, DevSecOps and SRE. This article explained DevOps use cases for an AI-assisted orchestrator like CAST AI. Such an AI-assisted Kubernetes orchestrator can help DevOps teams to streamline their operations, reduce costs and improve the quality and reliability of their infrastructures and applications for testing and deployment. By leveraging AI technology, DevOps teams can focus on innovation and delivering value to their customers.

  • WTH? WFH is 6× Pre-Covid ¦ Plus: Agile Sucks (Redux)

    WTH? WFH is 6× Pre-Covid ¦ Plus: Agile Sucks (Redux)

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Working from home is here to stay, and Agile is still a failure. (more…)

  • Strategies To Consider When Adopting Platform Engineering

    Strategies To Consider When Adopting Platform Engineering

    Platform engineering helps centralize the responsibilities associated with maintaining internal infrastructure. And it continues to be an emerging discipline—according to the 2023 State of DevOps Report, 51% of organizations have already adopted platform engineering within the last three years, and 93% said it’s a step in the right direction.

    I recently met with Hope Lynch, senior director of platform at Cloudbees, to gain some insights on implementing platform engineering. According to Lynch, platform engineering has emerged at a critical juncture. Developers are overloaded, burnout is on the rise and tooling sprawl is starting to rear its ugly head. To respond to these trends, platform engineering has emerged to take the heavy load off internal software infrastructure management. But the practice requires keenly balancing responsibility with control and treating the platform as a product.

    Interestingly, Lynch believes that many IT departments—whether they know it or not—are already implementing some form of platform engineering. They might just need to work out the kinks. Below, we’ll define platform engineering as it relates to DevOps and share some best practices to consider when rolling out (or reiterating) a platform engineering plan within your organization.

    State of DevOps and Platform Engineering

    So, what is the state of platform engineering and DevOps? Contrary to the salacious ‘DevOps is dead,’ headlines, Lynch doesn’t believe DevOps is going anywhere. Instead, platform engineering is helping overburdened developers, having emerged at a time when developers and operations seem to be at a crossroads.

    Developers are now responsible for coding, security, deployment and infrastructure maintenance. “Developers are talented and creative, but everyone has only so much capacity,” said Lynch. She believes platform teams can relieve some of these pressures by creating standard builds and common CI/CD pipelines. “I see it as a partnership between the DevOps teams and platform operations teams.”

    Lynch views DevOps as more of a practice than a specific job title. And although developers should have control over their DevOps toolchain, she believes they were granted too much responsibility. For example, the amount of effort required to search the market, talk to vendors, and try out tools can all add up significantly.

    By creating proven patterns and managing tools, platform engineering teams can help narrow down the options, working behind the scenes to ensure the platform is self-serviceable and continually updated. Of course, this partnership requires regularly collecting feedback to ensure platform teams are enhancing development workflows, not hindering them.

    Best Practices for Platform Engineering Adoption

    So, what are some best practices that enterprises can apply to their internal DevOps platforms? Lynch shared some areas platform engineering teams should focus on to improve their process. By following these tips, a platform can enhance DevOps principles within a company.

    • Be open to feedback from developers. As previously mentioned, platform engineering and development should be partners. Platform engineers should seek to gather as much feedback as possible from developers to improve their experiences and ensure the right DevOps tools are acquired.
    • Don’t control everything. As such, a degree of flexibility should be granted—you don’t want to mandate standardized adoption of all tools. Yet, you do want to decrease rogue tooling and sprawl. The platform team should thus work to find a balance and build trust.
    • Maintain a DevOps culture. When people discuss DevOps, they often talk about the tools and technology, not why DevOps came to be. “DevOps is here because we were trying to find a way to allow teams to work better together and be high-performing,” said Lynch. As such, we shouldn’t forget to include the people element here. Platform engineering should reinforce a healthy culture with positive dialogues and ensure work is “a fantastic place to be.”
    • Treat the platform as a product. When delivering internal-facing tools, your developers are your consumers. Thus, it’s a good practice to treat the platform as a product in its own right. This includes publishing roadmaps and eliciting feedback. “The platform team really needs to win the business of their internal customers, or else they’ll buy or use something else, which could cause shadow IT.”
    • Focus on increasing developer experience. As part of viewing internal developers as customers, platform teams should invest in improving the developer experience associated with using the platform. This means reducing friction and integrating new capabilities into preexisting workflows whenever possible.

    Goalposts For Platform Engineering Success

    For any new initiative to be successful, it must have goalposts and be measured in some capacity. The same is true for platform engineering. So, what are some goalposts that IT leaders should have in mind when introducing platform engineering? According to Lynch, some positive end results include collaboration and efficiency, cost analysis, cybersecurity and tooling centralization.

    • Collaboration and efficiency: First, platform engineering should improve work in the best way for everyone, says Lynch. “The people component is always there and should always be a priority,” said Lynch. To reach these goals, she recommends having the right conversations to co-discover bottlenecks in the value stream management of software development.
    • Cost optimizations: Secondly, platform engineering is an opportunity for garnering insight into usage rates, which could inform cloud cost analysis. Platform teams can implement specific policies, such as spinning resources up or down to reduce expenses.
    • Improved security: Platform engineering teams can be the first to test new products, giving them a unique opportunity to synchronize requirements with security teams. They can also take the reins of continually patching dependencies to reduce vulnerabilities.
    • Increasing consistency. In general, another benefit is centralizing tooling control. Because when tens and thousands of developers are each using their own tool, it becomes harder for teams to work together. While some cutting-edge technology organizations may seek to give developers control over the full cycle to increase agility, most will benefit from centralizing procurement and oversight, said Lynch.

    The Human Side of Platform Engineering

    “Platform engineering, when done right, furthers the principles of DevOps,” said Lynch. And interestingly, it may be the case that teams don’t even realize they are already doing platform engineering. Once they realize they are gravitating toward these ideals, it will be an even greater reinforcer for DevOps and DevOps principles, she said.

    Currently, the tech space is in a tricky spot, with rising layoffs and tightening budgets. At many organizations, fewer people are now expected to perform the same high caliber of work. As a result, we need to place more emphasis on retaining the remaining talent and boosting morale. This means caring about what the developer’s experience is like throughout the day and supporting the human side of DevOps. According to Lynch, platform engineering is a natural choice in these circumstances.

  • Tabnine Extends Generative AI Platform Reach to Testing

    Tabnine Extends Generative AI Platform Reach to Testing

    Tabnine today announced it extended its generative artificial intelligence (AI) platform that enables developers to write code faster to now include the ability to automatically generate tests for that code.

    Available in beta, this capability promises to make it easier for developers to test code at the time it is being developed. That approach should make it simpler for developers to address issues without losing any context.

    Brandon Jung, vice president of ecosystems and business development at Tabnine, said this latest addition to the Tabnine platform is part of a larger effort to extend the reach of the Tabnine generative AI platform across the entire software development life cycle. The testing capability is expected to be generally available in the third quarter, and Tabnine expects to also employ generative AI to automate a much wider range of tasks across the software development life cycle within the next 12 months.

    The Tabnine platform supports multiple programming languages including Python, Java and JavaScript and is designed to be integrated with integrated development environments (IDEs) such as Visual Studio Code and Jetbrains. The company has also previously integrated its code completion tool with the GitLab continuous integration/continuous delivery (CI/CD) platform. The overall goal is to make it easier for developers to automatically write code based on custom models using approved source code hosted in a secure private repository, said Jung.

    Generative AI creates a large language model that assesses the probability of what the next line of code will be based on what has preceded it. Tabnine is now extending the model it created to also generate tests for the code its platform helped a developer write. It’s not clear what impact this ability to automate test creation will have on the need for dedicated testing teams, but it is about to become considerably easier to shift more responsibility for testing further left toward developers.

    It’s not likely DevOps teams will be replaced as generative AI is extended across workflows, but the overall size of those teams might shrink, noted Jung. DevOps teams will soon be able to do far more with fewer people, he noted. At the same time, the barrier to DevOps adoption will also fall as AI platforms make it simpler for more organizations to embrace DevOps best practices, added Jung.

    The challenge will be making sure the data collected to train AI models is of a high enough quality to ensure the desired outcome, noted Jung.

    One way or another, it’s now only a matter of time before generative AI capabilities are applied more broadly. Platforms such as ChatGPT developed by OpenAI are only the tip of the iceberg that impacts almost every manual process, including software development and deployment. The issue will be determining at what rate those innovations will become practical to employ. In the meantime, it is already apparent generative AI platforms are having a significant impact on the rate at which code can be developed. Inevitably, that means the amount of code moving through DevOps pipelines at any one time is about to increase significantly.