devopsy.kinsta.cloud

Category: IT as Code

  • Lineaje Allies With Persistent Systems on Open Source Software Remediation Service

    Lineaje Allies With Persistent Systems on Open Source Software Remediation Service

    Lineaje this week revealed it has partnered with Persistent Systems to provide a managed service for remediating open source vulnerabilities that leverages artificial intelligence (AI) technologies.

    Persistent is extending an existing open source software maintenance service by incorporating a Lineaje platform that makes use of machine learning algorithms to analyze software bill of materials (SBOMs) to provide recommendations for fixing code and surface remediations such as updates that should be applied.

    Lineage CEO Javed Hasan said Persistent Systems is augmenting that capability with a dedicated team of specialists that IT organizations can contract to maintain open source code along with previous investments the managed service provider has made in large language models (LLMs) that add generative AI capabilities.

    Options for the services range from simply identifying issues that an internal IT team should address to a white glove offering through which Persistent Systems ensures all open source components are continuously updated.

    In the wake of an executive order issued by the Biden administration that requires federal agencies to better secure their software supply chains, more attention is being focused on the inherent cybersecurity risks associated with employing open source software to build applications. Many open source projects are led by a handful of maintainers that often lack the time and skills required to ensure the components they employ have not, for example, been compromised by malware that might find its way into downstream applications.

    Those maintainers are not being paid, so cybersecurity patches to open source software might not be readily made available, and even when they are, many organizations lack the skills and resources required to apply them in a timely manner. The majority of known vulnerabilities within application environments are still unpatched. Many IT teams are also reluctant to upgrade components for fear of breaking applications that have dependencies that are often difficult to track.

    It’s not known how much of the open source software that many developers routinely incorporate into their applications might contain vulnerabilities that could be exploited, but the level of technical debt that has accrued over the last several decades is considerable. While only a small percentage of those vulnerabilities have been exploited, cybercriminals are becoming more adept at discovering them.

    Hopefully, more contributions to open source projects will improve the overall state of application security, but in the meantime, it’s clear organizations will need to rely more on AI to drive DevSecOps workflows as ever-increasing amount of open source software continues to be relied on to build applications, said Hasan.

    The challenge, of course, is identifying which vulnerabilities, if exploited, will have the biggest impact on the organization. After all, at this point, it’s not possible to defend every application so the focus needs to be on prioritizing remediation efforts based on their actual severity rather than a general rating.

    In the meantime, DevSecOps teams would be well-advised to have incident response plans in place for remediating breaches involving both known and zero-day vulnerabilities that, in addition to being all but inevitable, can now be exploited within minutes of being discovered.

  • How DevOps Teams Can Unlock Cloud Savings and Improve DevEx

    How DevOps Teams Can Unlock Cloud Savings and Improve DevEx

    Can DevOps engineers unlock cloud cost savings for their organization that are incremental to what cost optimization tools offer (and improve the developer experience in the process)? Absolutely. Allow me to illustrate how.

    Reserve instance buying optimization and auto-stopping are proven tactics to reduce waste, but are those the only forms of waste that exist in your cloud budget? Of course not.

    Think about all the times environments have been brought up and then stayed up longer than required. Consider all of the times a commit changed the way data is stored, which spiked the cost to operate. Or how about the times when a commit changed how memory was used, which resulted in unexpected autoscaling?

    Collaborative Cost Management

    So the question becomes, what is the most efficient way to identify and root out additional savings while also balancing governance and agility? Bottom-up, collaborative cost management may offer a solution.

    A bottom-up approach to cost management involves pushing knowledge and functionality to the edge of the application and data engineering teams that own and operate code every day. This does not mean ceding centralized cost control to developers but rather arming them with timely, actionable insights inside their everyday workflow and, where appropriate, enabling action on a self-serve basis.

    How does this work in practice? It starts by enabling engineering teams to see the costs of the various services and environments they own on a timely basis. This helps teams understand when spikes occur and provides a path they can follow to understand why the spike occurred.

    That path can involve bringing different pieces of information together for engineering teams. They’ll want to see the costs of the individual resources that power their service or environment during the selected timeframe to see what spiked and maybe even drill down further to see the cost drivers of that individual resource. They’ll likely want to see deployments and commits, at a minimum, and maybe even explore observability data as well during this timeframe.

    Once they’ve identified a root cause, to the extent it involves needing to change a configuration setting of a resource, teams may want to understand a resource’s dependents, like other resources that are linked to it as well as any other environments and services that depend on it to size up the blast radius of a potential change. From there, they may wish to view config settings for the resource.

    Collaborative Discussion

    Finally, you want to give teams the ability to take certain actions on their own and, in other cases, foster a collaborative discussion between engineering and DevOps. You can accomplish the former via self-service actions, which are simple no-code workflows in which a developer can see if the DevOps team has allowed an action to be seen by a specific team for a resource via a role-based access control (RBAC) model. These workflows connect to your existing infrastructure-as-code (IaC) or CI/CD tools to orchestrate the desired change, leveraging golden paths defined by DevOps. This approach alleviates developers’ cognitive load and TicketOps for the DevOps team. For various changes that require coordination with DevOps, your engineering teams can have a collaborative discussion on a timely basis thanks to the fresh, actionable information you’ve made available to them.

    So what does it take to actually implement this vision? It’s easier than you might realize.

    Chances are, your existing cost optimization tool cannot provide cost visibility at the level of granularity and freshness developers need – daily cost insights at the service (or data pipeline, ETL job, etc.) level. That’s okay, though. Collaborative cost management is an incremental tactic that can still leverage some of the insights in these tools.

    The easiest way to facilitate this competency across your enterprise is via an internal developer portal. Internal developer portals are living sociotechnical knowledge maps that connect various data from your tools, clouds and teams to your services and the teams that own them. They are the perfect conduit to slice cloud cost data at the service level and put it in front of application and data engineers in their everyday workflow.

    Backstage, an open source framework to build a developer portal, offers a cloud cost plugin, though it involves a time commitment to set up, and the information it makes available to your developers may be limiting in the context of this scenario. For instance, your team may be unable to see per-resource costs, individual resource cost drivers, blast radius information and config settings. You must also expend effort wiring actions to support resource changes.

    You could also try building a BI dashboard for your team to accomplish this. This would require ingesting daily cost feeds from your cloud and then allocating the cost of each resource to each environment and to each service leveraging proprietary resource<->environment<->service mappings you would build and maintain as your system evolves. You would also need to build scripts and leverage IaC and CI/CD tooling and teach your engineers how to discover, configure and execute these actions.

    However you choose to get to this destination, collaborative cost management is a powerful emerging competency that can lead to meaningful savings and improve the developer experience by empowering your teams with the knowledge and functionality they need to manage costs on a proactive and, where appropriate, self-service basis.

  • Microsoft Previews Additional Copilot Tools for Azure

    Microsoft Previews Additional Copilot Tools for Azure

    At its Ignite 2023 conference, Microsoft this week previewed Copilot tools to simplify the management of the Azure cloud service along with a tool that streamlines the building and deploying of artificial intelligence (AI) applications on the Azure platform.

    In addition, Microsoft launched Microsoft Copilot Studio, a low-code tool that automates the process of creating data integration plugins and adding custom copilots within the Microsoft Copilot for Microsoft 365 tool that Microsoft previously launched.

    Microsoft Copilot for Azure leverages large language models (LLMs) to enable IT teams to use natural language to create, configure, discover and troubleshoot Azure services. It also enables IT teams to create complex commands, ask questions and optimize costs.

    Erin Chapple, corporate vice president for Azure Core at Microsoft, told Ignite attendees that Microsoft, along with a handful of customers, is already using Microsoft Copilot Azure to manage Azure infrastructure.

    In the long term, it’s clear that Microsoft is moving toward streamlining the building and deployment of AI applications using Azure AI Studio, a framework for invoking the AI models that Microsoft makes available on the Azure platform. The goal is to make it possible for organizations to create their own copilots based on AI models they have trained.

    It’s still early days in terms of organizations leveraging AI models to build applications, but it’s already apparent that DevOps and machine learning operations (MLOps), along with data engineering and cybersecurity best practices, will need to converge. Microsoft is making a case for Azure AI Studio as the framework that will enable IT organizations to achieve that goal.

    Of course, Microsoft is not the only provider of IT infrastructure resources with similar ambitions, but thanks to its investments in OpenAI and the acquisition of GitHub, it is furthest along in terms of defining a framework for building AI applications at scale. Last week, GitHub previewed an extension of the Copilot tools it already provides to help developers write code that leverages generative AI to automatically propose an editable plan for building an application based on natural language descriptions typed into the GitHub Issues project management software. Copilot Workspace will generate editable documents via a single click that can be used to create code that developers can then visually inspect. Any errors discovered by application developers or the Copilot Workspace platform can also be automatically fixed.

    At the same time, GitHub has extended the scope and reach of Copilot Chat to make it simpler for developers to use natural language to discover issues in their code base.

    Generative AI is already having a massive impact on the rate at which applications are developed, but that code still needs to be reviewed. Chat GPT is based on a general-purpose large language model (LLM) that is trained by pulling in code of varying quality from all across the web. As a result, code generated by the platform might contain vulnerabilities or be inefficient. In many cases, professional developers still prefer to write their own code.

    Of course, not every programming task requires the same level of coding expertise. In many instances, ChatGPT will generate, for example, a script that can be reused with confidence across a DevOps workflow. There is no shortage of mediocre developers who are now writing better code thanks to tools such as GitHub Copilot, and soon, domain-specific LLMs will make it possible to consistently write better code based on validated examples of code.

    The next challenge is going to be finding a way to manage increased volumes of code. There is no doubt that AI will be applied to the management of DevOps pipelines, but for the moment, at least, the pace at which AI is being applied to writing code is already exceeding the ability of DevOps teams to manage it.

  • Nobl9 Allies With Microsoft to Simplify SLO Creation

    Nobl9 Allies With Microsoft to Simplify SLO Creation

    Nobl9 this week revealed it has integrated its reliability center platform for managing service level objectives (SLOs) as code with the Microsoft Azure Monitor service to make it simpler to both create and track service levels.

    The Nobl9 Reliability Center provides access to dashboards for a single source of truth about the state of reliability in an application environment based on the metrics collected from the SLOs that have been defined.

    Nobl9 Chief Growth Officer Kit Merker said the integration with Microsoft Azure Monitor is the first in a series that will ultimately make it easier to define SLOs using historical data collected by third-party tools.

    The Nobl9 Reliability Center is already integrated with more than 50 DevOps, observability and incident management tools through which it collects metrics, events, logs, traces, alerts to track incidents, releases, rollbacks, runbooks and other documentation.

    Those integrations will ultimately make it simpler for IT teams to create SLOs using historical data that today are still challenging to define from scratch, noted Merker. In fact, the data tracked by Nobl9 can be used to automate remediations via those integrations, he noted.

    As more microservices-based applications are built and deployed, it’s becoming more challenging to maintain SLOs across applications that have many more dependencies than legacy monolithic applications. Each feature and application programming interface (API) added over time conspires to adversely impact performance. It‘s not so much that any given service will outright fail as much as it is determining where degradations are occurring that result in SLOs not being met.

    Ultimately, each IT team needs to provide some sort of objective benchmark that assesses their overall effectiveness at delivering application services by making it simpler to track whether SLOs are achieved and maintained. Not every service needs to necessarily meet a stringent requirement. Instead, IT teams need to have confidence in the fact that, on average, certain levels of performance are being consistently maintained.

    That’s crucial because as more organizations depend on software to deliver digital services, any disruption is likely to have a direct impact on profit and revenue. As such, the reliability of application environments has become a major concern in an era where IT teams are now trying to manage distinct services rather than individual applications.

    The challenge and the opportunity now is to find a way to proactively reduce that stress by programmatically managing SLOs as code rather than having to overprovision infrastructure resources to ensure maximum availability at the highest cost possible. At a time when more organizations are encountering economic headwinds, that’s no longer a luxury they can afford.

    Each organization will need to determine for themselves how aggressively they need to manage SLOs. Of course, SLOs as a concept have been around for decades, but with the rise of digital services that span multiple organizations, the level of reliability DevOps teams are expected to provide is now being written into business contracts. Not surprisingly, the overall level of associated stress DevOps teams are experiencing has correspondingly increased.

  • Immutable Infrastructure: The Next Step for DevOps

    Immutable Infrastructure: The Next Step for DevOps

    Immutable infrastructure, a concept that is rapidly gaining traction within the dynamic field of DevOps, offers a transformative approach to organizational security for companies of all sizes. 

    Instead of the traditional method where existing components are continuously updated and modified, immutable infrastructure advocates for an entirely different philosophy: Components are replaced wholesale with new versions and never altered after deployment. This type of paradigm shift promises a plethora of advantages, chief among them being enhanced consistency and reliability, which is a potential game-changer for DevOps practices.

    This article offers a thorough exploration of immutable infrastructure, taking a look at its core principles and examining why it’s becoming a focal point in the DevOps community. To help further bring these concepts to life, we’ll thoroughly examine the tools and techniques that are pivotal in its implementation.

    Understanding Immutable Infrastructure

    Immutable infrastructure is rapidly gaining traction in the world of cloud services and DevOps for its innovative approach to managing servers and components. Once deployed, these elements are not modified or updated; instead, new servers are created from a common image whenever changes are necessary. 

    This type of approach simplifies rollback procedures and minimizes troubleshooting, as the integrity of servers is maintained. Furthermore, this methodology, facilitated by OS-level virtualization, marks a significant departure from more traditional practices.

    And with the AI market already worth $313 billion, integrations of models and solutions will only become more popular. Integrating AI into immutable infrastructure can significantly enhance its efficiency and reliability. 

    In such systems, AI can be used to monitor and analyze system performance continuously. By applying machine learning algorithms, it can predict potential issues and automate the process of deploying new server instances before problems arise. 

    Comparing Immutable and Mutable Infrastructures

    The Immutable Approach

    Immutable infrastructure offers streamlined change tracking and rollback, with each new server or VM being easily identifiable. Its uniform configuration across servers simplifies testing and the unaltered state post-deployment reduces complexity. 

    This makes it ideal for environments with numerous interdependent elements, such as in DevOps and cloud computing, virtually eliminating configuration drift.

    Challenges With Mutable Infrastructure

    In contrast, mutable infrastructure necessitates more time for server provisioning due to manual configurations. It’s prone to various update failures and connectivity issues, with each server’s unique configuration complicating diagnostics. 

    This traditional approach struggles with unpredictability, making it less suitable for modern DevOps practices and resulting in frequent configuration drifts.

    Advantages of Immutable Infrastructure

    Opting for immutable infrastructure brings numerous benefits. Support calls are significantly reduced and security is enhanced, thanks in part to the use of machine learning to identify anomalies. 

    The implementation of safelisting rules strengthens security controls. Moreover, this approach mitigates configuration drift and negates the need for synchronization during updates, leaning on cloud platforms for swift VM management. It also ensures rapid recovery due to easy rollbacks and encourages experimentation, thus fostering innovation.

    Best Practices for Immutable Servers

    Adopting immutable servers involves several best practices all organizations would be wise to apply. Building images in a chroot environment helps isolate changes while keeping test suites lean and efficient while avoiding overburdening the change process as a whole. 

    Caching installation files near the build location optimizes update speeds, layering images on top of a base server image expedites updates, and minimizing the OS image reduces boot times and security risks. Additionally, using containers can dramatically speed up and simplify the process.

    Essential Tools for Immutable Infrastructure

    When it comes to immutable infrastructure, certain key tools have emerged as indispensable for efficiently managing and maintaining this modern approach. These tools help create, manage and deploy server images and infrastructure-as-code throughout organizations. 

    Here’s a closer look at some of these essential tools:

    Packer

    Packer is a crucial tool for creating identical machine images for various platforms from a single source configuration. This tool is instrumental in the immutable infrastructure because it allows for the creation of fixed server images that can be quickly deployed, ensuring consistency across environments.

    Terraform

    Terraform by HashiCorp is another key player, enabling users to define and provide data center infrastructure using a declarative configuration language. It helps maintain the infrastructure-as-code, which is an essential aspect of immutable infrastructure. 

    Terraform allows for safe and predictable changes to infrastructure, with efficient management of both cloud and on-premises resources.

    Docker

    Nowadays, Docker is synonymous with containerization, allowing applications to be packaged into containers—consistent, isolated environments that encapsulate all the necessary components of immutable infrastructure. 

    Docker helps to simplify the deployment process and ensures that applications run the same way everywhere, aligning perfectly with the core principles of immutable infrastructure.

    Kubernetes

    While not directly mentioned earlier, Kubernetes deserves recognition for being a powerful orchestration tool for containers, including those that are managed by Docker. Kubernetes excels in automating deployment, scaling and management of containerized applications, which aligns well with immutable infrastructure principles.

    SaltStack

    SaltStack offers configuration management and orchestration tools, standing out for its ability to manage and automate more complex and scalable infrastructures, making it suitable for environments where immutable infrastructure is implemented. SaltStack ensures that server configurations are enforced and maintained as defined, preventing drift.

    Jenkins

    An open source automation server, Jenkins plays a significant role in the continuous integration and continuous deployment, or CI/CD, pipeline. Jenkins helps to automate the various stages of the delivery pipeline, which is crucial in testing and deploying immutable infrastructures.

    Ansible

    While Ansible is generally associated with configuration management, it also excels in automated deployment. Because it doesn’t require agents on the servers it’s managing and uses a simple, human-readable YAML syntax, it’s useful for setting up and maintaining immutable servers.

    Git

    Git, a version control system, is essential for tracking changes in the configuration code, scripts and templates used to create and manage immutable infrastructure. It allows teams to manage their infrastructure-as-code, ensuring a detailed audit trail of what was changed, when and by whom.

    Ultimately, a slew of tools and platforms are available to make the transition to immutable infrastructure as seamless as possible. From container orchestration with Kubernetes to configuration management through Ansible, you have a robust array of options at your disposal. 

    Yet, when it comes to handling specification files or any form of documentation, you want an added layer of security. A robust custom document viewer with extra security features, for instance, could be an invaluable asset in this regard, offering the ideal blend of accessibility and protection while ensuring that your infrastructure is immutable and secure from prying eyes.

    Choosing the Right Tools For Your Organization

    When integrating immutable infrastructure into your operations, selecting the right mix of tools that align with your specific requirements and existing workflows is crucial. Essential factors such as compatibility, scalability and ease of use should be considered to create a robust, efficient and effective immutable environment. 

    Each of the tools highlighted above has its own strengths and is a part of a broader ecosystem designed to support the reliable, consistent and secure deployment of applications and services across organizations of all sizes. Companies can fully embrace the immutable infrastructure model by learning how to properly harness these tools, improving stability, scalability and efficiency across all of their IT operations.

  • Redgate Automates Pulling of Test Data From Production Databases

    Redgate Automates Pulling of Test Data From Production Databases

    Redgate today added a Redgate Test Data Management (TDM) tool that automates the pulling of masked test data from databases running in production environments.

    David Gummer, chief product officer for Redgate, said this capability eliminates manual tasks that previously inhibited testing or resulted in personally identifiable information (PPI) being inadvertently used to test applications.

    Redgate TDM automatically classifies and masks data residing in SQL Server, PostgreSQL, MySQL or Oracle database before it is used to test an application. It then produces a copy or clone of that data that is a fraction the size of the original, said Gummer.

    That approach creates a repeatable process for DevOps teams that can withstand a regulatory audit of application development processes, he added. In fact, with the increased focus on software supply chain issues, more auditors are specifically reviewing how data is secured during the application development process.

    Designed to be invoked via a command line interface (CLI), within an integrated development environment or via a graphical interface, Redgate TDM reduces the friction that currently occurs when DevOps teams request test data from database administrators (DBAs), said Gummer. Many DBAs are either too busy to fulfill those requests or reluctant to provide access to sensitive data that would result in the organization running afoul of a compliance mandate.

    Developers then often resort to using anonymous data that doesn’t actually reflect the environment in which their application will ultimately be deployed.

    The amount of data that developers need to build applications is only going to increase. In the absence of any way to effectively automate the process of accessing that data, it ultimately takes longer to build and deploy stable applications. In many cases, applications are simply not tested as thoroughly as they should be before being deployed in a production environment, resulting in rollbacks that might otherwise be avoidable.

    Advances in artificial intelligence (AI) are making it easier to create test scripts, but much of the testing setup process is still based on manual processes that increase the overall level of toil.

    At a time when more organizations than ever are trying to increase developer productivity, automating relatively mundane tasks such as pulling test data can have a big impact. Developers want to spend as much time as possible focused on writing code. Everything else is a task that gets in the way of achieving that goal. While there is a general desire to empower developers, that doesn’t necessarily mean they want the cognitive load associated with building applications to increase. In fact, one of the reasons platform engineering has emerged as a methodology for managing DevOps workflows at scale is to reduce the current level of cognitive load developers experience today.

    Of course, DevOps teams are, by their nature, ruthlessly committed to automating as many processes as possible. The challenge is bottlenecks in those processes conspire to slow down the overall rate at which applications can be built and deployed despite the best intentions of all involved.

  • What the Future Holds for FinOps and DevOps

    What the Future Holds for FinOps and DevOps

    FinOps, or financial operations, is a cultural practice that brings financial accountability to the variable spend model of the cloud. It’s a strategic approach combining systems, best practices and culture to increase an organization’s ability to understand cloud costs and make informed decisions.

    In essence, FinOps is a framework for managing cloud operating expenses (OpEx). It’s about bringing together technology, business and finance professionals to ensure that companies can get the most out of their cloud investments. The goal is to provide businesses with a better understanding of their cloud usage and costs, enabling them to make strategic decisions about resource allocation and cost management.

    FinOps bridges the gap between finance and operations. It’s not just about monitoring costs; it’s about understanding why those costs occur, how they relate to business value and what can be done to optimize them. It’s a comprehensive, cross-functional and continuous approach to managing cloud expenses, ensuring that businesses can maximize their return on investment (ROI) in the cloud.

    What Does FinOps Mean for DevOps Teams?

    Traditionally, DevOps has been focused on improving the speed, efficiency and quality of software delivery. But with the advent of cloud computing, cost has become a crucial factor. The dynamic nature of the cloud, with its pay-as-you-go model, means that costs can quickly spiral out of control if not properly managed. This is where FinOps comes in.

    Budget Responsibility

    As a DevOps team member, you’re likely used to thinking in terms of speed, performance, and quality. With FinOps, you need to add cost to that equation. You’re not just responsible for delivering high-quality software quickly; you’re also accountable for the cost of that delivery. This requires a shift in mindset, moving from a project-based budgeting approach to a product-based one.

    In a project-based approach, you have a fixed budget for a specific project. Once the project is finished, so is the budget. In a product-based approach, on the other hand, you’re responsible for the ongoing costs of a product throughout its life cycle. This means you need to consider not just the cost of development, but also the cost of maintenance, support, and continuous improvement.

    Resource Optimization

    In the context of FinOps, resource optimization is all about making sure you’re getting the most bang for your buck. You want to ensure that you’re using your cloud resources as efficiently as possible, minimizing waste and maximizing value.

    Resource optimization can involve a variety of strategies, from rightsizing instances to eliminating idle resources. But it’s not just about cutting costs; it’s also about aligning costs with value. You need to understand the value that each resource brings to your organization and allocate costs accordingly. This requires a deep understanding of your cloud usage and a commitment to continuous monitoring and improvement.

    Collaboration With Finance

    One of the key aspects of FinOps is the collaboration between DevOps and finance. You’re no longer working in silos; you’re part of a cross-functional team working towards a common goal. This requires open communication, mutual understanding, and shared responsibility.

    As a DevOps team member, you need to understand the financial implications of your decisions. You need to be able to articulate the value of your work in financial terms, demonstrating how your efforts contribute to the organization’s bottom line. At the same time, you need to be open to feedback and guidance from your finance colleagues, learning from their expertise and incorporating their insights into your decision-making process.

    Performance Metrics

    Performance metrics are crucial in the world of FinOps. They provide the data you need to understand your cloud usage, monitor your costs and make informed decisions. But these aren’t just any metrics; they’re metrics that align with your business goals and reflect the value of your cloud investments.

    These metrics might include cost per workload, cost per user or cost per unit of output. The key is to choose metrics that make sense for your organization, providing meaningful insights that can guide your resource allocation and cost management efforts. And remember, these metrics need to be regularly reviewed and updated to reflect changes in your cloud usage and business needs.

    Automation of Cost Controls

    Automation is a key tool in the FinOps toolkit. It can help you streamline your cost management processes, reduce manual effort and increase accuracy. From automated alerts to automated remediation, there are many ways automation can improve your FinOps efforts.

    With automated alerts, you can be notified when your cloud costs exceed a certain threshold. This allows you to respond quickly, addressing issues before they become major problems. With automated remediation, you can take this a step further, automatically adjusting your cloud resources in response to changes in demand or performance.

    Future FinOps Trends

    The year 2024 promises to be an important one for FinOps, with several trends poised to redefine the landscape:

    1. AI Algorithms for Cost Analysis and Prediction

    The use of AI algorithms for real-time cost analysis and predictions is predicted to be a major trend in 2024. AI enables the automation of complex financial calculations and projections, allowing for more accurate and timely decision-making. AI is already not just analyzing and predicting costs but also providing actionable insights to optimize these costs.

    The power of AI in FinOps lies in its ability to process massive amounts of data quickly and accurately. It can analyze past and current financial data, identify patterns, and predict future trends. This means that instead of reacting to financial changes after they happen, you can be proactive and make strategic decisions based on accurate predictions.

    The use of AI in FinOps will also enhance risk management. By predicting potential financial risks, AI can help organizations take preventive measures and mitigate the impact of these risks. The integration of AI in FinOps is a trend you cannot afford to ignore if you aim for financial operations excellence.

    2. Empowering Teams to Manage Their Own Cloud Costs

    Traditionally, financial operations and cost management have been centralized functions. However, the advent of cloud computing and the shift toward decentralized work models have resulted in a new trend—empowering individual teams to manage their own cloud costs. In 2024, we can expect this trend to gain further momentum.

    In a cloud environment, costs are often directly linked to usage. This means that the teams using the cloud resources are in the best position to control these costs. By empowering these teams to manage their own cloud costs, organizations can promote accountability, encourage resource optimization, and ultimately achieve cost efficiency.

    This approach requires a shift in mindset and the development of new skills. Teams need to understand the financial implications of their actions and make cost-effective decisions. They also need tools and processes to monitor their cloud usage and manage their costs effectively.

    3. Managing Costs Across Multi-Cloud and Hybrid Cloud Deployments

    The use of multiple cloud providers and the coexistence of cloud and on-premises data centers have added a new layer of complexity to financial operations. Managing costs across these diverse environments is a major challenge, and it’s another trend that is expected to shape FinOps in 2024.

    With multiple cloud providers, each with its own pricing model and billing system, cost management can be a daunting task. Add to this the costs of maintaining on-premises data centers, and the complexity multiplies. In 2024, organizations will need to adopt strategies and tools that enable them to manage these costs effectively.

    One of these strategies is the use of cost management platforms that provide a unified view of costs across multiple environments. These platforms can track and analyze costs, allocate them to the appropriate departments or projects, and provide insights for cost optimization. They can also automate cost reporting and forecasting, easing the workload of financial teams.

    4. Emphasizing the Security Aspects of FinOps

    As financial operations become more complex, the risk of abnormal spending patterns or unauthorized activities increases. Identifying and addressing these issues promptly is critical to prevent financial losses and maintain financial integrity. In 2024, the identification of abnormal spending patterns or unauthorized activities will be a key focus area in FinOps.

    Tools and technologies that enable real-time monitoring and anomaly detection will play a crucial role in this regard. These tools can analyze financial data, detect deviations from normal patterns, and alert you to potential issues. They can also help you trace these anomalies back to their source, facilitating investigation and resolution.

    Moreover, organizations will need to strengthen their internal controls and governance mechanisms. They will need to define clear responsibilities and accountabilities, establish robust approval processes and enforce strict access controls. Regular audits and reviews will also be essential to ensure compliance and detect any irregularities.

    5. Measuring and Optimizing for Environmental Impact

    The environmental impact of financial operations is a concern that cannot be overlooked. As organizations strive to be more sustainable, measuring and optimizing for environmental impact is becoming a key aspect of FinOps. This trend is expected to gain prominence in 2024.

    The environmental impact of financial operations is largely tied to energy consumption. In a cloud environment, for instance, the energy consumed by data centers contributes to carbon emissions. Therefore, optimizing cloud usage not only reduces costs but also reduces environmental impact.

    To measure and optimize for environmental impact, organizations will need to track their energy consumption, calculate their carbon footprint, and implement strategies to reduce it. These strategies can include using energy-efficient technologies, optimizing resource usage and sourcing renewable energy.

    Conclusion

    In conclusion, FinOps is a dynamic and evolving field. The trends and predictions outlined above provide a roadmap for achieving financial operations excellence in 2024. By harnessing the power of AI, empowering teams to manage their own cloud costs, managing costs across diverse environments, emphasizing security in FinOps and optimizing for environmental impact, you can take your FinOps program to the next level.

  • BMC Mainframe Survey Results Show a Platform on the Rise

    BMC Mainframe Survey Results Show a Platform on the Rise

    What if I told you that the oldest active computing platform is also one of the most innovative, seen as a platform for growth and new workloads, not just by seasoned professionals, but by a new generation of stewards, too? The 2023 BMC Mainframe Survey shows just that. In addition to an overwhelmingly positive perception and growth mindset regarding the mainframe, the survey reveals that the majority of those who are most enthusiastic about its future are relative newcomers to the platform.

    Now in its 18th edition, the annual BMC Mainframe Survey gauges the opinions of more than 800 executive and technical professionals on a range of topics, from overall perception of the platform to top priorities, common practices and greatest challenges.

    This year’s results show that 94% of respondents have a positive perception of the mainframe, with 62% citing it as a platform to grow and attract new workloads. This tracks the 62% who report adopting DevOps practices on the platform. It’s no surprise, then, that two of the top five priorities cited by respondents are efforts to enhance automation and modernize applications. Organizations around the world recognize that the mainframe can be a leader in innovation, powering their digital transformations.

    Modern Management Approaches

    This innovation goes beyond the software and services developed for the mainframe to include those used to manage the platform. It’s reported that 35% of respondents listed the implementation of cloud technologies as one of their top four priorities for the coming year, with 41% saying they are considering cloud-based storage and backup. With the growing volume of mainframe data and the emergence of new regulations and standards governing data security and recovery, organizations are turning to cloud-based data management to reduce costs and improve recovery options.

    Year over year, the number of survey respondents reporting the use of AIOps hasn’t changed considerably, but those reporting its cross-platform use on both mainframe and non-mainframe systems has jumped 7% from 2021.

    Organizations are recognizing the need to take advantage of the greatest business values of AIOps — cited in the survey as improved uptime and the ability to detect problems quickly, understand trends and respond proactively — as part of a holistic approach to enterprise IT operations management.

    With increased cross-platform use, significant benefits and a decrease in the number of respondents reporting implementation challenges like cost, complexity and the need for specialized skillsets, BMC sees AIOps as an area ripe for significant growth in the coming year.

    Investment Pays Dividends

    Improving the availability, quality and efficiency of the mainframe, of course, requires investment. In our report on the results of the 2023 BMC Mainframe Survey, we compare the responses of maximizers (those planning to increase investment in the platform) with those of minimizers (those planning to decrease investment levels). The results are eye-opening.

    Maximizers have invested in future-proofing their workforce in a variety of ways, and the data bears that out; 81% have ten or fewer years of experience on the platform. The new generation of stewards sees the mainframe not as a legacy platform, but one of continued growth and innovation, worthy of the investment required not just to keep it modern, but to place it at the forefront of digital transformation.

    Another key difference between maximizers and minimizers relates to security, which was cited as the top overall priority of survey respondents for the fourth consecutive year. Maximizers are more likely than minimizers to have a dedicated resource to investigate security events and to have dedicated ransomware recovery capabilities in place. It should come as no surprise, then, that maximizers were 20% more likely than minimizers to report that their mainframe security controls for ransomware are extremely effective.

    These results show that the differences between maximizers and minimizers go beyond outlook, producing tangible effects on outcomes. The maximizers increasing their investment in the mainframe report fewer challenges with staffing and skills shortages and a stronger stance against increasingly sophisticated cyberthreats. The minimizers decreasing their investment in the platform not only have greater difficulty in maintaining a skilled workforce, which increases the risk of falling behind competitively, but it also puts their organizations at serious risk of potentially catastrophic security breaches.

    A Bright Future

    In short, the results of the 2023 BMC Mainframe Survey reflect a positive outlook for the platform’s future. By investing in their workforces and the tools required to advance and protect the platform while adopting modern techniques and practices, organizations can reduce risk and promote innovation that delights their customers.

  • Cutting Costs, Boosting Efficiency: The Economic Benefits of Framework-Defined Infrastructure

    Cutting Costs, Boosting Efficiency: The Economic Benefits of Framework-Defined Infrastructure

    In a world that’s constantly modernizing, developers are at the forefront of progress, embracing cutting-edge tools that match the pace. Industry-standard practices like infrastructure-as-code (IaC) are getting an update: Framework-defined infrastructure (FdI) is an approach to deploying applications that is quickly gaining popularity among developers, where the deployment environment automatically provisions infrastructure derived from the framework and the applications written in it. For developers, this serverless architecture means more reliability, increased productivity, top-of-the-line security and reduced costs.

    To modernize development practices, understanding the role of framework-defined infrastructure in defining and automating infrastructure—and its impact on the development experience in open source frameworks—is crucial.

    The Evolution From IaC to FdI

    Infrastructure-as-code (IaC) is the industry-standard practice for provisioning infrastructure in a repeatable and reliable way. Framework-defined infrastructure (FdI) is an evolution of IaC, where the deployment environment automatically provisions infrastructure derived from the framework and the applications written in it.

    In the early days of servers and the internet, we SSH-ed (or worse) into individual machines, running install scripts or even configuring production software using graphical user interfaces to provision infrastructure. As the web scaled, it became clear that this approach wouldn’t scale with it, and together with the DevOps movement, IaC became the best practice for provisioning infrastructure. The code in IaC represents a version-controlled description of the desired state of the infrastructure—which, when executed, will create the described system state. However, as the web continues to scale, developers must apply new processes and architectures to increase the efficiency of their workflows.

    Enter framework-defined infrastructure.

    Framework-defined infrastructure abstracts over cloud primitives such as servers, message queues and serverless functions, making them mere implementation details of the frameworks’ concepts. Frameworks use well-established patterns to provide structure and abstraction to applications, making them easier to write and understand by managing the high-level application flow while the developer writes code within the hooks provided by it.

    Framework-defined infrastructure takes advantage of both this inversion of control and the predictable structure of framework-based applications like Next.js to automatically map framework concepts onto the appropriate infrastructure without the need for explicit declaration or configuration of the infrastructure.

    Optimization for Serverless Environments

    Since framework-defined infrastructure lets the framework itself define the production behavior, local development can just use the framework’s own tooling, while production infrastructure is automatically configured to be a scaled and optimized representation of the same underlying behavior.

    IaC uses machine-readable files, which developers can version much like software, to provision infrastructure such as physical servers, virtual machines and higher-level services like databases or applications. Serverless architecture—which, despite its name, still uses servers—eliminates the need for developers to manage specific physical or virtual servers.

    Serverless products still require developers to define and deploy their respective serverless primitives, much like more traditional infrastructure. For example, in the archetype of serverless products, AWS Lambda, developers need to create a lambda function and deploy code to it.

    While serverless architecture greatly simplifies managing production infrastructure, the systems that run serverless code are often complex and proprietary, which can cause problems with local development. In a worst-case scenario, local development isn’t possible, and developers must test local changes by making comparatively slow deploys to the production infrastructure. In a best-case scenario, developers must create a local simulation of the complex serverless stack, which must stay up-to-date with the production environment. Framework-defined infrastructure completely eliminates this problem, as it is capable of automating the process for users.

    Framework-Defined Infrastructure and Immutable Deployments

    These days, application code is developed almost exclusively within version control systems such as Git. IaC maintains infrastructure definition in either the same or a sibling version control system. However, production infrastructure itself can only represent limited points in time of the infrastructure’s version history. This is fundamentally incompatible with framework-defined infrastructure, which expects that production infrastructure directly maps to the framework code at the same commit hash.

    Immutable deployments solve this impedance mismatch between an application’s and the infrastructure’s version history. Instead of deploying onto a limited number of infrastructures, immutable deploys create a completely new infrastructure for every single deployment that is ever made. For developers, this means lower IT complexity and failures, improved security, and easier troubleshooting, given there are fewer chances for unpredictable behaviors or unintended consequences of code changes.

    Naturally, immutable deployments are impossible in a world where infrastructure is mapped to finite physical resources. However, in a serverless world, where unused infrastructure can scale to zero, immutable deployments become possible to perform, as unused deployments do not take up physical compute resources beyond the baseline storage needed for their contents.

    Conclusion

    It goes without saying that framework-defined infrastructures rely on IaC as the ultimate infrastructure interface and, hence, could not work without the amazing work of its community. In order to modernize, it’s imperative for developers to leave behind infrastructure constraints and embrace a world where scaling applications becomes effortless, enabling them to optimize efficiency without sacrificing performance. For developers growing frustrated with scaling issues or the burdensome process of their development process, widespread adoption of framework-defined infrastructure is key to improving the developer experience.