devopsy.kinsta.cloud

Category: IT as Code

  • Gremlin Adds Detected Risk Tool to Chaos Engineering Service

    Gremlin Adds Detected Risk Tool to Chaos Engineering Service

    Gremlin today added a risk detection capability to its chaos engineering service that automatically identifies issues that could cause outages along with recommendations to resolve them.

    Enabled by agent software deployed in an IT environment, the Detected Risk tool makes it possible to benefit from chaos engineering techniques without needing to construct experiments or run reliability tests.

    Gremlin CTO Kolton Andrus said that approach eliminates much of the friction that previously limited adoption of chaos engineering best practices to improve the resiliency of IT environments.

    Chaos engineering is rooted in a resiliency testing philosophy that posits applications should be able to keep functioning regardless of any service or infrastructure failure. Most IT organizations, however, don’t have the expertise required to build the tools required to test resiliency based on the “Chaos Monkey” principles—pioneered by a Netflix project by that name—that, for example, randomly turns services off to see if an application fails.

    Each DevOps team will need to evaluate Gremlin’s recommendations before implementing them, but the overall goal is to provide IT teams with a better understanding of the level of risk attached to, for example, a misconfiguration of a server. To do so, the tool uses a scoring mechanism provided by Gremlin, noted Andrus.

    The challenge is that as IT environments become more complex, the level of dependencies between applications and infrastructure continues to increase. It’s often impossible for DevOps teams to manually keep track of all the hidden dependencies that might exist when IT environments are continuously being updated.

    In theory, of course, adopting cloud-native applications based on microservices should make IT environments more resilient as calls to application programming interfaces (APIs) are rerouted in the event of an outage. Nevertheless, there are almost always dependencies that get overlooked as these applications evolve, which creates a potential single point of failure.

    Naturally, not every IT team is always comfortable with the concept of deliberately breaking things to better understand what issues might cause an outage. As organizations become more dependent on software to drive critical processes, however, a more proactive approach to ensure resiliency is required, added Andrus.

    In fact, business leaders are becoming less tolerant of outages that result in lost revenue, so DevOps teams are being held to a higher level of accountability. DevOps teams may appreciate the value of a blameless culture that encourages everyone to learn from their mistakes, but IT leaders still get fired when there are too many outages, noted Andrus.

    Less clear is the degree to which the rise of artificial intelligence might affect chaos engineering. At the very least, AI models should make it easier to assess levels of risk, but the cost of using those technologies to achieve that goal is substantial, especially when platforms that provide the same outcome already exist.

    Regardless of approach, however, when it comes to resiliency, everyone agrees that the value of application uptime is now beyond measure.

  • Styra Makes Source Code Available for Enterprise Edition of OPA

    Styra Makes Source Code Available for Enterprise Edition of OPA

    Styra is now making the enterprise edition of the Open Policy Agent (OPA) available under a source license that enables IT teams to modify or change the underlying code as they see fit when integrating it with other applications.

    Enterprise OPA is a drop-in replacement for OPA, agent software for implementing policy-as-code that is already available under an open source license. Styra’s enterprise edition provides access to a version that provides better performance, native integrations for a suite of data sources and additional capabilities such as policy decision analysis.

    Previously, Enterprise OPA was only available in either a binary or container format. While these formats enable Enterprise OPA to be widely used, they limited it from being built directly into applications for performance optimization because no access was provided to source code.

    Chris Hendrix, director of product management for Styra, said the source license also provides organizations with an assurance that they will be able to continue to modify Enterprise OPA in much the same way as they modify the open source edition.

    It’s not clear how many DevOps teams are managing policy-as-code within their pipelines, but as application security regulations become more stringent, it’s only a matter of time before most of them do so in one way or another. Styra’s approach relies on a Rego programming language that some DevOps teams have found challenging, however. To make it simpler, the company is working on a low-code approach that would help make Enterprise OPA more accessible, said Hendrix.

    In addition to encouraging more DevOps teams to use Enterprise OPA under a source license, Syra is clearly moving to make it more attractive to replace existing instances of OPA with a more robust implementation licensed from the company. No one knows how many instances of the open source edition of OPA advanced under the auspices of the Cloud Native Computing Foundation (CNCF) are running in production environments. But as those applications become more complex, the need for deeper levels of integration enabled by a faster version of OPA becomes more apparent.

    OPA enables developers to programmatically embed compliance controls without waiting for a compliance team to make them available. That ultimately makes it simpler to ensure that the proper controls have been implemented before an application is deployed in an on-premises IT environment. That capability also makes it easier to document which controls have been applied to make any audit less time-consuming.

    Shifting responsibility for compliance controls to the left also enables DevOps teams to better understand which controls address specific regulatory mandates incorporated into most applications versus which controls might be specific to a specific regulation. Armed with those insights, it then becomes simpler to incorporate policy-as-code within a DevSecOps workflow.

    Hopefully, more applications running in production environments will soon be secure by default. Naturally, one of the first places to start is by making sure the compliance controls needed to achieve a baseline level of security have been pervasively implemented.

  • IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM Previews Generative AI Tool for Converting COBOL to Java

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

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

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

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

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

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

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

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

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

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

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

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

  • How Platform Engineering Can Drive Digital Sobriety

    How Platform Engineering Can Drive Digital Sobriety

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

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

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

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

    A New Kind of Business

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

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

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

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

    Driving Digital Sustainability From the Ground Up

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

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

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

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

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

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

    Ultimately, it’s About Consuming Better and Consuming Less

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

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

  • New Relic Extends AI to Identify Alert Coverage Gaps

    New Relic Extends AI to Identify Alert Coverage Gaps

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

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

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

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

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

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

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

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

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

  • IBM to Provide Hybrid Cloud Service Based on VMware Cloud

    IBM to Provide Hybrid Cloud Service Based on VMware Cloud

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

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

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

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

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

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

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

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

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

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

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

  • VMware Looks to GitOps to Drive Edge Computing

    VMware Looks to GitOps to Drive Edge Computing

    At its VMware Explore 2023 event, VMware today unveiled an orchestration tool, dubbed VMware Edge, that promises to simplify the management of edge computing services at scale.

    At the same time, VMware has launched a Project Keswick initiative through which it will work with customers to define additional use cases for VMware Edge based on zero-trust principles and GitOps workflows for deploying applications. The company also unveiled a VMware Retail Edge platform based on VMware Edge and is planning to add additional offerings aimed at specific vertical industry segments.

    Finally, VMware is making available a managed connectivity service through which it will provide private 4G/5G wireless services.

    VMware Edge Cloud Orchestrator is based on a tool that VMware created to orchestrate the management of its secure access service edge (SASE) platform. That has now been extended to support a wider range of software running on edge computing platforms.

    Sanjay Uppal, senior vice president and general manager of service provider and edge for VMware, said the goal is to streamline the management of software-defined edge computing platforms via a single console. Achieving that goal requires the ability to identify and programmatically manage workloads distributed across a mix of networks, he added.

    VMware is betting that as more workloads are distributed to edge computing platforms, there will be a greater need to centralize the management of workloads running on platforms that are not always easy to physically access. Less clear, however, is to what degree those edge computing platforms will be managed by IT teams versus operational technology (OT) teams that are usually embedded within a department that manages a specific business process.

    However, regardless of who manages those platforms, they will be relying more on GitOps workflows to programmatically provision infrastructure and deploy applications that will need to be regularly updated. In fact, because these platforms are often dispersed across hundreds of physical locations, the need for a pull-based orchestration tool that works asynchronously is critical, said Uppal.

    In the longer term, IT teams should also expect artificial intelligence (AI) capabilities to be applied in a way that makes edge computing self-healing, he added.

    No one can say exactly how many organizations have adopted GitOps to manage the provisioning of both infrastructure and the delivery of applications, but it’s conceivable that edge computing will force the issue. The tricky part will be finding a way to manage those GitOps workflows at the necessary level of scale. Most DevOps teams already struggle with implementing DevOps workflows at scale, so if more workloads are to be distributed across hundreds of edge computing platforms, there will be a much more acute need for automation to consistently deploy, secure and update applications.

    Regardless of approach, however, there may come a day when the number of workloads deployed at the edge far outnumbers the number of workloads deployed in the cloud or in a data center. The challenge and the opportunity now is to get ahead of edge computing issues before they inevitably create a set of management issues that will be more difficult to address after applications have already been deployed.

  • VMware Looks to Streamline Multi-Cloud Computing Management

    VMware Looks to Streamline Multi-Cloud Computing Management

    VMware today integrated its console for managing cloud instances with its VMware Cloud Foundation to streamline the deployment of its software in on-premises IT environments.

    Announced at the VMware Explore 2023 conference, the latest edition of VMware Cloud will make it simpler to manage multi-cloud computing environments by combining VMware Cloud Foundation Software and VMware Cloud Services into a single platform.

    VMware also announced early access to an ESXi life cycle management cloud service for VMware vSphere+ that enables IT teams to centrally manage upgrades across a distributed vCenter environment. Additional updates to vSphere in the upcoming release include doubling GPU capacity per virtual machine.

    Krish Prasad, senior vice president and general manager for cloud infrastructure at VMware, said the goal is to improve the overall pace of innovation;  in addition to deploying workloads in on-premises IT environments, organizations are also deploying workloads on multiple cloud computing services.

    VMware Cloud is being made available in five editions that can either be managed by an internal IT team, an external services provider or by VMware. In addition, a VMware Ransomware Recovery service based on VMware Cloud is also generally available. Following a breach of an on-premises IT environment, VMware Ransomware Recovery will enable organizations to run production workloads in the cloud until forensics are completed. The company also unveiled a technology preview of cybersecure storage that will integrate recovery workflows with native vSAN snapshots and add support for Google Cloud VMware Engine.

    In addition, VMware is adding a managed NSX service delivered via the cloud, dubbed NSX+, that manages instances of the virtual networking software that runs on top of its virtual machine software. There is also now an NSX+ virtual private clouds (VPCs) option that isolates instances of the virtual networking platform.

    Finally, VMware is adding a VMware Cloud with VMware vSAN Max, which will make 8.6 petabytes of disaggregated capacity and 3.6 million IOPS per cluster available on demand later this year.

    VMware appears to be streamlining the number of platforms IT teams need to acquire to support and manage IT infrastructure at a time when more organizations are trying to navigate increasing economic headwinds.

    One way or another, IT teams will need to reduce the cost of IT at a time when IT environments are becoming more complex. VMware is betting that, given its dominance in on-premises IT environments, there will be a natural inclination to deploy more of its software in the cloud to create a more homogenous IT environment that is less complex.

    However, it’s not clear whether organizations are willing to pay extra for the privilege. Many organizations are now supporting multiple classes of virtual machines and associated software despite the fact that each additional platform raises the total cost of IT.

    In the meantime, many IT organizations are also awaiting the outcome of Broadcom’s effort to acquire VMware before deciding how to centralize the management of multi-cloud computing environments.

  • Rebellion Against Changes to Open Source Terraform License Mounts

    Rebellion Against Changes to Open Source Terraform License Mounts

    A segment of the community that has embraced open source Terraform software, originally developed by HashiCorp to provision infrastructure as code (IaC), has published a manifesto calling on the company to reverse recent changes made to licenses that determine how the software can be used.

    If that demand is not met, the group plans to launch its own fork dubbed OpenTF under the terms of the previous license that governed the usage of Terraform.

    Pawel Hytry, CEO of Spacelift, a provider of a platform for orchestrating the management of multiple IaC tools, said the issue comes down to restrictions that Hashicorp has put in place restricting use within platforms that have embedded it, in addition to limitations on how Terraform can be used in production environments.

    HashiCorp is shifting from a Mozilla Public License v2.0 (MPL 2.0) to a Business Source License (BSL) v1.1 in all future releases of its software including Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer and Vagrant, as part of an effort to maintain maximum control over its intellectual property.

    This shift will have a chilling effect on Terraform innovation because fewer individuals and organizations will want to contribute to advancing the tool, said Hytry.

    However, Hytry added, historically HashiCorp has not been perceived as not being overly receptive to contributions from external developers, so the bulk of the code used to create Terraform has come from developers working for HashiCorp.

    It’s not clear to what degree this firestorm impacts DevOps teams, but the fragmentation of open source projects stemming from issues that come down to revenue streams is increasing as it becomes more difficult for vendors that create open source software to continue to increase the number of subscription services for the support they provide. Red Hat, for example, recently decided to no longer make the source code for the Red Hat Enterprise Linux (RHEL) edition of its operating system available. The decision led to Oracle, SUSE and CIQ pooling their resources to create a fork of RHEL that they promise will be compatible with future updates to RHEL.

    It remains to be seen how many vendors might throw their weight behind OpenTF. HashiCorp, in addition to having partners that built the business on the open source edition of Terraform, also has plenty of rivals that offer IaC tools.

    It may be a while before this conflict is resolved, but for now, the situation remains fluid, said Hytry. DevOps teams that make extensive use of Terraform will need to monitor events to make sure any future usage of Terraform complies with BSL terms that supporters of the manifesto claim are at this point too vague.

    In the meantime, organizations that rely on open source software should brace themselves for any abrupt changes to licensing terms that may be forthcoming in more challenging economic times. In fact, one of the hidden costs of using open source software is the different terms and conditions under which it is licensed. Resources to monitor each additional instance of open source software for compliance, with terms and conditions that are not always as simple or clear cut, need to be dedicated to a task that doesn’t make any meaningful contribution to return on investment.

  • DevOps Download: What to Know About Life in the Cloud(s)

    DevOps Download: What to Know About Life in the Cloud(s)

    According to the 2022 Flexera State of the Cloud Report, 89% of cloud customers now use multiple cloud hosting providers. Nearly nine out of 10 might sound high, but it tracks with the anecdotal evidence we’ve seen. For varied and good reasons, companies are spreading their usage across multiple hyperscalers rather than putting all their eggs in one basket.

    In this article, I’ll take a look at what life in the cloud(s) looks like today. Along the way, I’ll examine the value that companies and their DevOps teams can derive from this approach, the challenges to be aware of, use cases for making the multi-cloud move and more.

    What is Multi-Cloud?

    Multi-cloud is a type of cloud strategy approach where an organization uses computing services from at least two cloud providers to run their applications. Instead of a single-cloud stack, these environments include two or more public or private clouds, or a combination of both. With multi-cloud, you can have an application running on Google Cloud Platform (GCP), another in Amazon Web Services (AWS), and maybe one on premise for hard-to-move applications.

    There are three kinds of cloud setups. Single cloud is when workloads run solely on one environment. Hybrid cloud entails overlapping workloads across multiple clouds, such as operating the same programs on different providers for business continuity purposes. The final setup is planned multi-cloud, which disperses applications and usage across providers along specific lines, like having compute intensive applications with one provider and data analysis applications with another.

    Got a Preference?

    Make no mistake, using multiple cloud providers is more complex than a single host, but as its popularity shows, the benefits can carry more weight. Foremost, that’s because an organization gains the flexibility to create a best of all worlds situation, based on factors like the following:

    • Operational preference: Users may like different features from different providers, and splitting types of use can yield the ideal setup. For instance, a customer may run compute on AWS but want their business intelligence and machine learning on GCP. In this deployment, the front-end app could gather the needed information, then send the data to the other provider for analysis and ML.
    • Regulatory requirements: Certain workloads may require data storage in specific regions, but not all cloud vendors have multiple “regions” in each country. Companies that want to use the cloud can set up a “multi-region” environment by having one region on AWS and a second region on GCP within the same country.
    • Cost savings: Cloud providers offer different savings plans. For a savvy user, structuring a flexible program can take advantage of each to significantly reduce costs. It’s also a great way to avoid the pitfalls of lock-in and can make it easier to go elsewhere should a provider lose your trust.
    • Failsafe Options: Outages happen, so companies needing 24/7 access to apps will sometimes run portions redundantly on two hosts to ensure smooth operations. For example, a retail app may run on GCP and AWS with live failover between them. That way, if one goes down the other can kick in without noticeable downtime.

    Not Without its Challenges

    The benefits to running a multi-cloud setup are clear, but there are some challenges as well. A carefully planned multi-cloud setup can save money, but a careless approach will duplicate operations and cost. It also leaves companies vulnerable to mistakes that can lead to significant overrun, especially for hybrid cloud operations, which can be extremely complex. Specialists must be well versed in FinOps principles and experienced at writing modern applications that can scale and work across regions and clouds, to ensure success in a multicloud approach.

    Coming to Terms

    You’ll undoubtedly come across a lot of new ideas and terminology when researching cloud setups. Here’s a few of the more crucial ones to become familiar with as you plan strategy.

    • Lift and shift: This refers to cloud-to-cloud migration, in other words, taking what you have in one cloud and putting it in another, whether it is private to public or public to public.
    • Move and improve: This usually refers to migrating while making a small change to take advantage of a public cloud feature. For instance, you could be using open source Kubernetes on premise but want to move to a managed version. Eliminating management of Kubernetes would require a minor change but it improves operations greatly.
    • Cloudbursting: On premise offers hard limits to capacity. For companies able to anticipate business peaks, cloudbursting can scale workloads to an on-demand public cloud for a short period. For example, a retailer who operates on premise may cloudburst on Black Friday in order to handle a volume increase.
    • High Availability: The goal of this is to eliminate single points of failure by enabling users to continue working even if one of the IT components that an applications depends upon fails.
    • Disaster Recovery: Clouds offer solutions to help an organization restore critical systems and data after a disaster strikes. Recovery comes in three “heat levels”: Cold is for data backup only, warm restores operations in several hours, hot is for near-instant resumption of cloud operations.

    People and Processes

    The most important considerations for operationalizing multi-cloud are people and processes. Providers pump out new services fast, and not only can it be difficult for staff to keep up, it can be demoralizing when they’re unable to. Allowing time to succeed, fail and learn is key, and larger companies might consider designated specialists for each platform.

    When it comes to processes, management and security are highly customizable, but it requires deep knowledge to get them right. Operating via infrastructure as code rather than ClickOps is a must. The latter is a time consuming approach that requires selecting options in a provider menu and introduces both operational and security risks in the form of configuration drift.

    Life in the Clouds

    Multi-cloud brings strong benefits to DevOps. Organizations can get the right infrastructure balance based on their needs. Distributing workloads can reduce the impact of outages and bolster resiliency. There’s greater opportunity for cost savings, and scaling is simple. Ultimately, multi-cloud operational enhancements can result in more reliable and innovative solutions, which delivers on the mantra of DevOps itself.