Tag: Multi-cloud

  • A DevOps Reset for a Multi-Cloud World

    A DevOps Reset for a Multi-Cloud World

    In the world of DevOps, only two things really matter: 

    • To release applications and updates as quickly as possible
    • To have access to resources (processing, storage, networks) able to run those apps, as cost-effectively as possible. 

    The measures used to achieve these twin goals should work together seamlessly–otherwise, you’re inefficient. But software development and IT operations have been on separate journeys, and it now takes layers of tools, specialized expertise and lots of precious time to distribute and manage applications where they need to run. Organizations tolerate all this complexity (and the delays and costs that come with it) since they see no alternative. But what if there was an easier way?  I’ll examine the two fundamental shifts driving software development and IT operations and see why current processes are so cumbersome.  

    Shift One: From Monolithic Applications to Microservices

    In the beginning, applications were monolithic, with all functions and code packaged together. That approach was manageable when apps were updated once or twice a year, but not when updates are expected multiple times each day. Finally someone realized that applications would be much easier to build, improve and maintain if they were divided into smaller units called microservices—independent, loosely coupled, individually deployable services, each one addressing a specific function. 

    To support microservices, a technology stack has emerged, similar to steps on a ladder:

    • To make them portable, microservices are packaged in containers—a lightweight, standard way for applications to move between environments and run independently. Everything needed to run the microservice such as settings, system tools, libraries and dependencies is packaged inside the container.
    • A single application could have hundreds of containers associated with it. How do you manage them? Along came Kubernetes (aka K8s), open source software for deploying and orchestrating containers within a cluster of virtual machines. (Note the word cluster—the significance will be discussed momentarily.)
    • Since microservices are updated constantly, how do you make sure the correct version is running? Along came GitOps to provide version control for all updates to all those microservices. Git repositories provide a single source of truth for the desired application state, as well as a record of every code change.

    Finally, we need to set up continuous integration/continuous delivery (CI/CD) for rolling out application improvements and new features. Along came ArgoCD, a GitOps continuous delivery tool for Kubernetes that continuously monitors running applications, compares the current, live state against the target state specified in a Git repository, and resolves discrepancies.

    Shift Two:  From On-Premises to Multi-Cloud 

    Not long ago, IT departments were having hot debates about this strange new concept called the public cloud and whether it could possibly play a role in their operations. But once they discovered how easy it was to spin up resources, the floodgates opened.

    The first tentative steps typically involved hybrid clouds combining an on-site private cloud with spillover into a public cloud for workload spikes. These initial forays mushroomed to dozens or hundreds of clouds, in different locations and with different providers. It’s a mind shift happening in enterprises globally—where they once had a small number of clouds, now their cloud operations are huge, growing and boundless. Companies are also discovering that the cloud is not just an easier, more cost-effective way to run their applications, it unlocks new opportunities.

    Now there are core clouds, edge clouds for hyper-local applications, regional clouds, clouds for high availability and resilience and more. Edge computing is another option, where low latency is required for operations at the customer-facing frontend cloud while backend processing happens in the primary cloud. But this is just the beginning.

    Continuous Delivery is Now Way Too Complicated

    Today, an application may have dozens of microservices distributed across different clouds that need to work together—perhaps some in cloud one, a few in cloud two, others in cloud 40, etc. The scale gets huge very quickly; for example, if 100 microservices are being delivered to 100 clouds, there are 10,000 mutations that have to be configured and managed. 

    This is the new normal, and DevOps needs to adapt to it. Processes should mesh transparently, but connecting microservices across multiple clouds and cloud instances requires inter-cluster communication, which Kubernetes (and GitOps/ArgoCD on top of it) does not natively support.

    To make all this work requires specialized skill sets, so organizations hire teams with expertise in continuous delivery, multi-cloud, networking, security and automation. The first step involves distributing K8s containers to clouds where the microservices are going to run. Some enterprises create their own distribution system, others choose to download, install, and manage third-party software such as open source ArgoCD.

    The second step is more complex: Securely connecting those microservices across different clouds and K8s clusters. This involves integrating complex service meshes, load balancers, API gateways and network/firewall automation tools, all feeding into a centralized console for configuration and monitoring.

    The result is inevitable: Lots of extra costs, inefficiency, potential security risk and delayed time to market with resulting risks to the business. Development teams update microservices daily but depend on CloudOps, NetOps, SecOps and other flavors of Ops to deliver them to the different clouds and clusters where they need to run. 

    Despite the best efforts of these different stakeholders, it can take days or weeks to update cloud networks and security for each change.

    Simplifying Multi-Cloud Operations With an Overlay Network

    When hundreds of microservices are being distributed across more and more clouds and updated constantly, you need an alternative—one that streamlines current operations without sacrificing security or application performance. Let’s set aside traditional methods and think about how it should be done.

    First, the solution should be easy to use, so DevOps people don’t have to be proficient with the underlying technology or be dependent on NetOps, SecOps and/or CloudOps people who are. Instead, just provide some basic information about the Git repository and the clouds where you want the microservices to run, and an overlay network handles the rest.

    It should be comprehensive—integrating ArgoCD, the service mesh, the K8s ingress gateway, zero-trust security, resilience/failover, load balancing and multi-cloud networking — all those elements that normally require assembling and configuring individual tools.

    It should make multi-cloud Kubernetes application operations easy to manage, with a single dashboard where you can securely deploy, connect and monitor microservices in all your clouds and clusters.

    Finally, the solution should be available as a service, rather than having to install an ArgoCD server and try to manage it yourself (or hire a team to support it). And if you have questions or need help, competent people should be available to give you a hand.

    Disruptive – In a Good Way

    Get ready for self-service multi-cloud Kubernetes decoupled from the underlying networking and security details. It’s an approach that’s about to upend how microservices are deployed and managed, so DevOps can get back to what really matters:  Delivering applications as fast as possible, on the resources where they need to run. The ability to deliver new features in a fraction of the previous times while significantly reducing costs and without compromising security will mean a competitive advantage and a stronger bottom line. 

  • Introduction to Cloud Custodian

    Introduction to Cloud Custodian

    Organizations continue to increase their footprint in the cloud. Yet, applying governance and enforcing policies across multiple cloud environments at scale is a challenging endeavor. Organizations typically have governance policies written in English, but translating them into enforceable code has historically required some custom workarounds. In the same vein as infrastructure-as-code (IaC), DevOps engineers now seek a similar GitOps approach to implement shared policies across cloud-based workloads.

    Cloud Custodian is one such toolset that can manage and enforce cloud policies in a standardized format. Using Cloud Custodian, a Cloud Center of Excellence has the building blocks to create policies for security governance, development guardrails and cloud cost optimizations. The free, open source project, which has been steadily evolving for years, recently gained its incubation status with the Cloud Native Computing Foundation (CNCF) and to date boasts over 350 contributors on GitHub.

    I met with Kapil Thangavelu, Cloud Custodian creator and maintainer and CTO at Stacklet, to learn more about Cloud Custodian and what features we should anticipate from the project in the near future. Below, we’ll provide a comprehensive introduction to Cloud Custodian, exploring its history, how to use it and its core benefits. We’ll also analyze a few sample policies to showcase how Cloud Custodian functions in practice.

    What is Cloud Custodian?

    Cloud Custodian got its start as an internal tool developed within Capitol One toward the end of 2015, explains Thangavelu. At the time, engineers were grappling with the newfound realities of managing the cloud at scale and realized that having one-off ad-hoc policies across teams was causing friction. “It’s really hard to manage and enforce policies at scale,” says Thangavelu. So, engineers toyed with creating a more GitOps approach to policies around governance and security that could be run as an internal SaaS solution.

    Thus, Cloud Custodian was born. The YAML DSL tool allows you to easily define rules to manage cloud infrastructure. It can offer real-time enforcement and produce event-based responses. For example, you can create policies that require tags on resources or one that turns off instances during off-hours. Or, a policy could prevent a developer without the proper privileges from accidentally making an open load balancer. Cloud Custodian supports AWS, Azure, and GCP and policies are specified to a resource type, whether it’s EC2, ASG, Redshift, CosmosDB or a PubSub Topic.

    Thangavelu describes Cloud Custodian as a bunch of Lego bricks that developers can pick up to build guardrails in arbitrary ways. Instead of shipping with canned rulesets, “Cloud Custodian makes customization itself a first-class citizen,” he says. Capital One open sourced the project and contributed Cloud Custodian to CNCF in August 2020.

    Example Policies

    Cloud Custodian comes with a library of actions and filters. Let’s take a look at a few example policies across the three main cloud providers. But first, to install Cloud Custodian from PyPI, you can initiate the following command:

    $ python3 -m venv custodian
    $ source custodian/bin/activate
    (custodian) $ pip install c7n
    

    Let’s consider an example policy that would improve security hygiene on AWS. Below is one such policy that creates a CloudWatch Event to be triggered anytime a user logs in from an invalid IP address. This could be used to ping a security administrator to investigate. With this rule, it’s also possible to turn on an auto-remediation function.

    policies:
    
      - name: invalid-ip-address-login-detected
        resource: account
        description: |
          Notifies on invalid external IP console logins
        mode:
           type: cloudtrail
           events:
              - ConsoleLogin
        filters:
          - not:
              - type: event
                key: 'detail.sourceIPAddress'
                value: |
                   '^((158\.103\.|142\.179\.|187\.39\.)([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])
                   \.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]))|(12\.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])
                   \.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]))$'
                op: regex
        actions:
          - type: notify
            template: default.html
            priority_header: 1
            subject: "Login From Invalid IP Detected - [custodian {{ account }} - {{ region }}]"
            violation_desc: "A User Has Logged In Externally From A Invalid IP Address Outside The Company's Range:"
            action_desc: |
                "Please investigate and revoke the invalid session along
                with any other restrictive actions if appropriate"
            to:
              - CloudAdmins@Company.com
              - SecurityTeam@Company.com
            transport:
              type: sqs
              queue: https://sqs.us-east-1.amazonaws.com/12345678900/cloud-custodian-mailer
              region: us-east-1
    

    Next, let’s consider a policy that would add some degree of governance for developers working on Azure. One simple yet popular policy involves tagging the ownership details to individual resources. This policy, therefore, will tag all resource groups with the creator’s email address:

    policies:
      - name: azure-auto-tag-creator-resource-groups
        resource: azure.resourcegroup
        description: |
          Tag all existing resource groups with the 'CreatorEmail' tag; looking up to 10 days prior.
        actions:
         - type: auto-tag-user
           tag: CreatorEmail
           days: 10
    

    Finally, let’s consider a policy that could aid in cost optimization on GCP. Below is a sample policy to enforce minimal CPU utilization for autoscalers on GCP. Implementing such a policy could help avoid underutilization to combat rising cloud costs.

    vars:
      min-utilization-target: &min-utilization-target 0.8
    policies:
      - name: gcp-autoscalers-enforced
        resource: gcp.autoscaler
        mode:
          type: gcp-audit
          methods:
            - v1.compute.autoscalers.insert
        filters:
          - type: value
            key: autoscalingPolicy.cpuUtilization.utilizationTarget
            op: less-than
            value: *min-utilization-target
        actions:
          - type: set
            cpuUtilization:
              utilizationTarget: 0.8
    

    Benefits of Cloud Custodian

    By automating a lot of the tedious policy management away, Cloud Custodian could reduce risk and accidents through more streamlined cloud governance. “It solves the natural problems when infrastructure is in everyone’s head,” says Thangavelu. By aggregating ad-hoc scripts and unifying policies across an organization, you could immediately instigate new rules without manually reminding all members of an organization, which could take years.

    For those familiar with Open Policy Agent (OPA), you may notice some overlap in the objectives, as both are engines for enacting cloud-native policies. Compared to OPA, Cloud Custodian has some developer experience perks. For one, you don’t have to use Rego, as the policies are written in YAML, which is a familiar configuration language for DevOps engineers. Cloud Custodian uses abstractions on event runtimes for each cloud provider. Furthermore, compared to OPA, you don’t need to bind the engine for a particular problem domain, says Thangavelu, as Cloud Custodian is specifically bounded to cloud governance and management.

    Cloud Custodian is also battle-tested. Many big names are using it in production, including Capital One, HBO Max, Intuit Inc, JP Morgan Chase & Co, Siemens and Zapier. Across its adoption, the tool tends to either be utilized by a Center of Cloud Excellence, security teams to conduct reporting or reveal real-time incidents or the CFO to direct cost optimizations.

    Future of Cloud Custodian

    Cloud Custodian maintainers describe the project as a consistent firehouse. Since the project tracks changes in all cloud provider resources in real-time, it’s quite a dynamic toolset. In addition to monthly updates, users can expect many additional updates on the horizon, including support for Tencent Cloud as well as additional Kubernetes support. Additional work is being done around shift-left capabilities to meet the developer where they are, says Thangavelu.

    For more information, check out the Quickstart Guide to Cloud Custodian, or view the project roadmap here.

  • From Cloud Chaos to Cloud Smart With Multi-Cloud Services

    From Cloud Chaos to Cloud Smart With Multi-Cloud Services

    Organizations that embrace multi-cloud services experience real results and a heap of advantages—including greater resiliency, agility and data sovereignty. This is why it’s no surprise the majority of enterprises today are using two or more public clouds, with 81% reporting in a recent survey that they plan to adopt a multi-cloud strategy by 2024.

    But despite the benefits, it’s also been proven that multi-cloud can be complicated and even overwhelming. It requires an entirely new approach to optimize workloads, simplify development and tackle a growing pattern of operational complexities. This has been described as cloud chaos, where greater cloud choice has led to a massive spike in complexity. Most report that building new apps is slow and cumbersome, and managing their entire app portfolio across disparate clouds is difficult and expensive. No wonder, when each cloud requires its teams to use proprietary tools that are siloed and incompatible with one another. Meanwhile, for the average employee, getting fast, secure access to critical apps from anywhere is imperative, yet it’s often a challenge. All this complexity has broad repercussions on the business, from managing costs to attracting and retaining top talent.

    Tackling this multi-cloud complexity needs to start with creating a layer of abstraction that spans various, diverse cloud environments and doesn’t hinder access to each cloud provider’s unique services. However, organizations must take it a step further to solve the challenge of how best to build, manage, govern and optimize apps and workloads across a multi-cloud environment.

    Multi-Cloud Services

    Multi-cloud services—a fast-emerging category of IT services—are the key to helping organizations implement a multi-cloud strategy that simplifies and streamlines development, operations, networking and security across clouds. A multi-cloud service provides a consistent API, object model, identity management and other core functions across clouds. And, it has one or more of the following characteristics:

    1. Runs on a single cloud but supports interactions with at least two different clouds
    2. Runs on multiple clouds and supports interactions with at least two different clouds
    3. Runs on any cloud or edge, even in disconnected mode, and basic operations are fully automated

    Multi-cloud services can be used to standardize cloud infrastructure and operations into one platform to reduce the complexity of individually building or consuming the equivalent native services from multiple clouds. In this model, public clouds, data centers, private clouds and edge locations are all verticals, and multi-cloud services are horizontals that provide functionality across these environments.

    Let’s take a closer look at the five most common categories of multi-cloud services and when to use them.

    1. Application Services

    Application services allow teams to use core services in a standardized manner across clouds. These core services include observability, replication, backup, and restoration. By implementing application services, enterprises can increase their speed of innovation and make their technologies easier to use. Examples of application services include developer tooling, databases, modular development platforms, artificial intelligence, machine learning and serverless and CI/CD capabilities.

    2. Infrastructure Services

    If your organization chooses to run its applications as VMs, containers, or both, using infrastructure services is the right move to standardize management and operations across the clouds. Different types of multi-cloud infrastructure services include the ability to manage and observe compute, storage and network services leveraging VMs or containers, infrastructure automation and Kubernetes management solutions. When applied, infrastructure services can improve resiliency, security, performance, interoperability and portability.

    3. Security Services

    When using multiple clouds, an issue enterprises run into is that each individual cloud has its own security tools and approaches, making it difficult to ensure your enterprise is protected against cyber threats. That’s where multi-cloud security services come in – centralizing security operations and secure software supply chains. Some examples of multi-cloud security services are network detection and response, endpoint detection and response, next-gen antivirus and secure access service edge. These services enable organizations to achieve cohesive visibility, context and control by providing a single interface.

    4. End-User Services: Access to Data and Services

    No matter how big your enterprise is, or how many applications you use, it’s necessary to provide the right level of access to applications and data. But this can prove difficult when you have a multi-cloud infrastructure. Multi-cloud end-user services, which consist of virtual desktops, device management and end-user application delivery, will provide your organization a uniform way for all employees to have quick, secure access to your applications, all while simplifying device management.

    5. Data Plane

    In the past, workloads were restricted to a single data plane contained within a single public or private cloud or edge location. Now with the rise of multi-cloud services, enterprises can run workloads in the multi-cloud data plane. A prime example of workloads running in the multi-cloud data plane is a distributed application that runs in multiple cloud provider environments. Part of the application might run in the private cloud and the other services are deployed in a public cloud. The multi-cloud data plane is where the containers, services and data exist and where user interaction occurs.

    From Cloud Chaos to Cloud Smart

    The desired destination of every multi-cloud journey should be to move from a position of cloud chaos to one of cloud smart. Being cloud smart means taking an architected and planned approach to multi-cloud and digital transformation. As more enterprises adopt multiple clouds, multi-cloud services will be key to becoming cloud smart by helping to reduce complexity and risk and proving the freedom to select the right cloud for all situations based on technical and business requirements.

  • Aligning Cloud Spend Management With Cloud Transformation

    Aligning Cloud Spend Management With Cloud Transformation

    The cloud transformation movement is well underway, with more than half of enterprise organizations moving to a cloud-native approach this year, according to Forrester Research. Spending on cloud infrastructure is rising accordingly – more than $21 billion in Q4 2021, up 13.5% from Q4 2020, according to IDC. The cloud offers economies of scale and connectivity that companies can leverage to optimize operations, make better use of their data and identify opportunities. However, if a company’s cloud infrastructure investment isn’t well planned, they can end up spending more than expected due to unplanned access costs, applications consuming more resources than expected and underperformance caused by inefficient architecture or lack of maintenance.

    Spending governance–creating and managing a budget that supports the company’s cloud goals–also helps to maintain cloud security by ensuring that there are adequate solutions in place to prevent phishing, ransomware and other attacks that can disrupt or disable an organization’s cloud operations. Financial monitoring allows organizations to accurately evaluate the cost-efficiency of the apps in their cloud ecosystem. This can help control costs and avoid situations where different groups add their own apps without first leveraging what’s already available or correctly gauging associated cloud spend. Unchecked app proliferation in the cloud can create a cycle that includes overconsumption of resources and security issues. 

    Cloud governance can address sustainability concerns, too, as executives increasingly focus on reducing their organizations’ carbon footprint. It’s important to benchmark the organization’s on-premises servers’ carbon impact, so you can quantify how moving workloads from on-premises to the cloud impacts sustainability progress. As with spending, cloud sustainability measurement requires adequate planning, execution, organization-wide visibility, effective monitoring, and efficient use of cloud resources. 

    Planning for Effective Cloud Spend Governance

    Spending management processes have always been crucial for business, but governance of cloud initiatives is playing catch-up to technology advances and an accelerated digital transformation. We see many organizations that are relying more heavily on cloud infrastructure because of the speed it offers to deliver new products and experiences through innovation. But without financial controls, there can be an element of inefficiency that affects cloud spending decisions—something that we’ve seen as an increasing issue for companies over the past decade. 

    Whether an organization is preparing for the transition to the cloud or seeking to make existing cloud spending more visible and accountable, the financial governance aspect requires readiness. Assessing this readiness starts with cataloging the tools and expertise available in the organization to build a cloud budget, put monitoring tools in place, setting threshold levels that trigger notifications when spending exceeds certain levels and providing organizational controls to remedy any spending excesses. 

    It’s also helpful to define the goals and potential benefits of implementing better spending controls. First, no one wants to deal with unplanned costs that create budgetary problems and have a negative impact on the business. Second, spending accountability allows you to identify the internal groups that are knowledgeable enough about both cloud operations and spending management to take ownership of their role in the move to the cloud. At the same time, you can also identify the groups that need more training, guidance, and resources to get the most value and beset employee experience from their cloud transformation. Third, proper cloud governance can help companies avoid scenarios where cloud-related issues such as security, budget or over-proliferation of apps in the cloud ecosystem lead to customer experience problems. 

    All these planning requirements are more complex for organizations with an existing or planned multi-cloud environment. Because each cloud provider has its own processes and features, the organization will need to understand–and financially manage–a diverse set of tools and resources to analyze what happens across their cloud network. For example, it’s relatively simple to pull two similar reports from a single-cloud environment and synthesize them to create a summary report. When the reports are coming from two different cloud platforms, there can be format differences that make synthesis more challenging, time-consuming and costly to aggregate that data and present it in a dashboard for leaders. 

    Platform differences also mean that simply comparing previous on-premises spending to proposed cloud spending may not be a good model for accurate cost planning for multi-cloud environments. For all of these reasons as well as technical ones, multi-cloud governance often requires creating a team or task force to collaborate and share knowledge for effective technology and budgetary decision-making. 

    Cloud Spend Governance in Practice

    Like cloud technology and applications, cloud spend governance is a continually evolving practice, not a one-and-done task. That’s because proper financial visibility and management require monitoring to identify any emerging issues in terms of capacity, cost and security. For example, a manufacturer might analyze their cloud usage data and find they’re underutilizing some resources, which enables them to turn those resources off to save costs. 

    Financial governance also allows companies to find opportunities for optimization–something that can be as simple as identifying potential configuration changes that make cloud operations more efficient and secure. In the end, the promise and potential of the cloud for companies depend on smart, properly planned use of cloud resources and spending governance is a critical part of that smart planning. 

  • DevOps and Hybrid Cloud: Life in the Fast Lane, Part Two

    DevOps and Hybrid Cloud: Life in the Fast Lane, Part Two

    In the early years of cloud computing, cost savings were the major driver of adoption. These days, however, organizations are increasingly faced with spiraling expenditures, waste and a lack of control. As cloud usage bills and inefficiencies start to balloon, these challenges are beginning to undermine the benefits of migrating in the first place.

    The truth is that optimizing costs in the cloud is more taxing than many organizations first expect. Identifying cost savings that can be made isn’t generally the hard part; effectively implementing those savings is where the real challenge lies.

    A lack of control over infrastructure means that many organizations are failing to make the changes needed to truly realize these gains. So common are these challenges that there is even a word for the process to deal with them: FinOps. FinOps, at its core, is the culture and practice of creating visibility and accountability to manage cloud penetration throughout an organization, and it’s an area that is growing rapidly.

    This is the second article in my series that looks at what needs to change so that organizations can really start embracing the opportunities provided by hybrid cloud and DevOps. In this installment, I’m going to take a look at the areas of FinOps, cloud waste and automation. In doing so, I hope to show that there is indeed life in the hybrid cloud and DevOps fast lane if handled the right way.

    Get Ready for FinOps

    If you think hybrid cloud and the topics of FinOps and, more specifically, cloud waste, haven’t come up during discussions, you’ve probably been living under a rock.

    It naturally follows that the more agile an organization becomes the harder it needs to work to keep track of waste. Exponential growth is great, but without the right controls a cloud budget will disappear before there has been a chance to see any returns; there are even examples of companies migrating and then deciding to roll back—such are the concerns around lack of control and rising costs.

    Based on survey responses from over 750 cloud decision-makers, Flexera found earlier this year in its 2022 State of the Cloud Report that organizations continue to waste significant amounts of money in the cloud. A full 66% of respondents said that cloud usage is “higher than initially planned this year”, and they estimated that they are wasting 32% of their overall cloud spend. A good five years into full cloud migration and most organizations still haven’t got a handle on costs.

    The tricky part is that waste can rear its head at many stages over the course of a project, which is why it’s so important to maintain control from day one.

    Establishing a baseline of an environment that is deemed to be the known state means that what is versioned can become a source of trust and the desired state of an organization’s cloud infrastructure. How is this possible? Simple: By creating a culture and practice of visibility and accountability throughout an organization. 

    How do you do that? Yes, you guessed it: FinOps.

    Tackling Cloud Waste Head-On

    The ideal time and place to start establishing robust FinOps policies and reducing waste come when the move has been made to start embracing a dual DevOps/hybrid cloud approach. The good news is that the principles of FinOps are easy to follow and can be applied at various stages of an application management life cycle and DevOps and hybrid cloud journey.

    First, teams need to estimate financial and environmental costs ahead of deployment, something which can be particularly challenging when infrastructure-as-code (IaC) tools such as Terraform, Ansible or Puppet are being used, but which is essential to successful FinOps. Once a team has decided which cloud provider they will be using, how much they plan to spend and, more generally, what criteria will be governing these decisions, effective tag management comes in.

    Tagging is the basis for achieving a structured cloud infrastructure, especially in multi-cloud environments that feature different resources being used for different purposes. Tagging means that users can add descriptive metadata (tags) to cloud infrastructure to identify key resources or values such as staging, development or production.

    In a rapidly growing cloud environment, consistent and comprehensive tag management helps to keep track of what is happening in terms of cost, usage, availability, performance and security across a constantly transforming cloud infrastructure. Once a project has been deployed, these tags need to be managed and maintained across all cloud providers, something which is critical for the management of waste, but is often a huge and messy task.

    Good tags help drive good decision-making and the more options there are for categorizing data, the better. To truly get a handle on tag management, finding a platform that can enable users to visualize and study multi-cloud costs in a central place makes it possible to establish that all-important baseline and start to reverse engineer invoices, optimize monthly costs and tackle waste head-on.

    One Cloud, One Strategy

    There was a time a few years ago that we used to hear people say this a lot: “I’ll migrate all my assets to a single cloud provider.” Cloud providers were pushing migration to a one-cloud strategy; considered completely normal at the time, but which has since been shown to be flawed, especially in the world of enterprise.

    Segregation of responsibility is perhaps the best example of why—there are simply too many responsibilities that keep a modern business afloat to risk putting all your eggs in one (cloud) basket. Consider on-premises legacy apps, sensitive data, critical workloads, the production life cycle, ongoing applications without too many peaks and even backend apps. Then consider the cloud providers, new cloud-first applications, public data, non-critical workloads, the development life cycle and frontend applications dealing with high traffic.

    Now imagine all of that suddenly disappears.

    Hybrid cloud means eggs in multiple baskets. Yes, it adds a layer of complexity, but when so much is at stake, it’s worth it. And when you have defined where you want to host everything for each application, it becomes much easier to gain clarity. The challenge is that all cloud providers have their own ecosystem, which will either be private or public.

    These ecosystems make it possible for everything to be integrated, but what is often not immediately obvious is that even though they are integrated, they are not always aligned. It’s in the interests of the cloud provider to provide the best tools to use their platform but not necessarily the best user or developer experience which is something that requires specialist expertise. That usually leads to a certain degree of lock-in as you generally cannot use their tools for managing other applications that aren’t part of the infrastructure.

    This lack of transparency and visibility into other cloud providers can get in the way and impact the ability to get the most out of a dual DevOps and hybrid cloud strategy. However, by adopting a hybrid cloud approach, teams can choose the best cloud provider for each application, putting the team in the best position possible to provide the best services possible.

    And finally, Always Consider the DevX Factor

    For DevOps to thrive, it is important for companies to stay independent both for their own sovereignty and for creating the best developer experience, or DevX (a topic I have explored in a previous article for devopsy.kinsta.cloud).

    It’s easy to fall into the trap of using all the automation capabilities available from each cloud provider, but that locks an organization into a situation where it needs deep expertise across a wide variety of technologies. Adopting a one-cloud, one-automation strategy means that it would never be possible to migrate automation or reuse it in different application deployment processes across various clouds.

    This is where automation of configuration management, IaC, CI/CD pipelines and the DevOps and hybrid cloud platform has a significant role to play. Automation on an organization’s own terms is arguably the most critical element in the race to reduce time to market and improve quality where concepts such as shift left are adding complexity and increasing the responsibilities piled on top of developers.

    Using automation technologies to maintain autonomy and favor cross-subject expertise and team mobility gives organizations the freedom and flexibility to save time, money and roll out better DevX. Ultimately, it also helps to create the best possible environment for organizations to truly start enjoying a DevOps and hybrid cloud life in the fast lane.

  • How to Go Multi-Cloud: A Simple Three-Step Approach

    How to Go Multi-Cloud: A Simple Three-Step Approach

    Odds are your business already uses cloud technology for automation, cybersecurity, IT infrastructure updates and other purposes. But you don’t have to stick to a single cloud server or provider. In fact, you can take advantage of multi-cloud strategies for your organization and reap the benefits for years to come.

    That said, multi-cloud adoption and optimization can be tricky, especially if you don’t have a plan in mind from the get-go. Today, let’s break down a simplistic yet effective three-step approach to go multi-cloud without running into major problems.

    Step One: Map Your Cloud Zoning Policy

    Your first major step should be to map out your cloud zoning policy and plan. In a nutshell, the cloud zoning choices you make can impact your commitments, costs, and even the eventual functionality of the multi-cloud setup.

    By mapping out your clouds, you also map out which processes and applications will run on each individual cloud server or provider. In essence, you decide what gets locked into one cloud, what data has to be ported between clouds and what applications must run on multiple clouds simultaneously.

    Need an example? A cloud zoning policy might cover whether you keep your web surfing or data analytics on separate cloud providers or on the same cloud servers. 

    You should map your cloud zoning policy regardless of whether you do the setup or hire a service. In the latter case, offering a read-to-go zoning map will make the service’s job easier and minimize the possibility of mistakes and/or hiccups.

    How to Determine Optimal Cloud Zoning

    Naturally, figuring out how to optimize cloud zoning can be difficult. The best way to do this is to determine your special focus areas. Alternatively, consider how you want your multi-cloud strategy to best benefit your organization.

    Say that you want to guarantee 100% uptime for your customers or visitors, even if your service goes down or if you experience a data breach. In this case, you can set up your cloud zoning strategy to balance the data load across multiple clouds at the same time.

    Or say that you want to make sure your users have global availability 24/7/365. In that case, you can set your cloud zoning policies to ensure that users can access your data or websites from anywhere around the globe at any point.

    Essentially, figure out what matters most to your organization–and what you want the most from multi-cloud optimization–and zone your cloud applications and policies accordingly.

    Step Two: Architect the Multi-Cloud Environment

    The next major step is to architect your multi-cloud environment. This involves looking at the high-level design of the environment and creating a rock-solid foundation for multi-cloud servers.

    At this stage, you should have at least some idea of how your business will grow and how the multi-cloud environment will assist with its scalability and resource needs. You need to know:

    • Where your data science and machine learning applications need to be
    • Where your product application serves from
    • Where your data warehousing takes place
    • Where cloud security is run from
    • How each of those functions grows alongside the others

    In the architecture phase of a multi-cloud setup, you need to figure out which projects and apps are so-called “cloud agnostic.” Cloud agnostic projects and applications don’t have to be portable; because of this, they can lean on managed services or proprietary IT infrastructure from your organization.

    How to Set Up an Ideal Multi-Cloud Environment

    To reap the most benefits out of a multi-cloud environment, you should adopt a containerized and flexible approach. Not only is this cost advantageous, it also allows you to set up your multi-cloud environment with as much versatility as possible.

    If you architect or plan your multi-cloud environment so it is containerized and flexible, you can work with practically any infrastructure-as-a-service (IaaS) provider. Therefore, you can transition to different cloud hosts or service providers whenever necessary according to your budget or other factors.

    To do this, be sure to perform heavy forecasting. You need to know how much data storage your computing will require, the database utilization your organization will need, the number of computer nodes you’ll likely require and so on.

    As a side bonus, containerization in your multi-cloud setup means that if one server or process goes down, the others are less likely to fail from a cascade effect as well.

    Step Three: Prep for Contracts and Forecast Costs

    The last step in going multi-cloud for your organization is handling the financial aspect of the process. You need to prepare for contracts and commitments alongside forecasting costs.

    Forecasting is critical in this phase because you’ll prepare for contracts and select different cloud services. Because of this, you need to understand how flexible your budget is relative to your infrastructure requirements.

    Specifically, you’ll need to match the costs to every multi-cloud forecast and build your overall resource and money consumption budget. Basically, you need to know:

    • How much you’ll likely spend on multi-cloud processing and services
    • Whether you need certain features, such as website monitoring tools like Visualping
    • Whether your budget can take that forecasted strain

    If the answer to the third question is “no,” you may need to go with a more affordable service or adjust your multi-cloud environment architecture and zoning policies. By forecasting costs ahead of time, you won’t run into a disaster scenario where you already have your multi-caught environment up and running but can’t pay for it, forcing you to scramble as a result.

    Minimize Commitment Risk

    Luckily, there are ways to minimize commitment risk and avoid budgetary disasters. For example, you can use commitment buy-back guarantees, or you can use flexible commitment options like that from AWS. These include computing savings plans, which consume cloud resources in any region and which result in very low savings rates.

    Of course, you can and should also practice very careful budgeting and accounting. Once you ensure that your commitment costs and savings are attributed to the right services, server resources, applications, etc., you’ll have a better idea of how much money and other resources you really need and avoid over-committing to a provider that is too expensive.

    Then you can further avoid commitment risk when planning your migrations of applications between different vendors carefully. Budgetary costs can skyrocket if migrating applications and data between vendors take longer or result in unexpected complications. Therefore, you should make sure that your migrations go quickly and easily or that a cloud service provider offers assistance during this phase (possibly as part of a deal to get you to sign with them in the first place).

    Wrapping Up

    As you can see, you can transition your organization to multi-cloud in a matter of months. But even if you follow the above steps perfectly, remember that you won’t optimize your commitments, performance and costs up to 100%. Still, you can prep your organization for long-term success and multi-cloud benefits with the right preparation and planning.

    With the right cloud services provider, you’ll gain additional assistance and support throughout this process and be able to take advantage of the extra resources from a multi-cloud setup quickly and easily. 

  • 90% Of Orgs Say Multi-Cloud Helps Achieve Business Goals

    90% Of Orgs Say Multi-Cloud Helps Achieve Business Goals

    Multi-cloud is the new normal. And thankfully, this new normal isn’t just happenstance—it’s driving positive outcomes.

    New findings show that most organizations benefit from using multiple cloud providers. Multi-cloud adoptions are helping achieve business goals, such as improving reliability and scalability and increasing overall security and governance. However, nearly all organizations (94%) admitted that they have some avoidable cloud spending and skills shortages continue to hold back a fully-realized multiple-cloud success.

    HaschiCorp recently released the 2022 State of Cloud Strategy Survey: Making Multi-Cloud Work. In addition to showcasing the positive outcomes of multi-cloud adoption, the report found a trend toward automation frameworks that help operationalize multi-cloud. Below, I’ll explore the report’s key takeaways to see what CloudOps and platform teams can garner from current multi-cloud trends.

    Multi-Cloud is Achieving Business Goals

    First off, the use of the public clouds is increasing dramatically—the majority of public cloud workloads will likely double in the next two years. To support this influx, more organizations are moving toward multi-cloud. According to the HashiCorp survey, 60% are already multi-cloud and 21% plan to use multiple clouds within the next year.

    The good news is that a multi-cloud strategy appears to be working. A full 90% of respondents said multi-cloud is helping their organizations achieve their business goals. This figure is an impressive jump from HashiCorp’s 2021 survey, in which only 53% of organizations said multi-cloud was helping them achieve their business goals.

    So, what exactly are companies extracting from multi-cloud adoption? Well, the topmost business goal driving multi-cloud is reliability, at 46%. This is followed by digital transformation (43%), scalability (42%), security and governance (41%) and cost reduction (39%). As we can see, multi-cloud equally benefits various areas.

    Centralized Automation Supports Multi-Cloud

    With the rise of multi-cloud, CloudOps is becoming its own discipline. As such, it’s common for an organization to build a dedicated Cloud Center of Excellence (CCoE) or strategy team to manage cloud operations—86% said they relied on a cloud platform team. Such a team is often in charge of standardizing cloud services, developing cloud best practices, creating operational policies and related duties.

    To aid cloud platform teams, cloud automation is becoming increasingly important. The survey found that 99% see automation as important for operationalizing multi-cloud infrastructure. Multi-cloud automation could help solve inconsistencies across varying cloud workflows. Respondents also found it can be applied to deliver more flexible infrastructure, improve security and governance and better utilize cloud resources. Improving security is especially important here, as 89% said security is a key driver of cloud success.

    So how are these automations built? Well, folks are rarely developing cloud automation tools from scratch—only 27% do so. It’s far more common to either use open source or commercial tools for cloud automation. It’s pretty equal across the board whether these tools are run ‘as-a-service’ or are self-hosted.

    Regardless of the tooling type, companies are experiencing a broad set of benefits from using middleware to manage their multi-cloud operation strategy. 49% rank scalability as a benefit. This is followed by infrastructure provisioning (42%), cost optimizations (40%) and more flexible deployment options (39%).

    (Nearly) Everyone is Overspending on Multi-Cloud

    Unsurprisingly to some, the study found that 94% of organizations are wasting money in the cloud. The following were the top cited areas that contribute to cloud overspending and waste: Idle or underused resources (66%), overprovisioning resources (59%), a lack of needed skills (47%) and manual containerization (37%).

    The cloud overspending dilemma necessitates forethought into optimizations and reduction of idle resources. As I’ve previously covered, some organizations are even tinkering with employing a cloud economist, or Cloud CFO, to keep escalating cloud fees in check. To help this mission, 43% say consistent and automated tooling has or would lead to better utilization of cloud resources.

    Although wasteful spending is pervasive, the majority of companies are forecasting their cloud spending correctly. More than half (57%) said that in 2021 their organization’s projected cloud spend aligned with their actual cloud spend.

    Getting the Most Out of Multi-Cloud

    Multi-cloud is becoming more common across all IT divisions—as is middleware to operationalize and standardize logic between multiple clouds. And, widespread business success with multi-cloud signals increased maturity in this area.

    Yet, multi-cloud doesn’t come without its challenges. Skill shortages rank as the highest factor impeding an organization’s ability to operationalize multi-cloud. Businesses must face other challenges, such as siloed teams, compliance and risk management and lack of training in order to fully realize multi-cloud. Standardized operating models, along with shared workflows and policies, are possible ways to combat these roadblocks.

    The HashiCorp study surveyed 1,000 technology practitioners and decision-makers from around the world. HashiCorp also partnered with Forrester to provide additional analysis of the findings. To read the results for yourself, check out the full report here.

  • Overcoming Multi-Cloud Management Challenges

    Overcoming Multi-Cloud Management Challenges

    We’ve long talked about how the cloud is the future. But with the vast majority of corporate data now stored in the cloud, it’s clear that most businesses now realize this is a must-have in today’s increasingly demanding and agile business environment. 

    The cloud has been the backbone of the remote restructuring of the workplace over the last few years, enabling organizations to access data flows and critical workloads no matter where their employees are stationed. So much so that there’s been a dramatic rise in the number of enterprises deploying different service providers as part of a multi-cloud strategy. This enabled them to pursue greater agility and flexibility within a hybrid environment. 

    Recent research from Wanclouds found that most IT professionals use two or more cloud platforms today—and just under half (48%) said they used a mix of public and private clouds. However, the reality is that the more cloud environments your organization use, the more complex it becomes to both manage and secure them. Here are three multi-cloud management challenges impacting IT teams today and how they can overcome them.

    Maintaining Uptime in the Face of Rising Security Challenges

    Avoiding downtime has never been more important, nor has it been more challenging to achieve. Extreme weather events are becoming more frequent and increasing the risk of natural disasters or power outages, leading to data loss. In fact, 65% of U.S. and UK IT decision-makers said their organization experienced at least one data loss incident last year, while 21% admit they experienced two data loss incidents.

    But it is, perhaps, the security challenges that pose the biggest threat to IT departments and the developer teams they support. Since the onset of COVID-19, organizations have been targeted for cyberattacks far more often and have been infiltrated by cybercriminals much more quickly. According to McAfee, there were 3.1 million cloud-based cyberattacks in 2020 alone. Unsurprisingly, these attacks are fueling concern in IT circles. 88% of U.S. and UK decision-makers said they’re at least slightly worried—and 15% are apprehensive—about cloud workload security in 2022. 

    While multi-cloud environments enable developer flexibility, they also cause inherent configuration and visibility problems, and this is where cyberattackers can take advantage of weaknesses. The complexity of migrating data across different cloud platforms and operating systems can also lead to delays with patching. The key is often ensuring visibility across these platforms and maintaining interoperability. Security platforms for multi-cloud environments must be set up to share threat information across providers and platforms. If not, threats can easily be missed, or even if they are detected, the response across infrastructure will be too slow to minimize damage. 

    With businesses accelerating their goal of becoming 100% cloud-native in the next few years, a cloud-based disaster recovery strategy must also be embedded within their management plans. Without one, every business risks losing vital data and having their systems, operations or services shut down by natural and man-made disasters, security risks, hardware failures and power outages.

    Staying on Top of Hidden Charges

    Cloud spending has skyrocketed in the past two years, and all signs suggest that organizations will continue to allocate more of their IT budgets to the cloud over the years to come. But not every business has the same resources as, say, Apple, which reportedly spent over $30 million a month on Amazon’s cloud, according to a 2019 CNBC story. The reality for most IT teams is that they’re constantly battling hidden charges and unexpected cloud costs that threaten to blow up their entire IT budget. 

    In fact, in Flexera’s 2022 State of the Cloud report, respondents self-estimated that their organizations wasted just under a third (32%) of their cloud spend, up from 30% last year. Meanwhile, Wanclouds research found that 54% of British and American IT professionals say they have been hit with unexpected cloud costs in the past year.

    It’s a severe problem throwing IT teams for a loop from the migration stages of the multi-cloud plans right through to management and maintenance. Sure, cloud providers like Amazon provide basic tools for resource tracking and spend visibility. But truthfully, these features generally fall short of providing real-time and enterprise-wide insights on how to optimize costs.

    To eliminate the sticker shock of unanticipated cloud costs, organizations need to have a defined plan for cloud cost management. Again, company-wide visibility into their cloud platforms’ billing systems is imperative and a way to track spending across their multiple accounts. It’s vital for companies to properly tag the infrastructure for understanding costs and maintain up-to-date inventory of all the resources.

    Meeting Multi-Cloud Compliance Requirements

    Every cloud user must comply with specific regulatory standards following industry guidelines and local, national and international laws. Organizations in the health care space, for instance, must comply with HIPAA rules, which are essentially a set of national standards to protect sensitive patient health information from being disclosed without the patient’s consent or knowledge. Meanwhile, manufacturing IT teams must abide by stringent intellectual property security protocols and protocols for other sensitive data like PCI and PII. 

    Ensuring compliance across multiple cloud environments is necessary, but undoubtedly a challenge. This is especially true in today’s attack-filled security landscape, where internal threats can pose as much risk to data security as external attackers. (32% of the organizations surveyed by Varonis found incorrect access authorizations and privileges assigned to users). Not to mention compliance requirements are constantly changing, making it even more difficult for organizations to meet demands.  

    This is why every IT and security professional invested in the cloud needs a solution that lets them set up compliance policies against their cloud infrastructure, making it easy for them to ensure compliance requirements in the case of any unforeseen natural disasters or security incidents. We’ve seen the damage that just one data breach can have on a business—costing them millions of dollars in cleanup and leaving them with considerable damage to their reputation. It’s imperative that an organization’s entire multi-cloud strategy prioritizes compliance and the security of sensitive data. 

  • Three Key Steps To Going Multi-Cloud

    Three Key Steps To Going Multi-Cloud

    Are you considering a multi-cloud strategy for your organization? Getting this sequence of foundational steps right can make a huge difference, both economically and performance-wise. FinOps or a cloud resource optimization solution like Archera, for example, is often brought into the picture after a company has already embarked on a multi-cloud approach and is knee-deep in long-term commitments. These solutions can help organizations avoid—or get further entangled in—problematic costs and contracts. We recommend a three-step approach for organizations that are going multi-cloud. The sequence of steps is:

    Cloud zoning policy: Determine which applications, teams and projects go where—and which cloud they will reside in.

    Architecture: Draw up the blueprint for your multi-cloud infrastructure. This specifies how applications run within a cloud and/or across clouds, particularly focusing on which applications need to be portable between clouds and cannot use vendor-specific services like AWS Lambda.

    Pay for it: Typically this is called the “contracts and commitments” phase, but we strongly encourage putting off decisions on contracts until you have created an overall plan, started to roll out and forecast usage so you understand the overall financial requirements for each platform.

    Step One: Cloud Zoning

    First, is cloud zoning. Your cloud zoning choices will have a major impact on commitments and costs. You need to map out what applications and processes will run on each provider. That entails deciding what can be locked into a single cloud, what needs to be portable between clouds and what applications need to be fully multi-cloud.

    Cloud zoning policy would cover, for example, whether you keep analytics and web serving on separate cloud providers.

    This also involves identifying your special focus areas. For example, if you want to ensure constant uptime even in the rare instances that AWS goes down, you might concentrate to extremes on load balancing among multiple clouds.

    If global availability is absolutely paramount to your business, you would set cloud zoning policies to support that imperative.

    Do not overlook the possibility that different teams need to use different best-in-class tools that may be specific to a provider; for example, an AI team that needs GCP TPUs.

    Step Two: Architect Your Multi-Cloud

    The high-level design and knowing what goes where are the crucial foundations for multi-cloud implementations. Forecasting is an art that comes into play here because you will need to forecast how your utilization of different services will grow.

    Hopefully, you will know how it’ll grow. Where do data science and AI go? Where is production application serving? Where is data warehousing? How will they grow relative to each other?

    The architecture phase is where you determine projects that need to be cloud-agnostic, and which don’t need to be portable and therefore can lean on proprietary CSP managed services.

    In general, in the long term, we see it is cost-advantageous for companies to take a flexible and containerized approach that can work with any infrastructure-as-a-service provider, or build with common standards if using managed services, such as using EKS for orchestration. This ensures not only portability between vendors’ common compute hosting solutions, but also portability within individual vendors’ managed service ecosystems, allowing customers to find an optimal fit for the application needs. For example, a containerized application can run on EC2, Lambda, ECS and a number of other options within AWS alone.

    Forecasting comes into play for specific parameters, including invocations of lambdas, the data storage your computing will need, the number of compute nodes and database utilization.

    Step Three: Financial—Contracts and Billing

    Forecasting continues to be important as you move into the selection of services and preparing for contracts. You need a clear understanding of your flexibility needs as the infrastructure you are consuming changes over time, both today and up to three years out. Then comes the process of matching costs to each forecast to build your cloud consumption budget,

    By studying your forecasts and the amount of uncertainty associated with each of them, you can begin to optimize commitment plans to zero-in on the best blend of contracts to cover the expected future usage.

    Throughout this challenging phase, look for ways to mitigate the risk of the commitments you’ll make. One way to do this is via commitment buy-back guarantees or by taking advantage of more natively flexible commitment options from AWS—such as compute savings plans, which can be consumed by any AWS compute usage in any region—in exchange for much lower savings rates.

    You can avoid confusion and lost time with careful budgeting and accounting. Make sure that commitment costs and savings are attributed specifically to the right applications, not spread like peanut butter across everything, which is often the default (unfortunately).

    Finally, when planning migrations of applications between vendors, interpret carefully between the big three and other providers. The performance semantics of a virtual machine at vendor X usually means something different than a VM at cloud provider Y, even if they appear to have the same specs.

    Going Multi-Cloud: Real Perspective

    In real-life multi-cloud computing where services are billed by the second, it is almost impossible to achieve 100% optimization of costs, commitments and performance. With manual approaches, very few organizations can expect to come close. Some companies do a very good job with attribution and tagging but do not accurately compare the hundreds or thousands of options between the big three providers to understand the optimal strategy.

    It can be extremely challenging, and it’s useful to understand the perspective of Amazon, Microsoft and Google. They respond first and primarily to the technical needs of their customers and often put off servicing their other wants (contracts, cost, transparency). For example, they make VMs spin up faster, but cannot make them less costly.

    Your challenge with going multi-cloud is much greater because you confront complexity by design, which makes optimization grounded in simplifying processes and automating as much as possible indispensable. Optimizing your multi-cloud smorgasbord requires involvement on your part, as well as external, neutral partners that exist to help the hundreds of thousands of organizations that consume cloud services.

  • Why DevSecOps Should Be Top Priority

    Why DevSecOps Should Be Top Priority

    DevOps culture and process are integral to maintaining the pace of cloud-native software development for organizations, especially when code deployments might take place many times a day. The ability to instantly create, populate and scale cloud applications and infrastructure, often automated through code, allows enormous agility and incredible speed. But moving this quickly means security is often left in the dust.

    The reality is many organizations still haven’t come to grips with how to properly secure the cloud. A lack of cloud security experience, coupled with legacy security policies that don’t encompass the cloud and a shortage of cybersecurity expertise relevant to cloud environments, presents a challenge. And cybercriminals are moving quickly to exploit these gaps: a 2021 report showed that almost half of the more than 2,500 disclosed cloud-related vulnerabilities recorded were disclosed in the last 18 months. 

    Due to the agile nature of cloud technologies, security must be integrated at every stage of the DevOps life cycle—also known as DevSecOps. A DevSecOps mindset is an absolute necessity for any organization that is leveraging the cloud, and requires new security guidelines, policies, practices and tools.

    The Cloud is Vulnerable

    Data breaches are among the most urgent concerns of any organization today. A 2021 report revealed that data breach costs rose from $3.86 million USD in 2020 to $4.24 million USD in 2021. The techniques that adversaries used to infiltrate the cloud differ from on-premises environments. Malware attacks are far less prevalent; instead, attackers exploit misconfigurations and other vulnerabilities.

    Another major concern is that organizations are usually using multi-cloud, which can cause a visibility issue. It can result in cloud workloads and traffic that are not properly monitored, leaving security gaps to be exploited by attackers. Also, DevOps teams tend to provide employees with far more privileges and permissions than needed to perform their job, which increases identity-based threats. According to research, nearly 80% of cyberattacks leveraged identity-based attacks to compromise legitimate credentials. 

    Threat actors will also deploy a variety of attack methods to compromise an organization’s cloud environment. Lateral movement is a common technique that involves threat actors going from the point of entry to the rest of the network (for example, infiltrating an end user or system hosted on-premises and then shifting their access to the cloud). Research showed that adversaries move quickly—in just 98 minutes they can move laterally from a compromised instance to another instance within the victim environment. 

    Alternatively, another way for attackers to profit from cloud vulnerabilities is by installing cryptominers onto a company’s system. Cryptocurrency mining is an activity that requires large amounts of computing power. Threat actors will use compromised cloud accounts to carry out this process and extract as much profit as possible, while simultaneously using up the company’s resources. 

    Shifting Security Left

    Protecting the cloud means securing an increasingly large attack surface that ranges from cloud workloads to virtual servers and other technologies that underpin the cloud environment. Attackers are always looking for soft spots they can exploit, particularly vulnerable cloud applications. With organizations moving to the cloud now more than ever to meet the needs of a remote workforce, opportunities to exploit cloud apps have increased. 

    Traditionally, code is subjected to security as the last phase before release. When vulnerabilities are exposed, either the release is delayed or the development team has to scramble to correct each security issue while the security team has to scramble to check the revisions. For DevOps teams, shifting security left ensures vulnerable code is identified as it is developed rather than in the testing phase, which reduces costs and results in secure cloud apps.

    The concept of shift left security is an essential part of the software development life cycle, and getting it right must be a top priority. By embedding security into the earliest phases of the development process, organizations can achieve DevSecOps and significantly reduce the security concerns around cloud-native software and application development. 

    Effective Cloud Security can Enable DevSecOps 

    Organizations that use DevSecOps tools and practices can build a powerful and secure cloud foundation. Unifying the visibility of multi-cloud environments and continuous intelligent monitoring of all cloud resources are essential in cloud security. That unified visibility must be able to detect misconfigurations, vulnerabilities and security threats while providing actionable insights and automated remediation for developers and DevOps teams. 

    Additionally, it’s essential to have the right security policies in place that enforce cloud security standards to meet (or exceed) industry and government regulations across the entire infrastructure. This includes everything from multi-factor authentication to general security best practices for all employees and robust incident response that ensures the company is prepared for an attack.

    However, the core of any effective cloud security strategy should always be up-to-date threat intelligence. Adversaries are constantly finding new ways to target the cloud and search for any weaknesses they can exploit. Having the latest data about threat actors and their tactics, and then applying it to breach detection is an absolute must. Threat intelligence enables security teams to anticipate threats and prioritize defense, mitigation and remediation effectively to preempt them. Delivering all this functionality from the cloud and for the cloud through DevSecOps provides organizations with the prevention, detection, visibility and response capabilities they need to beat attackers.