devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • 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.

  • Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    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: Denis Pushkarev is fed up with core-js freeloaders, and hundreds more malicious packages found at PyPI. (more…)

  • Technical Debt is a Major Threat to Innovation

    Technical Debt is a Major Threat to Innovation

    A survey published today suggested that technical debt is starting to take a heavier toll as IT environments continue to become more complex to manage.

    The survey of 400 IT leaders at organizations with 1,500 employees was conducted by Foundry, the market research arm of International Data Group (IDG) on behalf of Insight Enterprises, a provider of IT services. The survey found that 86% of respondents reported their organization was impacted by technical debt over the past 12 months, with the top areas affected being the ability to innovate (43%), meet service level agreements (41%) and avoid downtime (37%).

    Technical debt is created when organizations cut corners and leave known bugs in the race to meet application delivery deadlines. Application code is often not as thoroughly tested as it should be. In some cases, it turns out that what was intended to be a minimum viable product doesn’t scale all that well. Quick fixes needed to improve performance are also frequently undocumented. Inefficient code also winds up consuming more IT infrastructure than required, which adversely impacts everything from cloud costs to the amount of carbon generated.

    Juan Orlandini, chief architect for the Cloud + Data Center Transformation (CDCT) division of Insight Enterprises, said every organization struggles with technical debt; it will never be eliminated, but it does need to be contained, he added.

    The challenge is instead of trying to keep the proverbial IT lights on during the COVID-19 era, IT teams are now being asked to innovate to advance digital business transformation initiatives, said Orlandini. A full 87% of survey respondents cited modernizing critical applications as a key success driver.

    As a result, many organizations are embracing platform engineering to bring more structure to their DevOps processes, he noted. The challenge, however, is striking a balance between a more centralized approach to DevOps and maintaining the ability of developers to innovate, said Orlandini.

    The issue, of course, is that in addition to massive technical debt, the latest generation of applications are more distributed than ever. The survey found 91% of respondents now rely on multiple public cloud providers for different workloads, with 54% of data residing on a public cloud. However, the survey also found on-premises IT environments are still relevant, with 20% planning to repatriate select public cloud workloads to an on-premises model over the next 12 months.

    Nearly three-quarters (72%) of respondents also noted data volumes are growing faster than their ability to manage them, with 64% ranking implementation of a data governance program to improve data management as their top data-related objective this year. Just over a third (35%) of the data estate is now, on average, driven by edge workloads, with 29% of respondents reporting that at least 50% of data volumes now reside on the edge. Nearly two-thirds (64%) expected that to increase in the next 12 months.

    A total of 85% of respondents also indicated their organization is using artificial intelligence (AI) to some degree to drive business insights and/or efficiencies, although only 36% reported having optimized their use of AI and machine learning (ML) across the enterprise.

    Finally, cybersecurity also remains problematic, with 51% reporting they were impacted by a cybersecurity breach over the past 12 months. Just 20% resolved their issue in one day, while 31% needed less than a week. Nearly half (49%) required one week or more to recover.

    It’s clear that IT isn’t becoming any easier to manage. IT teams need to find ways to build and deploy new applications while reducing technical debt so it doesn’t strangle future innovation.

  • FinOps & ITAM Must Team up to Cut Cloud Spend

    FinOps & ITAM Must Team up to Cut Cloud Spend

    Ahead of its Wisdom NA 2023 event taking place in Florida March 21-22, Rich Gibbons from the ITAM Review explores the relationship between FinOps and IT Asset Management when it comes to managing software costs. With on-premises revenues in decline, will the major software publishers respond by increasing policing and enforcement of their licensing rules in the cloud? Are cloud audits ahead in 2023? And will a marriage of convenience between FinOps and ITAM see us through?

    It’s already clear that, in 2023, corporate spending will be under the microscope more than ever. With software publisher price increases, rising energy bills and a global recession all contributing to the need for businesses to focus on cost, IT–and particularly software–is a prime place to focus. Concentrated efforts to monitor and manage software spending present a fantastic opportunity to materially improve an organization during these difficult times, enabling it to weather the storm and emerge from it lean, strong, and heading in the right direction.

    Annual spending on public cloud is predicted to reach $809 billion (IDC) by 2025, so ensuring this money is spent as efficiently and effectively as possible must become a key corporate-wide priority for every business.

    It’s Not All About Reduction

    One important aspect to realize is that, in the modern cloud age, cost management efforts shouldn’t be all about cost reduction. Rather, it is more appropriate to focus on spend efficiency. With cloud computing as a driver of digital transformation which enables organizations to offer new services to new audiences, it’s completely understandable that your cloud bill may increase; the important thing is whether the value to your business has risen commensurately.

    If your cloud bill rises by $1 million and your revenue rises by $1.5 million because you’re reaching more customers and/or have a new product line–happy days. If, however, you’re seeing your bill increase without that associated revenue increase, then that is a sign of spend inefficiency; you’re spending more for no return. This will likely be due to resources that are over-provisioned, under-used and/or incorrectly architected.

    Who’s Involved?

    The management of on-premises software such as Microsoft, Oracle, IBM, etc. has long been the domain of the software asset management (SAM) team or IT asset management (ITAM) team and their remit quickly grew to incorporate software-as-a-service (SaaS) products such as Adobe Creative Cloud, Microsoft 365 and Salesforce alongside SQL Server, Oracle DB and IBM Websphere.

    More recently, with the massive and continued growth of infrastructure-as-a-service (IaaS)/platform-as-a-service (PaaS) cloud environments, the discipline of FinOps has experienced considerable growth and become the de facto strategy for managing public cloud spending for many enterprises.

    While the two areas may seem separate, the growth of hybrid infrastructure means the two disciplines must learn from each other and work together to deliver the best overall results for a business. As John Donne said in 1624, “No man is an island,” and the same applies to teams managing corporate assets–what one team does (or doesn’t do) often impacts the other.

    Let’s take a look at some of the ways this collaboration can pay off in the real world.

    Azure Hybrid Benefit

    This is a perfect example of how regular, clear communication between ITAM and FinOps benefits everyone. Most enterprise organizations purchase their Microsoft volume licenses via an enterprise agreement (EA) and one of the characteristics of this agreement is the mandatory inclusion of software assurance (SA). This suite of extras includes a range of benefits such as new version rights, disaster recovery rights and, most pertinent here, the Azure Hybrid Benefit.

    Azure Hybrid Benefit is an SA benefit that allows you to allocate your existing on-premises licenses to cover portions of your cloud costs in Azure and on-premises hybrid infrastructure. It is currently applicable to:

    • Windows Server Azure virtual machines
    • SQL Server Azure: Virtual machines, managed instances, databases
    • Azure stack hyperconverged infrastructure (HCI)
    • Azure Kubernetes Service (AKS)
    • Red Hat Enterprise Linux (RHEL)
    • SUSE Linux Enterprise Server (SLES)

    Each of these scenarios can help an organization reduce their cloud bill, make better use of their overall Microsoft spend, and potentially use higher-level services–all increasing their return on investment (ROI) and spend efficiency. Microsoft claims savings of 50% for Windows Server and 85% for SQL Server are possible (see here), although your mileage will, almost undoubtedly, vary.

    However, while enabling the Azure Hybrid Benefit is, in many instances, as simple as ticking a box when deploying the cloud resource, that is far from the only requirement. First of all, there is a need to know how many applicable on-premises licenses you currently own and what your future plans are for renewals.

    Then you must be aware of the various licensing rules that pertain to the range of Azure Hybrid Benefits and understand their implications for your specific environment. Rules and usage allowances differ between editions, such as standard/enterprise/data center, while certain benefits may not be used concurrently. Also, given Microsoft’s penchant for regularly updating and changing licensing rules, this understanding needs to be frequently reviewed and any changes highlighted.

    Furthermore, given the direct link between on-premises licenses and cloud resources, changes at either side may have a knock-on effect. To keep hybrid spending as efficient as possible requires strong processes, capable discovery/monitoring tools and clean lines of communication between the ITAM and FinOps teams to keep things running smoothly:

    Example One:
    During the Microsoft Enterprise Agreement renewal process, a decision is made to reduce the number of SQL Server Enterprise licenses on which Software Assurance is renewed. This will require the Azure Hybrid Benefit to be removed from certain cloud workloads, resulting in increased cloud costs that need to be mitigated in other ways.

    Example Two:
    There is a blanket policy to activate Azure Hybrid Benefit for all applicable workloads in Azure. A new project is spun up consisting of dozens of Windows Server VMs and SQL Server instances which surpasses the number of on-premises licenses available; ITAM needs to be notified so they can purchase new licenses to ensure continued license compliance and, in most cases, keep spending at a minimum.

    Two Sides of the Same Coin

    In a hybrid environment, spend management and license compliance are often interlinked. So far, the software publishers have been relatively hands-off when it comes to policing and enforcement of their licensing rules in the cloud, but that could change at any point. Given that we’re already seeing the impact of the recession with layoffs across several major software vendors (Microsoft, Google) and Microsoft’s FY23 Q2 operating income dropping, traditionally on-premises software vendors such as Oracle, Microsoft, IBM, et al. may seek to realize untapped revenue in the cloud through license non-compliance audit penalties. While the examples above look at Microsoft licensing, the ability to use on-premises licenses in the public cloud exists with most software publishers and so, too, do the risks.

    A close relationship between ITAM and FinOps with regular and comprehensive data sharing and a clear understanding of each other’s priorities will be integral to the growth and development of any business using software and cloud services. Ensuring the best use of existing assets, enabling the most cost-effective cloud spending and reducing the risk of unexpected budget hits are all fundamental aspects of ITAM and FinOps collaboration.

  • Optimizing Cloud Costs for DevOps With AI-Assisted Kubernetes

    Optimizing Cloud Costs for DevOps With AI-Assisted Kubernetes

    As indicated in my prior blog, 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 the landscape for cloud-native optimization approaches and a features requirement blueprint 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.

    Cloud-Native Optimization Approaches Landscape

    As indicated in the article Tricks for Cloud Cost Optimization, “Cloud cost optimization (CCO) is a technique of running cloud-native applications effectively, at minimal possible cost, without affecting the health of the services.” The most typical approaches are variants of the following:

    • Rightsizing pre-paid, fixed and reserved instances: Cloud service pricing models are intended to fit your application and business needs with the hundreds of choices available from cloud service providers. This approach can be cost-efficient when application and business needs are constant over time. However, this approach is not sufficiently cost-efficient for many applications and business needs that are constantly changing, such as use cases for DevOps, DevSecOps and SRE.

    • Spot instances can offer low cost-per-instance, but reliability is not guaranteed because the cloud provider can interrupt these services anytime. Unless the use of spot instances is limited to workloads that do not require a high level of reliability, this approach is limited. This approach does have the potential to have a broader application if a smart management layer is implemented to orchestrate the use of the spot instances.

    • Pay-as-you-go offerings by cloud service providers, used together with infrastructure-as-code (IaC) and auto-scaling, can help save on cloud costs. This approach facilitates the automatic spin-up of resources when needed and automatic shutdown when not needed. However, to realize the benefits of this approach requires constant supervision of cloud usage and manual adjustments to realize the benefits. Businesses may not even be aware of the resource scaling until the monthly bill arrives.

    • Cloud auto-stopping of entire applications and clusters can help to manage cloud resources automatically to ensure that they run only when needed, never when idle. This approach is not granular enough to sufficiently reduce costs for rapidly fluctuating resource needs for DevOps, DevSecOps and SRE use cases.

    • Manual cloud costs management, in which team members are taught to understand their own cloud spend and cloud cost management practices, can help reduce costs. However, this approach is subject to human involvement, is slow and generally does not provide granular controls needed to sufficiently deliver cloud cost savings 24/7.

    None of the traditional cloud cost optimization approaches described above have the requisite smarts, speed or granularity to sufficiently optimize the highly dynamic requirements for DevOps, DevSecOps and SRE use cases. An AI-assisted orchestration approach, when supported with the right features, can make up for the deficiencies of the typical optimization approaches.

    Features for AI-assisted Kubernetes Orchestrator

    As indicated by CAST AI an AI-Assisted Kubernetes orchestrator needs the following features:

    • Easy to start – It should take less than five minutes to fully onboard a cluster.
    • Easy to use – The orchestrator should abstract layers of complexity, so little knowledge is needed to use it other than a basic knowledge of running Kubernetes clusters in a public cloud. For example, a working knowledge of the kubectl command line utility for creating and managing Kubernetes clusters.
    • SaaS configuration – Avoids the need to host and manage the orchestrator itself.
    • Autoscaler policies – Define threshold values and upper bounds so instances are automatically added or removed as per the policy.
    • Cloud Support for AWS EKS, GCS GKS, Azure AKS and kOps clusters
    • Reports to monitor and track cost savings for each cluster.
    • Features to optimize each cluster.
    • High availability to ensure the orchestrator itself is not a failure point.
    • Collect and analyze each cluster configuration to provide the most optimal setup along with a savings estimation for the current cloud environment.
    • Security – Detect and monitor K8s vulnerabilities and configuration issues.

    Roadmap for Implementing AI-Assisted Kubernetes Orchestrator

    According to the article Roadmap To Cloud Cost Optimization, organizations need to understand that they need to deploy cloud computing the right way. This not only paves way for the actual digital transformation but is even instrumental to cloud cost management.”

    The article Top 3 Issues in Kubernetes Cost Management indicates, “Teams cannot manage and monitor Kubernetes’ costs without having the right tools in hand. No doubt, you can collect all the data yourself and create the right solutions. It wouldn’t be easy to modify these solutions if changes are required.” The speed of change with DevOps, DevSecOps and SRE is not compatible with the typical tools.

    A good example AI tool, CAST AI, indicates how easy it can be to onboard a Kubernetes cluster. First, connect your Kubernetes cluster to CAST AI and see how much you can save by optimizing cluster configuration. After exploring the available savings and cost reports, you can onboard the cluster into CAST AI and set the Autoscaler policies, which will manage the cluster for you. It takes less than five minutes to fully onboard a cluster.

    Benefits of Solutions Using AI-Assisted Kubernetes Orchestrator

    An AI-assisted cloud orchestrator can provide the following benefits.

    • Spot instance automation
    • Spot instance fallback
    • Real-time autoscaling
    • Instant rebalancing
    • Visibility into cloud usage and costs
    • Avoids over-provisioning
    • Cloud resources are not left idle
    • A consistent approach between teams and departments
    • Reduce monthly average cloud spend by up to 60%

    Summary

    The prior blog Optimizing Cloud Costs for DevOps With AI-Assisted Orchestration explained why an AI-assisted Kubernetes orchestrator is needed to optimize cloud costs for DevOps, DevSecOps and SRE. In this blog, specific requirements for such an AI-assisted Kubernetes orchestrator was explained using CAST AI as an example. The steps to onboard a cluster to the AI tool was explained.

  • Fiberplane Adds Wasm Plug-in Framework for DevOps Notebook

    Fiberplane Adds Wasm Plug-in Framework for DevOps Notebook

    Fiberplane today announced it is extending the reach of a real-time collaboration notebook designed for DevOps teams by making available tools for building plug-ins based on the WebAssembly (Wasm) framework.

    Micha Hernandez van Leuffen, Fiberplane CEO, said these plug-ins, dubbed providers, will make it much simpler for anyone to connect the Fiberplane notebook to other DevOps tools and platforms.

    The Fiberplane notebook uses the same operational transformation algorithm used in Google Docs to enable teams to easily collaborate around a document or spreadsheet. The core platform itself is built in Rust and WebAssembly. That approach enables a DevOps team to, for example, write and run PromQL queries and display Prometheus charts alongside other data presented via an integrated graph. Wasm makes it possible to run those providers both in the browser and on a backend platform.

    Fiberplane also announced it is open sourcing its Provider Development Kit (PDK), written in Rust, to enable organizations or third-party developers to create additional plug-ins. A Fiberplane Daemon then executes the plug-ins. The overall goal is to provide an open format based on Wasm for consuming DevOps data, noted Hernandez van Leuffen.

    The full open source Fiberplane WebAssembly-based Plugin System includes a Fp-bindgen to provide the bindings generator for building plug-ins, the Provider Development Kit (PDK), a toolchain for building plug-ins, a set of pre-configured plug-ins for Prometheus, ElasticSearch, Sentry, Grafana Loki, Cloudwatch and a generic HTTP provider, the Fiberplane command line interface and the Fiberplane Daemon.

    Fiberplane is essentially taking the concept of notebooks used for collaboration by data science teams and applying it to DevOps workflows. The goal is to improve DevOps teams’ productivity by reducing the amount of time it takes to sort through multiple types and classes of DevOps data to resolve an issue.

    As IT environments become more distributed in the age of the cloud and microservices, troubleshooting issues now invariably spans the responsibilities of multiple members of an IT team. Fiberplane, in effect, makes it possible to spin up a virtual war room that enables the members of an IT organization to collaborate until the issue of the moment is resolved.

    The speed at which any IT issue is resolved has become a crucial metric. Given the complexity of IT environments, it’s inevitable that incidents will arise. Ideally, IT teams would discover those issues before they disrupt the business. However, in reality, the metrics organizations use to evaluate the effectiveness of a DevOps team are often how quickly IT issues are resolved once they are discovered. The longer it takes for a distributed DevOps team to marshal its resources, the more likely it becomes that team will be perceived as being inefficient—regardless of what level of application availability is actually achieved.

    Most DevOps teams have, of course, implemented a wide range of incident management best practices that create a level of muscle memory for responding to a wide range of issues. The trouble is there will always be unforeseen issues that arise. DevOps teams, as a result, need to find ways to quickly focus on an unpredictable issue that they didn’t anticipate.

  • More Java Apps Are Migrating to the Cloud

    More Java Apps Are Migrating to the Cloud

    A survey of 879 enterprise developers and architects from Vaadin, a provider of framework for building Java applications, found that, as part of modernization efforts, the pace at which Java applications are moving to the cloud is now accelerating.

    The survey found more than one-third (36%) of Java applications are already deployed in the public cloud. More than half of respondents (56%) are also already deploying some of their Java applications into Kubernetes or serverless environments. Nearly two-thirds (63%) said they planned to move more Java applications to the cloud over the next 24 months, the survey also found.

    Kim Weins, vice president of product and marketing at Vaadin, said the survey makes it clear that enterprise IT organizations are still highly committed to Java. Still, there is a clear shift underway in terms of where those applications are being deployed. More than a third of respondents (35%) said they have Java applications deployed on Amazon Web Services (AWS), while 22% have deployed them on the Microsoft Azure Cloud. Another 11% are running them on the Google cloud platform.

    This shift, however, will take time. Almost half (47%) of Java applications still need modernization. As a result, 63% of respondents planned to increase their investments in modernizing existing Java applications.

    Maintainability is the top-ranked motivation for modernizing Java applications (32%), followed by security (20%) and ongoing maintenance costs (10%), the survey found.

    The top three challenges in developing Java applications are building an intuitive and simple user interface (81%), upgrading the tech stack (81%) and ensuring app security (78%).

    There is also a shift underway in terms of the frameworks used to build and modernize applications using a more cloud-native approach. A full 70% of respondents use Spring today, but 50% also noted they are planning to increase their use of Spring Boot. Other Java frameworks used include Vaadin Flow, Quarkus, Hilla and React. While derivatives of Spring are the dominant framework, it appeared more organizations are at least evaluating other options, noted Weins.

    Most organizations are also integrating Java applications with modern tools for logging (72%), observability (61%) and single sign-on (53%), the survey found.

    The shift to Java 17 is also well underway, with nearly three-quarters of respondents (73%) using or planning to use it over the next year. More than a quarter (26%) are already on Java 17 or a later release. Another 21% are currently upgrading, while 26% plan to update in the next 12 months.

    Overall, the survey found Java is being widely used for both internal (64%) and customer-facing (62%) applications. Java is most often used to build full-stack Java apps (70%) and backends (69%), the survey found

    Finally, the survey found more than a third of respondents (38%) expected that finding and retaining developers would be a significant challenge in 2023.

    There are, of course, no shortage of options when it comes to deploying Java applications. Most organizations will deploy Java applications everywhere from the network edge to the cloud. The one thing all these applications will have in common is they will be written in a venerable programming language that itself has been modernized.

  • Watching the Watchers: Solving the Problem of Meta-Permissions

    Watching the Watchers: Solving the Problem of Meta-Permissions

    The move to the cloud and microservices has introduced new challenges in managing permissions. Software has been broken down into small, independently-deployable microservices, each with its own unique set of permissions. These permissions make it excruciatingly hard to ensure and track correct access. While this technological shift is challenging, it pales in comparison to the cultural and organizational shifts it has caused—one of which is the challenge of authorization for authorization. The challenge of authorization for authorization, or “controlling access control,” is a crucial but often misunderstood aspect of system design, and  its recursive nature is quite confusing.

    At its core, authorization for authorization deals with ‘meta-permissions’—the permission to grant and revoke permissions for the designed system.

    Controlling Access Control

    Deciding who can do things inside an application is one thing. Deciding who can decide (or, in other words, dealing with meta-permissions) is another story entirely. Once you start dealing with authorization for authorization, there are two main problems to contend with: Recursiveness, which is a technical challenge, and the question of trust, which can be hard to handle and can have dire consequences if handled incorrectly.

    Naively, developers often choose to be the superusers—the ones calling the shots; retaining all of the power with them. This can produce a very stable and secure application, but will quickly put a strain on precious R&D resources, turning developers into bottlenecks for the entire business operation.

    The opposite approach—delegating all of the power away from developers to other stakeholders—is equally dangerous, often creating a slow-moving, inefficient bureaucracy (looking at you, security and compliance) or an unstable, risk-filled environment (looking at you, sales and product).

    At the end of the day, it’s a question of balance—one that varies for every company and application.

    When building this balance, it’s important to empower the various stakeholders (and customers) working with the application, giving them a significant amount of control and decision-making abilities to enable the business to move quickly and securely while enabling developers to monitor the flow without becoming a bottleneck.

    To keep you on track as you tackle this challenge, here are some guidelines, do’s, and don’ts:

    Common Pitfalls to Avoid

    ● Don’t mix up authentication and authorization: This might seem trivial, but it happens all the time. Authentication is the process of identifying the user, while authorization is the process of granting access to specific resources based on the authenticated user’s roles or privileges. Solutions are required for both.

    ● Thinking you won’t need authorization for authorization: Simple systems may require meta-permissions functionality and advanced ones will undoubtedly need it. It’s important to consider when you’d need this ability and set the groundwork for it accordingly.

    ● Limiting access control to the vendor side: It’s not enough to delegate access control from developers to the rest of the organization. Doing so merely moves the bottleneck up the chain. To appropriately delegate the workload, you must be able to assign at least some access controls to the end customers themselves, providing them with true self-service.

    ● Thinking access control is limited to direct human use: Your first users are likely to be human users, but with increasing automation, more and more of your “users” will be automated agents—other applications and AI agents acting on behalf of humans. You will need to cater to them, too, and it might be sooner than you think.

    ● Delaying providing interfaces to non-technical people: A powerful interface that’s intuitive to non-technical users is crucial for access control systems.

    Best Practices

    ● Create a cascading waterfall of trust and permissions: By creating a cascading system of permissions and trust, you can ensure that the right permissions are granted to the right users at the right time. Often, developers and security would be the main source of this waterfall, but it mustn’t end with them. Design your flow to gradually delegate more and more between the different levels with each level empowering the ones below it.

    ● Assign an owner: To avoid conflicts, such as two admins being able to remove each other, always have a primary admin, or “owner,” who takes precedence to avoid conflict. Owners often cannot be removed without transferring the title first.

    ● Identify bottlenecks early on: Identify potential bottlenecks in permission delegation (permissions that are hard to delegate, or manage) and have a plan and interfaces to mitigate in advance before friction piles up.

    ● Use a classic policy model (e.g. RBAC, ABAC) for your meta-policy: Just like with your regular permissions, there’s no need to reinvent the wheel. Start with common policy models first.

    ● Use the same policy model for your meta-policy: This can help to ensure consistency and ease of understanding across the system, lowering the cognitive load on system managers and users.

    ● Have meta audit logs: The information on who changed the meta-permissions is just as critical, if not more so, than who changed the permissions. Log it and track it.

    ● Build on top of existing AuthZ for AuthZ: Use tools that have authorization for authorization already baked into them (such as Permit.io), saving the effort of starting this from scratch.

    In conclusion, solving the problem of meta-permissions requires a multifaceted approach that considers both the technical and cultural challenges associated with modern software systems. By following the best practices outlined above and by carefully thinking through the design of the interfaces and trust flows that govern the system, it is possible to create a system that is secure, usable and ready to accelerate to the velocity required by modern cloud-empowered business today.

  • The Evolution of DevOps: Developer Productivity and Platforms

    The Evolution of DevOps: Developer Productivity and Platforms

    This article is part two in a series of three on the rise of platform engineering and its role in improving the developer experience. Read part one here.

    Developer experience is business-critical in organizations of all sizes and across all industries. In the first article of this series, I make the case that the cloud-native developer experience will be shaped and eased not only by platform engineering but also by the vital support of DevOps and/or PlatformOps teams. This flies in the face of the recent and somewhat controversial assertion that DevOps is facing extinction. In fact, it’s possible that DevOps is more important than ever, even if the role of DevOps has changed in the era of cloud-native development, supported by centralized developer platforms.

    Business stakeholders who depend on reliable, stable, scalable and secure software shipping fast and consistently understand the business case for an integrated DevOps team, and most developers and their teams understand the challenges of coding, shipping and running cloud-native software without the guideposts offered by a platform (and the DevOps team). The complexities of Kubernetes and microservices (and their contingencies) make getting to productivity difficult, which is why developer platforms are touted as the magic-bullet solution. But these platforms don’t build and maintain themselves, and the concept hasn’t quite reached the level of maturity at which developer platforms are available as commercial, out-of-the-box offerings.

    Developer Platforms: Who Paves the Developer Path?

    DevOps is not dead and claiming that it is ignores the need for the surrounding, supporting roles that pave the developer path. DevOps is evolving, in some cases into PlatformOps, and keeps workflows flowing and manages operations that support developers’ ability to ship their work into the world.

    Who paves the developer path? It’s actually a cooperative process between developers and DevOps/site reliability engineering (SRE) teams. In discussions with DevOps and SRE leaders about cloud-native development, one trend was a throughline: DevOps and SREs continue to play an instructive role in helping guide developers to realize the possibilities of self-service through supporting platforms.

    The level of full-service ownership this amounts to for developers varies depending on the organization and its goals. But the role of DevOps is still clear. For developers, there is a significant learning curve, and DevOps can help clear the way to the centralized developer platform. This platform, assuming all goes as planned, will not only improve the developer experience but also relieve DevOps teams of the firefighting that has been typical of their job until now. Paving the path provides an opportunity for DevOps/SREs to both develop better operational support mechanisms for developers as well as engage in more long-term and strategic operational work.

    DevOps Ways: Unlocking Developer Productivity via Developer Platforms

    Helping unlock developer productivity is one aspect of powering a positive developer experience. And the shift to a developer-first platform model reinforces the business commitment to the developer experience. It becomes defined by its optimized tools and workflows, which make up developer platforms. The platform approach also supports wider adoption of cloud-native development across larger organizations and broader industries beyond the more niche applications we’ve seen, thanks to clearer guideposts and abstractions.

    But becoming dev-first doesn’t kill off ops, which has been one recent point of contention. In fact, the three ways of DevOps continue to be critical:

    ● The First Way: Flow/Systems Thinking
    ● The Second Way: Amplify Feedback Loops
    ● The Third Way: Culture of Continual Experimentation and Learning

    Quoting industry luminary Gene Kim, “The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department—this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).” Essentially, it doesn’t matter who constructs the platform as long as they are thinking about the entire value stream, starting with customer requirements which, for an internal platform, are driven by developers.

    The Second Way is focused on creating right-to-left feedback loops. To quote Kim again, “The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.” For platforms, this hints at embedding both developers in platform teams and ops in development teams.

    The Third Way is focused on creating a culture that fosters two things: Continuous experimentation, taking risks and learning from failure and understanding that repetition and practice is the prerequisite to mastery. The platform you build today won’t be the platform you need tomorrow. This is why the ‘big bang’ approach to building platforms doesn’t work. Think big, start small and iterate fast. This is something DevOps is designed to do.

    In supporting the cloud-native paradigm, DevOps is far from dead. It’s a shifting discipline that involves a focus on centralizing workflows and infrastructure to improve the developer experience and reduce their cognitive toil. This toil stems from developer guesswork, and DevOps is best positioned to remove that obstacle. If we concede that developer experience is central to business success, and devex depends on being able to code, ship and run quickly and safely, DevOps is the fixer who enables crucial self-service access for developers and, as we will explore in the third and final part of the series, “platforms” the developer experience.