Category: Blogs

  • 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 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 tends to create 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 being offered.

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

    Indeed.com

    MasterCard
    O’Fallon, Missouri
    Principal DevOps Engineer
    $160,000 to $202,000

    Dice.com

    ITC Federal
    Remote
    Technical Lead – DevOps
    $130,000 to $150,000

    SimplyHired.com

    JP Morgan Chase
    Jersey City, New Jersey
    AWS DevOps Software Engineer
    $128,500 to $180,000

    LinkedIn

    Accenture Federal Services
    Springfield, Virginia
    DevOps Services Specialist
    $122,600 to $198,800

    CareerBuilder.com

    NextZen Tek Solutions
    Alpharetta, Georgia
    Azure DevOps Lead
    $120,000 to $170,000

  • IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM this week announced it will preview a generative artificial intelligence (AI) tool for converting COBOL code running on mainframes into Java. The preview will be available next month during IBM’s TechXchange learning event, IBM said.

    Kyle Charlet, CTO for Z software at IBM, said watsonx Code Assistant for Z makes use of large language models (LLMs) that IBM has trained to both convert and optimize Java code for z/OS running on IBM mainframes.

    Rather than converting COBOL into Java code line for line, the watsonx Code Assistant for Z improves the syntax of Java code generated using object-oriented techniques, he noted.

    IBM’s watsonx.ai code model, which will have knowledge of 115 coding languages, is based on 20 billion parameters that will eventually be applied to other programming languages such as PL/1, added Charlet.

    That model is the same core LLM that IBM used to create Red Hat Ansible Lightspeed, a tool to generate code for an IT automation framework that is scheduled for release later this year. In the future, IBM will also most likely employ generative AI to convert REXX code into Ansible code, said Charlet.

    IBM expects the final offering will combine generative AI tools with its existing Application Discovery and Delivery Intelligence (ADDI) inventory and analysis tool to streamline the modernization of legacy mainframe applications.

    The goal, however, is not to move COBOL applications off the mainframe. Java applications created using watsonx Code Assistant for Z will still call the same data sources, such as an IMS database or CICS transaction processing system, as the original COBOL application.

    That approach will make mainframes more accessible to a wider pool of developers that know Java, which should increase the overall pace of innovation for application development, noted Charlet.

    There are billions of lines of COBOL code currently running on mainframes that, in one way or another, need to be modernized as the pool of developers that know COBOL continues to shrink. Generative AI will make it easier to quickly assess, update, validate and test code, which should accelerate code conversion efforts that otherwise would take years to complete, said Charlet.

    It’s not clear how quickly organizations might move to modernize COBOL applications, but as the time and effort to do so decreases, so should the cost of modernizing legacy code. Most organizations still running z/OS on mainframes are committed to the platform, but if they can transition to Java, the overall cost of building and maintaining mainframe applications should decline.

    In the meantime, it’s not likely that AI will replace developers. IBM recommends that developers further optimize the Java code generated by watsonx Code Assistant for Z.

    Most developers are already using some form of AI to accelerate application development. The next wave of AI will see more widespread use of LLMs that are optimized for specific tasks and that generate more reliable results. After all, the quality of any output from an AI model is always directly related to the quality of the data used to train it. The narrower the set of vetted data, the more trustworthy the AI becomes—the opportunity for erroneous data to create AI hallucinations is a whole lot less than any general-purpose AI model could achieve with customization.

  • VMware Previews Spring AI to Accelerate Java Development

    VMware Previews Spring AI to Accelerate Java Development

    At a SpringOne at VMware Explore event this week, VMware demonstrated a tool that uses abstractions to make it simpler to build Java applications that invoke multiple artificial intelligence (AI) components with minimal changes to code.

    The goal for the open source Spring AI project is to, for example, make it simpler to swap out AI models using an AiClient interface for invoking OpenAI and Azure OpenAI services. It also adds capabilities that promise to make it simpler for developers to query documentation using generative AI enabled by large language models (LLMs). An additional goal is to extend those capabilities to other Spring projects, including Spring Integration, Spring Batch and Spring Data.

    In addition, the Spring command line interface (CLI) has been extended to support Spring AI and the Spring Boot framework has been extended to help set up dependencies and classes more easily.

    The AI capabilities are part of several additions made to the widely used framework for building Java applications that address everything from automatically turning off instances of Spring running in a container, also known as scaling to zero, to using virtual threads to call external services in a way that reduces memory consumption.

    Those additional capabilities promise to make it more efficient to run Java applications in, for example, a cloud computing environment.

    Betty Junod, vice president of product marketing for modern applications and the Management Business Group at VMware, said generative AI capabilities should serve to make Spring more accessible by not having to click around as much to gain answers to questions.

    In general, VMware is betting that a larger percentage of the Java applications built using Spring will be deployed on the Tanzu platform the company has built on top of Kubernetes. That platform streamlines the application development process in a way that reduces the cognitive load on developers by eliminating the need to know how to work with YAML files or use Docker Compose to create containers.

    Despite the proliferation of alternatives to Java, it remains the primary programming language used by developers to build applications. The challenges involved with learning additional programming languages are high, so most developers would prefer to continue to use Java to build both monolithic and emerging cloud-native applications.

    In the meantime, AI is already widely employed to help developers write code faster. AI isn’t going to replace the need for developers, but it will increase the pace at which applications are being developed. As such, DevOps teams will soon see a significant increase in the amount of code moving through DevOps pipelines. The hope is that AI will be applied in a way that enables those DevOps teams to manage increasingly larger codebases.

    In fact, the way applications are built and deployed will drastically change now that the AI genie is out of the proverbial bottle. But it remains to be seen how quickly those advances will change the way DevOps is managed at a level of unprecedented scale.

  • Driving DevOps Excellence: Implementing SLOs for Your DevOps Team

    Driving DevOps Excellence: Implementing SLOs for Your DevOps Team

    In today’s fast-paced world of software development, when continuous deployment and frequent releases are the norm, DevOps teams are essential to facilitating smooth communication between development and operations. In a blog post on LinkedIn, I talked about the importance of service level objectives (SLOs) for the testing team to improve the overall product quality. On top of that, let’s look at how adding SLOs to your DevOps team can improve productivity, dependability and client happiness.

    The Role of SLOs for DevOps Teams

    • Aligning DevOps Goals with Business Objectives:

    SLOs help DevOps teams coordinate their efforts with business objectives. The DevOps team can concentrate on delivering real business value by setting precise performance indicators, such as deployment success rates or infrastructure provisioning timeframes.

    • Promoting Collaboration and Accountability:

    By implementing SLOs, several stakeholders—including development, operations, quality assurance and business teams—are encouraged to work together. Over each stage of the software development life cycle, this shared responsibility promotes a sense of ownership and accountability.

    • Driving Reliability and Stability:

    SLOs play a key role in ensuring the stability and dependability of the system. You can be sure that your services consistently fulfill client expectations when your DevOps pipeline adheres to defined SLOs.

    • Proactive Issue Mitigation:

    Monitoring and alerting systems are used together with SLOs. The DevOps team could avoid service outages and downtime by aggressively identifying possible problems and resolving them before they become more serious by regularly monitoring important indicators.

    • Data-Driven Decision Making:

    Decision-making is driven by quantitative data. With the help of such indicators, the team is able to identify bottlenecks, prioritize improvements and streamline processes based on quick feedback.

    Now, let’s explore some key areas where DevOps teams can set SLOs to improve their performance:

    1. Continuous Integration (CI):
    SLO: “xx% of builds complete within Y minutes.”
    Measurement: Monitor build times and queue times regularly.
    Action: Optimize CI infrastructure and configurations to meet the SLO.

    2. Continuous Deployment (CD):
    SLO: “xx% of deployments are successful.”
    Measurement: Track deployment success rate.
    Action: Improve the deployment process to meet the SLO and reduce deployment failures.

    3. Infrastructure Management:
    SLO: “xx% of infrastructure is provisioned within Y minutes.”
    Measurement: Monitor infrastructure provisioning time.
    Action: Optimize infrastructure provisioning scripts to meet the SLO.

    4. Monitoring and Logging:
    SLO: “DevOps tools and system uptime should be at least xx%.”
    Measurement: Monitor the availability of the DevOps pipeline, deployment system and other tooling, including monitoring and logging systems.
    Action: Ensure high availability for DevOps tools and components.

    5. Artifact Management:
    SLO: “Artifact retrieval time should be less than x seconds on average.”
    Measurement: Monitor artifact retrieval time and availability.
    Action: Optimize artifact storage and distribution mechanisms.

    6. Testing and Quality Assurance:
    SLO: “Code must have at least xx% unit test coverage.”
    Measurement: Track test coverage regularly.
    Action: Encourage developers to write more tests.

    7. Security and Compliance:
    SLO: “xx% of compliance checks must pass.”
    Measurement: Monitor the results of compliance checks.
    Action: Ensure necessary security measures to meet the compliance SLO.

    8. Standardized Tools Selection:
    SLO: “xx% of teams must use the approved CI/CD tools stack.”
    Measurement: Track the percentage of teams using the approved tools stack.
    Action: Encourage teams to adopt standardized tools and provide necessary training and support.

    9. Training and Skill Development:
    SLO: “xx% of team members should undergo relevant DevOps training annually.”
    Measurement: Monitor training completion rates.
    Action: Provide training opportunities and resources to help team members enhance their skills.

    Initially, teams should baseline which percentage values to track by observing the current state. In the event they don’t have the bandwidth to baseline, start with any reasonable arbitrary number over a period of time, and it will be automatically refined.

    Implementing service-level objectives empowers DevOps teams to focus on delivering reliable and high-performing services that meet user expectations. By setting clear performance and reliability targets, teams can proactively identify and resolve issues, leading to improved collaboration, efficiency and overall user satisfaction.

    SLOs are not rigid constraints but are a means to drive continuous improvement and foster a culture of excellence within the DevOps ecosystem. As organizations strive to keep up with the ever-changing demands of the digital world, embracing SLOs is a crucial step toward achieving DevOps excellence and ensuring a competitive edge in the market.

  • How Platform Engineering Can Drive Digital Sobriety

    How Platform Engineering Can Drive Digital Sobriety

    If we’re being honest, the “green issue” currently isn’t the priority it needs to be for a lot of companies. At best, they are ticking the box marked ‘sustainability’ and paying lip service to a trendy topic. At worst, they are engaging in nothing more than greenwashing.

    Considering carbon emissions from cloud computing have now overtaken those from commercial aviation, this is disheartening for the IT sector. Unsurprisingly, most of these emissions come from inefficient use of the cloud due to overly complex processes and a lack of centralized oversight over cloud infrastructures. And if “emissions” sounds a bit vague, here’s a translation into dollars–$147 billion was wasted in 2022 in cloud spend.

    So, when it comes to reducing an organization’s cloud carbon footprint, there is clearly a financial incentive. Even for those who don’t believe in individual responsibility or worse, simply don’t care what kind of world we’ll leave future (and some present) humans to live in, there is money to be saved.

    The truth is that companies need to put sustainability first across the whole enterprise, and they need to do it now.

    A New Kind of Business

    Tackling departments one-by-one or singling out individual processes to make them more sustainable is not going to work. What organizations need is to stop thinking of sustainability as an afterthought and start incorporating it in the decision-making process from the get-go, maybe even as part of their very business model.

    This is the sort of business that places its people and the planet above profits. Progressive, modern companies that want to stay in business longer need to invest in their people and take care of the planet instead of chasing endless growth and ever-increasing profit because that, simply put, cannot last.

    As a culture, we’re currently at a turning point–late-stage capitalism is running its course, and more people are realizing that constant growth at the expense of well-being and the planet’s dwindling resources is not sustainable (in all senses of the word).

    For this to work, it’s about looking at business through a new prism.

    Driving Digital Sustainability From the Ground Up

    It’s not too late for businesses to become more sustainable. In fact, it is the best time to make life-saving changes. When it comes to tech specifically, there are a couple of things you can do, starting with two key things that need to change.

    First, cloud waste has been costing companies billions of dollars for years now. Organizations are set to spend nearly $600 billion on the cloud in 2023, but it seems that most people are still in the dark about the real environmental impact of cloud usage. As with most big corporate changes, it’s all about a change of mindset. We need to accelerate awareness and promote digital sobriety to inspire transformation and decision-making with GreenOps on the enterprise level.

    A cloud-first approach has long been the holy grail of IT. However, what we couldn’t anticipate is the sheer volume of resource usage and complexity that comes with it. We simply do not have the planetary resources to support this growth much longer. It’s time to become smarter, leaner and more environmentally conscious by using the “consume better” approach.

    Second, think about the KPIs. Change without success parameters will not work. While organizations have a key role in decreasing global cloud spend, they must have the right tools and references. They need to be able to assess the environmental impact of their digital choices at all decision levels.

    For the IT sector, this is where platform engineering comes into play. An internal developer platform can act as the critical piece that connects DevX, deployments, governance, security and observability.

    With green best practices and cloud carbon footprint visibility at every stage–from the dev deploying a new environment on the cloud to the CFO checking the monthly cloud bill–a platform engineering approach ensures not only organizational but also individual responsibility. When all tools are accessible and processes transparent, nothing gets lost in translation. This means less room for error and cloud waste.

    Ultimately, it’s About Consuming Better and Consuming Less

    Right now, these KPIs will be financially motivated, and rightly so. But there will come a time when progressive organizations will put their environmental impact at the forefront of their mission statement.

    The B-Corp certification, which evaluates companies in terms of their social and environmental performance, grew 63% in 2022. This shows the trend toward moving to a more inclusive and sustainable economy. Partly because it’s in the interest of the businesses’ long-term success and reducing costs, but partly because it is simply the right thing to do.

  • New Relic Extends AI to Identify Alert Coverage Gaps

    New Relic Extends AI to Identify Alert Coverage Gaps

    New Relic this week added additional artificial intelligence (AI) capabilities to its observability platform that make it possible to detect and resolve alert coverage gaps.

    Camden Swita, a senior product manager for New Relic, said it’s not uncommon for DevOps teams to discover an issue that the existing alerts they put in place were not designed to address. New Relic is adding machine learning algorithms at no additional cost that are designed to identify anomalies indicative of those potential issues. The platform then surfaces recommended alerts that DevOps teams can apply or further customize as they see fit, he added.

    Those machine learning algorithms ensure DevOps teams are tracking the right thresholds to ensure there are no blind spots that could adversely affect application performance, noted Swita.

    New Relic is employing both predictive and generative AI to enable DevOps team to detect and resolve issues faster. The company has been using machine learning algorithms for predictive AI for several years and, more recently, started providing early access to a generative AI tool dubbed Grok.

    The overall goal is to make the capabilities of an observability platform more accessible, Swita said. This is accomplished by surfacing issues without requiring a software engineer to craft intricate queries to interrogate metrics, logs and traces, he noted.

    The AI capabilities also serve to reduce the amount of alert noise; it’s now possible to more easily understand the root cause of an issue and reduce the total number of alerts that might otherwise be sent, he added.

    While there’s no doubt AI will help democratize DevOps by making it possible to write scripts and better manage workflows, it might be a while before DevOps teams trust the recommendations made. AI models typically require some time before they understand how an IT environment functions, and not every initial recommendation may be valid. In time, however, DevOps teams will find themselves increasingly supervising processes that AI models are executing.

    In addition, there are competing approaches to building large language models (LLMs) that drive generative AI. For example, it’s not clear whether chaining LLMs together will be more efficient than creating a single large ‘parent’ LLM that has ‘child’ relationships with smaller LLMs, noted Swita.

    In the meantime, DevOps teams would be well-advised to list tasks that are likely to be automated by AI models. Many of them will tend to be manual tasks that most software engineers don’t especially relish, so in that regard, there’s naturally a lot of interest in AI. It remains to be seen, however, whether various forms of AI might one day automate an entire DevOps workflow. In fact, most DevOps engineers are going to set a high bar for AI models that, at the very least, will be expected to perform a task as well as humans before it’s trusted completely.

  • The Differences Between DevOps, DevSecOps and SRE

    The Differences Between DevOps, DevSecOps and SRE

    DevOps, DevSecOps and SRE are all quickly gaining traction within the tech world due to their effectiveness and promise of reliability for companies. Each framework provides various levels of safety and scalability—DevOps is agile, DevSecOps prioritizes security above all else and SRE focuses on performance optimization. Together, these are changing how software gets deployed from conception to production. We’ll break down each one in detail.

    What is DevOps?

    DevOps is a set of practices that combines software development and IT operations, which aims to shorten the software development life cycle (SDLC).

    DevOps bridges the gap between those two areas by bringing together different people–developers, operators, testers and system engineers–who are responsible for different parts of the software delivery process, from planning to deployment into production environments.

    A core tenet of DevOps is to automate manual processes within each stage of the SDLC, eliminating much of the redundant work that used to take weeks or even months. This automation significantly drives down costs, as well as reduces problems posed by human error when running manual tasks.

    The following are some of the core tenets of DevOps:

    1. Collaboration
    2. Quality and reliability
    3. Automation
    4. Scalability
    5. Security

    What is DevSecOps?

    DevSecOps (or DevOps security) is an emerging field within the DevOps practice that focuses on strengthening software security within the development and operations process.

    These three distinct groups often have different priorities when it comes to building software applications. Developers are focused on speed-to-market objectives from their employers or clients, operations focus on reliability and scalability, while security teams prioritize safety from malicious actors or data breaches. At the same time, with DevSecOps, these goals become united under one umbrella: Build fast and reliable applications with built-in protection against attacks.

    DevSecOps focuses on implementing security as code—or automating many routine tasks involved with identity management, like user authentication and authorization. To ensure that security is properly integrated into your DevOps pipelines, below are some key DevSecOps practices:

    1. Automate security processes whenever possible
    2. Encourage continuous testing
    3. Prioritize remediation over detection
    4. Create a culture around secure coding principles

    What is SRE?

    SRE stands for site reliability engineering. The basic idea behind SRE practices is that software engineers should be responsible for both the development as well as the reliability of their product as a whole. This means having an understanding of not only how users will interact with the application or service but also how it interacts with other services in its operating environment, such as databases, firewalls, cloud environments, etc.

    To maintain uptime while meeting these requirements, SRE applies various techniques like automation and continuous deployment processes to ensure high availability.

    A key goal of site reliability engineering is service-level objectives (SLOs), which measure how consistently a service meets its goals over a given period of time—such as how often it’s available, how quickly it responds to requests made by users or customers—and establishing goals around those SLOs. Achieving objectives like these helps organizations build customer trust in their products and services since it ensures that they have stable and reliable day-to-day operations.

    Here are some of the most important SRE principles:
    1. Automation
    2. Proactive monitoring
    3. Fault tolerance
    4. Measurement and analysis
    5. Service-level objectives (SLOs)

    DevOps Vs. DevSecOps Vs. SRE

    The differences between DevOps, DevSecOps and SRE can be summed up in three main areas: Scope, roles and objectives.

    DevOps focuses on improving the speed of releasing software by automating processes and optimizing collaboration between development and operations teams. This helps organizations create a continuous delivery pipeline to quickly deploy code into production with minimal risk. As such, it is typically focused on development or operations activities and has become synonymous with agile methodologies such as continuous integration/continuous delivery (CI/CD).

    DevSecOps expands upon these concepts to include security considerations from the very beginning of a project’s life cycle instead of tacking them on after the fact. By shifting security left in the process–meaning bringing security earlier into the design phase–teams are able to reduce risk early on while achieving faster results overall through continuous feedback loops.

    As part of this shift left process, DevSecOps practitioners focus heavily on automating security compliance activities as part of their job function rather than waiting until after deployment has occurred.

    Meanwhile, SRE focuses more broadly on keeping the user experience consistent across various products an organization offers by responding to customer needs quickly while creating automation processes that allow common tasks to be repeated without manual intervention from engineers or developers.

    Then there is also platform engineering, which is a closely related yet distinct discipline with its own unique responsibilities. While both DevOps and platform engineering involve automation and working with the infrastructure that supports software development, there are some key differences between them.

    Platform engineering can be defined as a practice that involves developing a standardized platform on which all applications will run. Platform engineers build the underlying infrastructure to support applications, including servers, databases, virtualization layers and networking components using standardized toolsets. An important task for this field is designing an application’s architecture in such a way that allows it to scale easily with increased demand or usage levels. Additionally, they create self-service tools that enable developers on their team to quickly spin up new environments without requiring outside assistance.

    Wrapping Up

    In conclusion, while all three approaches have similar goals–ensuring reliability, speeding up the software delivery process and securing user data–they do so using different strategies:

    ● DevOps favors automation.
    ● DevSecOps puts focus on proactive security measures.
    ● SRE prioritizes optimization, reliability and scalability.

    Each one can contribute significantly when appropriately implemented into any organization’s workflow, depending upon its own specific needs.

  • Strategic Roadmap for SREs: Software Deployments With AI

    Strategic Roadmap for SREs: Software Deployments With AI

    In my recent blog Revolutionizing the Nine Pillars of SRE with AI-Engineered Tools, I indicated that SREs can use AI and machine learning to optimize deployment strategies and minimize risks. In this blog, I explain, in more detail, how AI-engineered tools can be used to improve the pillar that I call deployments.

    SRE Use Cases for AI-Assisted Deployments

    Here are use cases for SREs to use AI to assist with software deployments.

    Pre-Deployment Preparation Activities: AI can analyze the deployment package to assess dependencies, predict potential conflicts and evaluate the readiness of the package for deployment. AI can also assist in configuration management, ensuring the correct configurations are applied based on the deployment environment. Tools like Harness Continuous Delivery use machine learning to predict the success of deployments based on previous patterns and trends.

    Deployment Decision Process Automation: AI can use data from past deployments, current system status and predictive analytics to decide the best time and method for deployment. It can assess the risk associated with the deployment and help in decision-making. Tools like IBM’s UrbanCode Deploy leverage AI to optimize deployment processes based on historical data.

    Deployment Orchestration Using Blue-Green: AI can help orchestrate Blue-Green deployments by managing the routing rules, monitoring the performance of the new environment and deciding when to switch traffic. Tools like Spinnaker, integrated with AI capabilities, can automate this process more effectively.

    Deployment Orchestration Using Canary: In Canary deployments, AI can analyze the performance of the canary instances in real-time, compare it with the baseline and make data-driven decisions about whether to proceed with the full deployment. Canary deployments can benefit from AI tools like Flagger, which automatically advance or roll back deployments based on key metrics.

    Deployment Orchestration Using Feature-Flag Rollouts: AI can help manage complex feature-flag rollouts, analyzing user behavior and system performance to optimize the rollout strategy. Tools like LaunchDarkly provide feature flag management and integrate machine learning for more sophisticated flag controls.

    In-Production Testing: AI can enable more effective testing in production by identifying unusual system behavior, predicting potential issues and recommending areas for focused testing. Chaos engineering tools like Gremlin integrate AI to automate the identification of system weaknesses.

    Decision-Making and Orchestration of Rollbacks: AI can monitor the health of the system post-deployment, making data-driven decisions about when a rollback is necessary. AI can also help orchestrate the rollback process to minimize disruption. Harness Continuous Delivery provides AI-driven rollback capabilities.

    Monitoring Performance of Deployed Artifacts: AI can analyze the performance of deployed artifacts, compare it with baseline performance, and predict potential performance issues. Tools like Dynatrace use AI to provide real-time performance monitoring and anomaly detection.

    RoadMap for SREs to Transform Deployments to Using AI

    Here is a practical roadmap for SREs to transition to using AI tools for deployment.

    Needs Assessment: Begin by understanding the current state of your deployment processes and identify areas where AI can bring the most benefits. This could be in deployment decision automation, deployment orchestration, in-production testing, rollback decision-making or performance monitoring.
    Tool Selection: Research AI-enabled tools that are available in the market that could fulfill your specific needs identified in step one. Some of these tools could include Harness Continuous Delivery, IBM’s UrbanCode Deploy, Spinnaker, Flagger, LaunchDarkly or Gremlin. Remember to evaluate these tools based on their features, scalability, compatibility with your existing systems and cost.
    Pilot Program: Implement a pilot program with the selected AI tools on a small scale or in a non-critical environment. This will allow you to evaluate the tool’s effectiveness, understand its strengths and weaknesses and refine its configuration and usage in your environment.
    Training: Ensure your SRE team is adequately trained to use the selected AI tools. This could involve formal training sessions, self-guided learning resources or hands-on practice in a sandbox environment. Remember, the tool is only as good as the person using it.
    Gradual Rollout: Once you’re confident in the tool’s effectiveness and your team’s ability to use it, begin a phased rollout of the tool in your production environment. Monitor closely and be ready to adjust as necessary.
    Continuous Improvement: Regularly review the tool’s effectiveness and look for ways to further optimize its usage. Stay informed about updates to the tool and industry best practices, and continually adjust your processes to stay ahead of the curve.

    Summary

    AI’s role in enhancing SRE practices, specifically software deployments, is revolutionizing the efficiency and reliability of deployment processes. From pre-deployment preparation to monitoring the performance of deployed artifacts, AI tools can automate complex tasks, make more informed decisions and improve the speed and reliability of deployments. Whether you’re using Blue-Green, Canary or feature-flag rollouts or you’re navigating decision-making for rollbacks, AI tools like Harness Continuous Delivery, UrbanCode Deploy, Spinnaker, Flagger, LaunchDarkly and Gremlin can be game-changers.

    However, transitioning to AI-driven deployments isn’t an overnight switch; it’s a journey that requires strategic planning and execution. Starting with a thorough needs assessment, choosing the right tools and implementing them via a pilot program is the first leg of this journey. Training your SRE team on these tools and rolling them out gradually in your production environment will ensure a smooth transition. And the journey doesn’t end there. Regular tool effectiveness reviews and staying up-to-date with the latest in the tool’s features and best industry practices will ensure that you’re getting the most out of AI in your deployment processes. Embrace the AI revolution in SRE to stay ahead of the curve in the fast-paced world of continuous software deployments.

  • IBM to Provide Hybrid Cloud Service Based on VMware Cloud

    IBM to Provide Hybrid Cloud Service Based on VMware Cloud

    At the VMware Explore 2023 conference this week, IBM announced that it will soon provide a fully managed service based on a streamlined edition of VMware Cloud.

    Brendan Kinkade, vice president for independent software vendors, technology and hybrid cloud partnerships for IBM Global Sales, said VMware is now making available editions of VMware Cloud that are both easier to deploy and manage and, just as importantly, migrate between cloud platforms and on-premises environments as IT teams see fit.

    IBM is committed to using that platform to deliver a managed VMware Cloud service that will span hybrid cloud computing environments aligned to an NIST-validated framework, he added. That approach is critical because it will enable IT teams to apply VMware license credits to any instance of VMware Cloud no matter where it is deployed, noted Kinkade.

    In addition, the streamlined edition of VMware Cloud doesn’t use proprietary application programming interfaces (APIs) to make it simpler to port IT environments to another cloud service or back to an on-premises IT environment whenever necessary, he added.

    At the foundation of the hybrid cloud service will be an instance of a multi-tenant vCloud Director console residing on the IBM Cloud. Through the console, IT teams will be able to work with IBM to co-manage application environments.

    In addition, IBM is providing a managed IBM Cloud Cyber Recovery (ICCR) Service to better secure cloud computing environments.

    It’s not clear how much of IT is now being consumed as a managed service, but the COVID-19 pandemic has certainly increased that number. Many IT organizations are also finding it simpler to rely on a managed services provider (MSP) to manage infrastructure so they can focus more of their time and effort on application development, noted Kinkade.

    MSPs are also in a better position to aggregate all the telemetry data needed to train artificial intelligence (AI) models that will be used to automate workflows, he added.

    Exactly how DevOps workflows will evolve as organizations rely more on external service providers to manage IT infrastructure is, naturally, a work in progress within many organizations. The main challenge is aligning a unique set of continuous delivery (CD) practices for deploying and updating applications with a provider that has already defined its own workflows.

    Nevertheless, given the complexity of those environments, many organizations are not able to hire and retain the IT expertise required to manage it, so the only option may be to rely on an MSP.

    Each IT organization will need to decide whether to rely on an MSP, given the total cost of a service. Many organizations often wind up having a mix of workloads managed by internal IT teams and external service providers. The one thing that is certain is that as the pace at which workloads are being deployed in the cloud increases, many internal IT teams are overwhelmed by a level of complexity that will only increase.