devopsy.kinsta.cloud

Tag: GCP

  • Tools for Sustainability in Cloud Computing

    Tools for Sustainability in Cloud Computing

    Cloud computing is a primary driver of modern technological advancements. However, as cloud services adoption continues to soar, so does a concern for their environmental impact. The further expansion of cloud infrastructure will demand more energy, which means the need for sustainable solutions has never been more acute.

    Due to their scale, cloud vendors operating large data centers have a greater impact on minimizing the IT’s industry overall carbon footprint than do smaller on-premises deployments. In this article, we highlight the main benefits of migrating business operations to the large-scale cloud providers known for their established sustainable practices, and point to useful resources.

    Follow the Leaders

    Major cloud platforms, including Google Cloud Platform, Amazon Web Services and Microsoft Azure, have pledged to achieve net-zero carbon emissions in their data centers by 2030. These platforms are well-positioned to lead the adoption of sustainability principles in cloud engineering due to their reputation and global reach.

    Microsoft’s study on the carbon benefits of cloud computing showed that an enterprise could reduce its carbon footprint by up to 98% by migrating to Microsoft Cloud, compared to running its IT operations in the on-premises data center.

    As for Google Cloud, all of its cloud products are carbon neutral. Google achieves this by purchasing renewable energy to reduce the carbon footprint from operations performed on its infrastructure, as well as by using high-quality carbon credits to compensate for its remaining carbon emissions.

    By moving your operations to the cloud and focusing on developing cloud-based applications, you can contribute to sustainable business practices and overall carbon footprint reduction.

    Increase Energy Efficiency

    Public cloud platforms rely on large-scale data centers with advanced infrastructure technologies. That allows them to reduce electricity consumption for overhead tasks such as lighting, cooling, and power conditioning. For example, according to Google’s environmental report, its data centers consume half the energy needed to power an average on-site data center.

    Energy efficiency is also driven by higher server utilization rates and the ability to manage workloads flexibly. These are the main factors that allowed AWS to make its data centers 3.6 times more energy efficient than a median data center run by a U.S. company.

    Additionally, the innovative approach applied to server architecture design in large data centers enables cloud service providers to develop custom hardware optimized for their customers’ workloads.

    Big Names are Committed to Sustainable Software Development Practices

    Another environmental benefit of running IT operations in the cloud is that public cloud platforms are committed to sustainable software engineering – and they want to make it feasible for anyone who uses their platforms.

    Green (or sustainable) software starts at the design phase, considering carbon emissions as a project requirement. According to the Green Software Foundation, sustainable software applications are carbon efficient (can run on fewer machines and resources), energy efficient (require less energy to perform the same tasks), carbon aware (prioritize renewable energy sources as a power source) and hardware efficient (use less hardware).

    IT operational efficiency is a fundamental of sustainable software engineering. Since cloud service providers already apply advanced technology to improve the energy and hardware efficiency of their infrastructure, cloud migration is a good start for supporting green coding.

    Microsoft developed eight principles of sustainable software development for engineers to follow when they build, design, and deploy applications. You can apply these principles to all types of applications, whether deployed on-premise or in the cloud.

    Amazon released a sustainable architecture guide with strategies for applying sustainability practices to optimize AWS infrastructure compute, storage and network layers. AWS also provides guidance on applying environmental best practices for designing and operating workloads in the cloud.

    A Tools Roundup for Measuring and Reporting Carbon Emissions

    In addition to implementing sustainability practices in their business operations, cloud platforms offer clients tools to monitor and measure carbon emissions linked to cloud service usage and report their overall carbon footprint following greenhouse gas protocol standards.

    Google Cloud provides users with an emissions calculator. Using Carbon Footprint, you can track the emissions from running your applications. The tool lets you view and analyze data related to gross carbon emissions and use derived insights in emissions reports.

    AWS also offers the Customer Carbon Footprint Tool for emissions tracking. You can calculate their carbon emissions associated with using AWS services, track emissions after migrating to the cloud, and use the data for sustainability reporting purposes.

    Microsoft customers can access the Emissions Impact Dashboard to estimate their carbon footprint related to Microsoft Azure and Microsoft 365 cloud services. Microsoft also offers Cloud for Sustainability for tracking and managing carbon emissions. It gives you visibility into your organization’s environmental impact, aggregates data from various sources, and offers practical recommendations for reducing a carbon footprint.

    Energizing Thoughts

    Achieving “net zero” is not solely the responsibility of large-scale cloud providers. Businesses must also contribute. Itransition’s cloud consultants believe that if more companies move their IT operations from on-premises servers to the public cloud, overall energy consumption and related carbon footprint will decrease.

    By leveraging renewable energy sources, optimizing infrastructure for energy efficiency and employing innovative technologies, these leading cloud platforms can attract a cohort of environmentally conscious clients. Those users may consider switching to the cloud not only for direct business benefits but also to make their operations more sustainable.

    Photo credit: Aimable Mugabo on Unsplash

  • Migration to AWS Cloud: Do’s and Don’ts

    Migration to AWS Cloud: Do’s and Don’ts

    What if one day, you were told to migrate to AWS/GCP/Azure/any other cloud provider? It would likely introduce some stress, to understate the case, right?

    I’ve seen quite a few migrations in my career and, in this article, I would like to share some thoughts to help DevOps engineers, architects, managers or anyone else who might be involved in such a migration. I’m focusing on migration to AWS mostly because I have a specialization in this subject and because it’s fairly common, but I think these experiences are applicable to any other cloud provider. For this case, I’ll cover migration from on-premises to a cloud because these types of migrations are much more difficult (in my opinion) than cloud-to-cloud migrations. I’ll also share my own perspective on do’s and don’ts of migrations. But please filter them through critical thinking and remember that everybody has their own background and experience. What’s good for one might be bad for another.

    What is a Cloud Migration?

    Let’s start by defining what migration is. How do you know if it’s a migration? I like the following definition: 

    Cloud migration is the process of moving a data center’s capabilities to IaaS providers.

    “Capabilities” is the keyword. A business does not migrate servers/virtual machines/hardware/data or anything else. A business migrates its capabilities.

    There are seven migration strategies (or seven Rs): Relocate, rehost (lift and shift), replatform, repurchase, rearchitect/refactor, retain and retire.

    For example, I’ve seen situations when a company was creating a new product that would replace an existing one hosted on-premises. The product would be designed to be well-architected and cloud-native from the very beginning and would be hosted in a cloud. Is that migration or greenfield project type? From the definition above, we can say that this is a migration. This is a rearchitecture strategy for migration.

    What if we buy a new SaaS subscription instead of some software we host on-premises? This is also a migration: A repurchase strategy.

    Let’s dig deeper into these seven migration strategies:

    Relocate. We host some workloads on-premises and move them as-is into the cloud. This is possible in limited cases; when we migrate cloud-agnostic workloads or when a platform might be cloud-native. Examples: Relocate a Kubernetes cluster from on-premises to the cloud or relocate VMware machines with VMware Cloud.

    Rehost. This is also known as lift and shift. We convert virtual machines/servers on-premises to virtual machines in the cloud. Examples: Migrate on-premises virtual machines to EC2 instances with CloudEndure, or create EC2 instances, install the software and apply the same configuration as on-premises.

    Replatform. We migrate a workload to a cloud-native platform without rearchitecting systems. Examples: Migrating PostgreSQL to AWS RDS or Docker containers to ECS.

    Repurchase. We replace some custom/legacy system with SaaS. Example: Replace custom on-premises email system with SendGrid or replace CRM with Salesforce.

    Rearchitect. We change your application’s architecture to be cloud-native and use managed cloud services. That also includes rebuilding from scratch. Examples: Change the code of your apps to upload files to S3 instead of local storage or containerize an app and migrate to ECS.

    Retire. We decide that a piece of the workload will be eliminated if not needed. Example: Log servers are no longer needed as migrated applications use CloudWatch.

    Retain. We leave it on-premises. Usually, it’s temporary. Example: A huge Oracle database with a lot of functions and customization is not moved to AWS because of the massive costs. It’s decided to keep it on-premises until it’s replaced with another solution in the modernization phase.

    I like the following picture that shows the high-level stages of each migration type. It may be a helpful cheat sheet to approach migrations.

    Picture Source: https://aws.amazon.com/blogs/enterprise-strategy/new-possibilities-seven-strategies-to-accelerate-your-application-migration-to-aws/

    Migration Don’ts

    I don’t recommend the following when performing a migration:

    Migrating too quickly. A business might think, “We have to migrate to the cloud quickly. Let’s do lift and shift right now!” It’s better not to start right away. Are you sure that rehosting strategy will really be faster than some other strategy? In one instance, we tried to migrate on-premises VMs, but it didn’t work because the OS on the machines was quite old. Some OS-level dependencies didn’t work on AWS’ hardware. This required a lot of configuration work, custom code and testing and the initial estimates were completely wrong. It eventually turned out to be a replatform. 

    Assess what you have, analyze it, analyze the business case and think. During this engineering work, we should stop and think before we act.

    Migration without clear goals. Why are you migrating? If you can’t answer the question, you probably need to find an answer or not migrate at all. I’ve seen situations in which businesses wanted to migrate to the cloud to reduce costs. They performed a lift and shift migration without doing a total cost analysis. Only after the fact did they realize that it cost even more than when it was in a colocation center. This migration may be considered unsuccessful.

    To avoid this, define clear goals and define the target state that achieves these goals. If costs are the driver, make the proper calculations and plan accordingly. Cost optimization will be the main thing to focus on when you plan your target state. If availability is the reason, measure it, define SLOs and focus on availability in a target state.

    Black box migration. Don’t treat workloads you migrate as a black box. It is almost critically important to know what exactly you migrate, what technical requirements it has, what dependencies it has and how it works. That information will allow you to choose the correct strategy for workload migration. If this is not done, there’s an excellent chance that you will choose the wrong path and the result will be lost. Capturing information about your systems is the most important task when planning.

    Don’t forget well-architected. Migration is stressful. That’s why people tend to try to get through it quickly on as short of a timeline as possible, focusing on the only thing: Making everything work in the cloud ASAP. They set aside well-architected framework pillars. This is a mistake; it may lead to a different set of negative consequences of different severity. Don’t ignore well-architected framework pillars, or you won’t know about potential issues or risks until they have already materialized.

    Use one strategy for everything. It’s always easy to make a single overarching plan for all workloads. For example, deciding to do lift and shift and then rehost everything in the cloud. But what if some things could be retired? What if some components could be replatformed with little effort? You will save significant resources by analyzing all of the components of the workload and deciding on a unique strategy for every component. Collect data and plan properly.

    Cloud Migration Do’s

    Do perform a cloud readiness assessment. If a person migrates to a new location, they should consider:

    • That the climate will be different
    • The language spoken in that location may be different
    • The cost of living will be different and perhaps more expensive

     When a company migrates to the cloud, they should ask questions including: 

    • Have we considered all the risks?
    • What must be changed for the workload to actually work?
    • Do we have the human resources required for all of the work?
    • Do I have the budget to accomplish everything? 

    The Cloud Readiness Assessment is a long-form interview about varying processes in the company that identifies whether a company is ready to live in the cloud. It’s based on the Cloud Adoption Framework (CAF) and allows us to understand what should be changed so that a migration can happen successfully. AWS has a Cloud Readiness Assessment tool which covers all of that. I urge you to use this process for all workloads being considered for migration.

    Create a business case. Describe the business case. What are the drivers for migration? What problems are resolved with the migration? What goals should be achieved by migration? Be specific: If you intend to reduce costs, then calculate the sum. If you intend to improve availability, then define a clear SLO. That will be the number-one driving force for your migration. All other artifacts should be based on it.

    Automate discovery and data collection. Use automated data collection and analysis to create a portfolio for migration. Don’t base your analysis on manually created spreadsheets or verbal communication. Let machines collect data about inventory and usage statistics. The more precise data you collect, the better. AWS Migration Evaluator service will help you to do this in most cases.

    Portfolio management. Create a portfolio of workloads to migrate, analyze them, choose a migration strategy for each, choose some for the pilot/first wave migration, estimate timelines and prepare a plan. Execute the migration after that. Repeat until the migration portfolio is empty. Share the data. Have subject matter experts review it.

    Found CCoE. This is part of the CAF mentioned above. Before executing the migration, create a team of people responsible for creating a strategy and defining a good standard of living in the cloud: A Cloud Center of Excellence. It should include people with a variety of subject matter expertise including management, operations, platform, people, finance and every other department consuming or providing services in the cloud. These people will prepare a landing zone for the migration, hard policies and softer policies for the landing zone; preparing the company for life in the cloud. Don’t fear revisiting any policy.  Make changes as new factors come to light.

    Well-architected framework reviews (WAFR). Do well-architected framework reviews (WAFRs) during migration waves and after them. That will allow you to avoid foolish mistakes and to get a high-level overview of what you have done from a technical perspective.

    Modernization plan. Prepare a modernization plan along with the migration plan. Migration isn’t the end of the story. To be effective in the cloud, you will have to do well-architected reviews and modernization. The first modernization is likely to be huge; that’s why it’s important to plan and to schedule budgets and resources in advance. Failure to do this will lead to increased operational costs, not decreased costs.

    Summary

    If we want to reduce the risk associated with a migration and to make it less stressful, we do not rush. You may believe that rushing will save you time and other problems will be managed later, but experience tells us that this is wrong. The most likely outcome is that you will end up resolving all the issues encountered in the most stressful situation possible: When you cut over to your new cloud-based production environment. Instead of resolving issues in a well-considered way and in advance, the choices will be made under duress. Proper engineering principles must be applied here. Picking up a bridge and moving it from one river and plunking it down on another never works. The key to migration success is to measure, analyze, design and plan. Migrating a workload to the cloud is hard, but I hope these do’s and don’ts will make it easier.

  • GitLab Allies With Google to Improve Developer Productivity

    GitLab Allies With Google to Improve Developer Productivity

    GitLab Inc., in collaboration with Google, today launched an open source Cloud Seed tool that makes it simpler for DevOps teams to consume Google Cloud Platform (GCP) resources.

    The Cloud Seed tool, announced at the virtual Google Cloud Next ’22 conference, is integrated within the GitLab web UI to make it simpler for developers to consume Google cloud resources—such as Cloud Run for building and deploying containerized applications—and the managed Cloud SQL database service.

    Nima Badiey, global vice president of alliances for GitLab, said the goal is to reduce friction that would otherwise be created by requiring developers to write code to consume these services using a set of lower-level application programming interfaces (APIs).

    That self-service approach not only improves productivity but provides the added benefit of reducing the odds those services might be misconfigured in a way that creates a cybersecurity vulnerability, he added.

    As it seeks to gain ground on Amazon Web Services (AWS) and Microsoft, Google has a vested interest in working with providers of DevOps platforms to make it simpler for developers to consume cloud resources. The challenge is that developers often make mistakes when they programmatically invoke cloud services. Those resulting misconfigurations are all too often not discovered and remediated until after there has been some type of cybersecurity incident.

    In the wake of a series of high-profile breaches of software supply chains, there is a lot more focus on security. The challenge, of course, is finding a way to ensure application development platforms are as secure as possible without slowing down the rate at which software is developed and deployed. Achieving that goal requires the right mix of policies, training and systems, said Badiey.

    Most organizations are trying to strike a balance between the need for greater security and their need to attract and retain developer talent. In theory, the rise of DevSecOps best practices is pushing more responsibility for security further left toward developers. However, most developers have little to no cybersecurity expertise, so it’s clear more guardrails need to be built into DevOps tools and platforms to prevent cybersecurity mistakes from being made.

    It’s not clear how much improved developer productivity and greater security will drive organizations toward one cloud platform versus another, but in an age where many more organizations now routinely employ two or more cloud platforms, it could make a significant difference. Developers don’t especially enjoy remediating applications after they are deployed in a production environment because they have generally already moved on to other projects. IT operations and cybersecurity professionals are also likely to nudge developers toward platforms that create the least amount of operational overhead for them.

    Regardless, one thing that is certain is compliance requirements are about to become stricter for all concerned as scrutiny of software supply chains intensifies in the months ahead. The issue now is how to proactively address those requirements before they become a much larger issue.

  • Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region

    Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Linux 6.0 promoted to Stable, Debian 12 will include closed-source binaries, and Google Cloud opens its first Africa region. (more…)

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

  • Sustainability No Longer Just a Buzzword for Cloud IT

    Sustainability No Longer Just a Buzzword for Cloud IT

    A recent CloudBolt survey on IT sustainability finds that sustainability is no longer just a buzzword — the market is demanding real change, and it appears that environmental concerns finally are influencing large IT investments. For example, 67% say that a cloud provider’s sustainability initiatives are important in deciding whether to do business with them. A significant portion of organizations are even willing to pay a premium to support green initiatives!

    Below, I’ll review the report to find its major takeaways. We’ll see how sustainability is directing real action in cloud IT and briefly compare how the market perceives current green initiatives among three top cloud providers: AWS, GCP and Azure.

    Sustainability Gains Real-World Traction

    In June and July 2021, CloudBolt polled 256 global CxOs and tech leaders on its Pulse platform, and found that 76% of respondents now consider climate change an existential threat. Not only are IT purchasers factoring compute and cost, but a sustainability conscience is now influencing executives to direct sweeping change. In fact, 79% of respondents indicate their IT departments are expected to help their companies achieve specific sustainability initiatives driven by the board of directors of the C-suite.

    Interestingly, other studies found that a sustainability commitment results in tangible business outcomes. For instance, 88% of the research conducted by Oxford University and Arabesque showed that solid environmental, social and governance (ESG) practices result in better operational performance of firms and higher profits. This study also noted that 80% of the time, a company’s stock price is positively influenced by sustainability practices.

    Climate Conscience Guides Cloud Choices

    Most organizations now consider a cloud vendor’s sustainability initiatives when choosing whether to do business with that provider. A full 78% of respondents agree that the public/private cloud choices they make can materially affect the environment for better or worse. New environmental cloud commitments not only attempt to minimize carbon emissions from their data centers but factor in ecological ramifications and aim to erase companies’ historical carbon footprints, as well.

    Cloud consumers also want to contribute to addressing these green initiatives. An impressive 79% of respondents indicate that they will pay a premium to work with vendors who incorporate sustainability into their business. And 41% of companies are willing to pay a premium of 11 % to 15% of their current bills. This shows that sustainability is now a vital factor within the marketplace, and companies are willing to pay the price to increase their own environmental standing.

    Though this commitment is undoubtedly growing, the report did find that operational requirements such as security, cost and agility, still rank significantly higher than sustainability when comparing cloud providers. Though IT professionals recognize climate change as an existential threat, they still have day jobs and must keep operations moving.

    AWS: King of Green Clouds

    Slightly more than half (51%) of respondents agree that the industry-wide green energy commitment is real and growing among all cloud providers. However, when comparing the top three—Amazon Web Services (AWS), Azure and Google, AWS appears to be emerging as an IT sustainability leader; 41% of respondents perceived AWS as doing the most to address green initiatives.

    AWS is on track to power its entire operations with 100% renewable energy by 2025. With their solar plant investment in April 2021, Amazon became the largest corporate buyer of renewable energy in Europe. Around the globe, AWS has invested in a combination of on-site solar, solar farms and wind farms to power their data centers and Whole Foods divisions.

    To their credit, both Microsoft and Google also committed to climate pledges that affect their cloud footprint. Azure supports a similar initiative to reach 100% renewable energy by 2025, in addition to further investments to improve water, waste disposal and surrounding local ecosystems. Google Cloud’s commitment is to operate on carbon-free energy 24 hours a day by 2030, and the company has already achieved 100% renewable every year since 2017.

    Not only does AWS appear to be doing the most to address its environmental impact, it also retains the most market traction as a cloud leader. The majority of respondents (62%) said that AWS is winning the cloud wars while only 31% said Azure and just 7% said GCP.

    Final Thoughts

    It is heartening to see that ESG standards are having a measurable impact on a company’s cloud allegiances. The market now demands real change and is willing to pay the price for more ethical and sustainable cloud hosting.

    But choosing a cloud provider is only one aspect of reducing IT’s impact. As I’ve covered before, there are many ways IT can curb its climate impact. Such actions include optimizing overall infrastructure, shuttering zombie VMs, avoiding over-provisioning resources, increasing performance visibility, refactoring code and other measures. What’s great is that most of these initiatives have the added benefit of reducing cost to the business.

    The CloudBolt Industry Insights Report, The Truth About IT Sustainability: Paying More Green to Get More Green, surveyed 256 IT leaders on their perception of cloud sustainability. For additional insights, you can pick up a copy here.

  • Majority of Organizations Now Adopt Multi-Cloud

    Majority of Organizations Now Adopt Multi-Cloud

    As IT’s digital footprint grows, its cloud footprint is rising both in size and complexity. As a result, most organizations have matured into multi-cloud operators. A multi-cloud approach empowers different divisions with the autonomy to select the right computing environment for their needs. It also enables a lift-and-shift ability to port workloads across cloud service providers (CSPs) when needed. Adopting a multi-cloud model could bring performance benefits, cost savings or better scalability, all while encouraging a more vendor-neutral stance.

    We’re in a multi-cloud world. A recent HashiCorp study found three out of every four organizations are already multi-cloud. This is a staggering increase from just a few years ago when mono-cloud was more accepted, and operators had zombie-like allegiance to AWS. The uptick in multi-cloud signals the maturity of offerings at other CSPs, like Azure and GCP. It also signals differentiation among clouds as each hones in their unique value propositions.

    HashiCorp’s inaugural State of Cloud Strategy Survey offers some very clear results about the state of multi-cloud adoption. Below, I’ll review major takeaways from the report to better understand the state of multi-cloud adoption. To sum it up, large organizations tend to benefit most from multi-cloud adoption, as there are still significant roadblocks to truly reaping a sizable return from a multi-cloud status. Yet, more infrastructure automation may help companies of all sizes respond to multi-cloud complexities.

    The Multi-Cloud Era

    DevOps truly operates in a multi-cloud era. The report revealed 76% of organizations are already multi-cloud; that leaves only one in four companies leveraging a single cloud. And, that trend won’t stop—within two years, 86% predict they will be multi-cloud operators. The study also confirms that the larger a company is, the more likely it will adopt multi-cloud—94% of large enterprises with 5,000 or more employees are multi-cloud.

    So, what’s driving this cloud fragmentation? Well, 34% of respondents cite digital transformation as a top driver for multi-cloud adoption. In the race to meet new digital innovation demands, multi-cloud has emerged as a strategic force. To enact this rapid change, many organizations are investing in a cloud center of excellence (CCoE) to guide cloud transformation efforts. A CCoE is most common within large companies with a cloud budget of $5 million or more.

    Speaking of budgets, cloud spending is going through the roof. In 2020, only half of companies met their projected cloud spend, and 39% of companies overspent their allotted cloud budgets. As I’ve covered before, cloud-native costs are notoriously difficult to identify and trim. Without the proper guardrails to manage spending, surprise data egress fees or hidden server costs can strain the cloud checkbook. As it stands now, 40% of companies lie in the $100,000 to $2 million per year range, and 6% of enterprises are investing $50 million a year or more into multi-cloud. This spending will likely increase in the coming years as cloud reliance expands.

    Enterprises Benefit Most

    So, which clouds are companies using? If we compare cloud adoption, AWS is a clear market leader; 88% of companies use AWS, 74% use Azure and 61% use GCP. AWS’s hegemony is not expected to fade in the next two years. Yet, while AWS usage will remain the same, competing CSPs will experience modest increases. This is likely due to Azure and GCP making gains in geographical zones outside North America, such as Asia-Pacific and Africa.

    In terms of technology used in cloud environments, open source software (OSS) is a popular choice. Cloud-native open source projects, such as Kubernetes, OpenStack and Terraform, have taken on a life of their own, with vibrant community support. However, not all shops build upon OSS and run it themselves. Somewhat ironically, we’re seeing more managed OSS emerge. One stand-out area is provisioning, where 42% of organizations build with open source and run it themselves.

    On the whole, multi-cloud is working at most enterprises, with 53% of survey respondents saying multi-cloud has helped achieve their business goals. The top benefit of multi-cloud is digital transformation, at 34%. This is followed by avoiding lock-in (30%), reducing cost (28%) and scalability (25%). But multi-cloud does not treat all companies as equals; the likelihood of multi-cloud success increases as the company size increases. Less than half (42%) of small companies say they have multi-cloud success, which jumps to 64% for large enterprises. With fewer resources for support, multi-cloud may be less beneficial for startups and small to medium businesses. In fact, 41% of professionals say a lack of in-house skills inhibits their cloud success.

    Challenges in a Hybrid Multi-Cloud World

    An ongoing talent gap is just one potential challenge to cloud success. Just over half (51%) say cost concerns are a top inhibitor to their cloud program success. Hybrid cloud complexity is another prominent challenge, with 35% of organizations citing it as a major cloud obstacle. Many enterprises are still grappling with the remnants of legacy on-premises estates. But technical debt is not the only reason for hybrid modalities. Surprisingly, large platforms even have constructed their own data centers or used colocation as an intentional strategy.

    Security is a top cloud inhibitor, according to 47% of IT professionals. The leading cloud security concerns include data protection (40%), data theft (33%) and regulatory compliance (31%). The myriad cybersecurity threats evolve each day, and cloud technologies are not immune; for example, web APIs are now a significant threat vector. A separate report found a 300% increase in malicious API traffic in the past six months. Other issues, such as exposed keys, insecure defaults and misconfigurations are known to hamper cloud-native infrastructure.

    Contrary to popular belief, nearly half (46%) of companies reported that COVID-19 has not quickened their cloud adoption. This reality could indicate that cloud migration has been planned for years, and recent adoption is only part of an ongoing trend. The study found that the pandemic did, however, accelerate things like infrastructure-as-code (IaC), container orchestration, compliance and governance and other operational factors.

    Infrastructure Automation Supports Multi-Cloud

    Multi-cloud feels like an inevitable result of accelerating cloud adoption in a more diversified market. Rising multi-cloud use is also arguably in line with Conway’s Law. As organizations develop more and more digital experiences across new verticals, the platforms and backend processes to support these initiatives will inevitably grow more and more complex.

    To mitigate some of the issues posed by multi-cloud, many organizations are turning toward increased infrastructure automation. In fact, 70% of those surveyed said infrastructure automation tools are extremely important to their organization. Of these tools, provisioning automation (75%) is the most popular kind in use. Automation for other areas, like networking (58%), security (50%) and app development (69%) follow.

    Hashicorp’s State of Cloud Strategy Survey boldly announces, “Welcome to the Multi-Cloud Era,” and its findings back up that sentiment. For further insights, you can view the results freely on this website.

  • Multi-Cloud Is Not About Lift and Shift

    Multi-Cloud Is Not About Lift and Shift

    Multi-cloud is often framed from the perspective of “lift and shift.” In other words, an organization takes a computing environment previously running on one cloud and transfers it over to a different service provider. Cloud migration may make sense for cost savings or performance benefits and such a shift may be necessary when migrating on-premises data centers to a public cloud.

    In theory, lift and shift sounds like it would empower cloud consumers with more choice in the marketplace. However, according to John Gentry, CTO of Virtana, lift and shift is quite rare in practice; it may not be the true driver behind multi-cloud strategies. Moving resources between clouds can result in costly egress fees. Plus, culturally-ingrained cloud preferences become challenging to shake. Unique configurations and add-on software-as-a-service (SaaS) make each cloud more nuanced, requiring new skills and procedures with every migration.

    Instead, Gentry advocates for a “fit-for-purpose cloud” strategy. This attitude is less about moving similar workloads between clouds but, instead, pairing particular types of workloads with the appropriate cloud types. According to Gentry, using multiple clouds simultaneously could still help organizations strategically align their digital resources and reduce dependency on a single cloud service provider (CSP). But, the real value of a hybrid multi-cloud setup lies in matching computing environments to different business layers.

    Fit-For-Purpose Cloud

    At first glance, the ability to move between clouds appears to be driving a new multi-cloud economy where cloud strategists can swiftly migrate resources and optimize intercloud utilization. However, when organizations attempt to shift, they usually experience many hidden costs, Gentry warned. These often pop up around data egress. Or, new data storage costs may take a surprising toll, Gentry added. “A lot of companies look at it from a computing perspective and they don’t account for the storage footprint.”

    DevOps in the cloud also introduces new responsibilities and processes that may differ between clouds, continued Gentry. From unique storage operations to managing the life cycle of a virtual machine, each cloud carries unique configuration methods. This makes it more difficult to abandon established procedures in favor of a different computing arrangement.

    Nevertheless, Gentry recognizes that we’re starting to see a maturing effect of the multi-cloud concept, especially among large enterprises. “Companies have a multi-cloud strategy—it’s less about moving between clouds than about picking a cloud that has specific advantages for a given workload,” he said. In a fit-for-purpose cloud approach, different workloads correspond to different layers of the business. For example, an organization may require a local data center or private cloud for high-security data. Certain applications may benefit from a distributed global public cloud, whereas other workloads could reap performance benefits and cost savings from a cloud-adjacent edge model. “These specific areas may not have anything to do with one another other than supporting the overall business,” explained Gentry.

    Matching Cloud Types to Business Units

    So how do we match the workload at hand to the ideal computing arrangement? Gentry identified three emerging cloud types:

    • Private cloud: A private core for particular functions that can’t be replatformed or rearchitected. Business areas such as financial records or patient care hold sensitive data that must be stored properly to meet regulations and SLAs.
    • Public cloud: End customer-facing, where sensitive data is not an issue. Public distributed cloud is ideal for delivering a highly available front end for customer-facing digital experiences.
    • Cloud adjacent/edge: When an environment is kept in a cloud adjacent facility with relatively local geographies. This may sit alongside the public cloud or connect to a front end in a cloud.

    For example, Gentry described how a large health care company uses a hybrid multi-cloud setup to support various business divisions. The organization is keeping traditional patient care workloads exclusively on-premises; due to regulatory reasons, it will never see the inside of a cloud. Yet, they are simultaneously building the next generation of applications in a public cloud, using Google Cloud to scale a clinical trial division. Simultaneously they began using Microsoft Azure for their back office. This scenario highlights one peculiar advantage of late-stage cloud adoption, noted Gentry: “They had the advantage of being able to take a more thoughtful approach.”

    Gentry described another case of an organization performing genomic sequencing. For data-heavy applications like this, where there is a high dependency on input and output, syncing with a public cloud could be extremely costly and introduce latency. For them, the most cost-effective method was to use a cloud-adjacent or edge model alongside a public cloud.

    How to Leverage Fit-For-Purpose Cloud

    One situation that may warrant cloud migration is a complete replatforming, noted Gentry. He described one early cloud adopter that rushed into AWS, only to find it wasn’t cost-effective for their needs. Architects then had to make tough decisions to determine what would be repatriated back to local data centers and what should remain in the cloud. “Their only motive going from cloud to cloud was, ‘We made a bad choice and we want to move.’”

    Clearly, to match cloud use with business requirements, you must choose the appropriate cloud. AWS is widely adopted for elastic computing and offers a wide product catalog. GCP is offering feature innovation and cost reduction to compete and is going after un- and under-penetrated regions. Azure, on the other hand, will offer licensing advantages if you are a Microsoft shop.

    Secondly, to unite IT around a hybrid multi-cloud strategy, you must remove the adversarial state between traditional ops and cloud ops. Classic ops is typically very safety-oriented, using a slow approach with endless tests in pre-production. Traditional ops may produce yearly updates. This is directly opposed to the new cloud ops approach, which emphasizes agility, speed and constant deployment. “They sit in different silos,” Gentry explained.

    To solve this dilemma, companies must share technical skillsets between the three main cloud types. “DevOps must become a continuum for all types,” Gentry said. In addition to cultural change, DevOps tools must evolve to monitor workloads across a hybrid multi-cloud estate. This will require integration to tie together tools and deeper observability.