devopsy.kinsta.cloud

Category: Features

  • Force Me Back to the Office? Apple ‘Hasn’t Learned Anything’

    Force Me Back to the Office? Apple ‘Hasn’t Learned Anything’

    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: I’m devoting my entire column to new ways of working. Whether it’s remote work, enforced hybrid working or a four-day working week, let’s triage the trends and futz with the future.

    Analysis: The Great Resignation — Not So Great

    Too many managers are stuck in their old ways. Despite the success of pandemic-era WFH, they yearn for how it used to be. But that ship has sailed.

    Mark Gurman: Apple Sets Return-to-Office Deadline

    “Pushing employees back into the office”
    The company … set a Sept. 5 deadline [and] will require employees to work from the office on Tuesdays, Thursdays and a regular third day that will be determined by individual teams. [It] has been working toward getting its employees back in the office since at least June 2021, when it first announced the three-day policy.
    …
    The iPhone maker has been one of the most stringent technology companies when it comes to pushing employees back into the office, irking some staffers. … An Apple spokesman declined to comment.


    It “Shows the Company Hasn’t Learned Anything,” cries Jason Aten:

    “Not the same thing as actual collaboration”
    Right now, every company is trying to figure out how to get its employees back to the office. Despite the fact that the world did not, in fact, come to a stop over the past two years. … Many companies—especially Apple—had their best two years ever when most of their employees were working from home.
    …
    Apple SVP of software Craig Federighi … told employees in an email … he “can’t wait to experience the special energy of having all of us back in the office together again!” … I imagine a lot of the people who work in the software organization are wondering whether that “special energy” actually makes them more productive—or if it’s just a thing managers feel as they watch employees.
    …
    If we’ve learned nothing else from the pandemic … coming to the office doesn’t make them more productive. It might make managers feel better … but that’s not the same thing as actual collaboration.


    But WFH doesn’t suit everyone. Here’s Aunty’s Kate Morgan: Why workers just won’t stop quitting

    Anthony C Klotz, a professor of management at University College London’s School of Management who coined the term “Great Resignation” [says] in addition to the original push factors … the reasons people are resigning have diversified. … Some workers are now swapping jobs that require them to be present in the workplace for remote positions. Other workers … are leaving remote jobs for ones that have a larger in-person component.


    WWSJD? quonset knows:

    Regardless of the jerk he was, Steve Jobs had grand visions which he brought to fruition. … One thing he stressed was the personal connection and serendipitous encounters.
    …
    It’s why, before he died, he was arms deep in the design of Apple’s headquarters. He wanted people to bump into each other, he wanted interaction between different groups. It’s why it’s designed the way it is. People are funneled to certain areas and have no choice but to interact with others.


    Is there an unintended brand consequence? u/Latinhypercube123 demonstrates there might be:

    Hahahaha. Apple is such a dead end company now. They’ve literally become what they ridiculed IBM of being: Corporate monolith of sameness.


    But is there a better way? You should read Evelyn Yu: Bank Says Four-Day Week Is The ‘Future of Working Life’

    “Flexible work is here to stay”
    Six months after switching to a four-day working week, the UK’s Atom Bank said it’s seen benefits from talent retention to improved productivity. … Days lost to sickness fell over the period and customer service ratings also improved.
    …
    Even as the pandemic recedes and some bosses push for a return to the office, there’s increasing evidence flexible work is here to stay. Office vacancies in central London are at the highest level in more than 15 years.


    Not just in the UK—it’s in Canada too. Here’s Sean Davidson:

    “Huge impact on employee retention”
    Ross Wainwright, CEO of Alida, said the software company implemented four-day work weeks for its 500 employees at the start of June and the two-month trial wraps up this week: … “The early results are fantastic. … The employees are clearly happier. … This is about getting better balance for our employees and helping to invest in their mental health.”
    …
    He said the trial is also having a “huge impact” on employee retention. … The most “unanticipated” result of the trial was how empowered his employees told him they felt, knowing the company trusted them to get the job done with a reduced schedule: “We empowered the employees to get the work done within their schedule.”


    Also in Toronto is u/SuperChloe:

    We had similar results at my company when we initially trialed 4-days (also not longer days, still 9-5) — overall increased output/productivity and employee satisfaction. We’ve moved to permanently having a 4 day work week.


    Meanwhile, @AnnaLovesVoting is just fine with a hybrid schedule:

    I don’t need 100% WFH, I’m willing to go to an office 1 maybe 2 days a year.

    The Moral of the Story:
    The tempter or the tempted—who sins most?


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Carles Rabada (via Unsplash; leveled and cropped)

  • Understanding the Importance of Developer Experience

    Understanding the Importance of Developer Experience

    If you’re creating a developer tool, you’re bound to run into this dilemma—you know the inner workings of it really well, but others don’t. And without solid documentation and samples to follow, it can be challenging for another person to get started. Friction with the tools we use can contribute to burnout, inhibit creativity and slow down innovation.

    Developer experience (DX) is becoming integral for any software company to consider. I recently met with Christine Spang, CTO and co-founder of Nylas, to consider the benefits of investing in developer experience. Below, we’ll take a look at what exactly DX is and consider some best practices for implementing it.

    What is Developer Experience?

    Developer experience (DX) is similar to user experience but for developer-facing tools. DX considers the developer’s journey while developing with a certain framework, language or platform. “Developer experience is the amount of friction a developer experiences between having clarity on what they want to implement and getting to the point where you have created that thing,” said Spang.

    For example, consider integrating with an API to solve a common use case like payments integration. There are many steps involved here, from reading the reference documentation to getting an API key, testing calls and understanding how the service responds. After developers initially integrate the API into their application, they may also have to make continual updates as the service versions. Throughout this journey, DX can be thought of as “how hard it is to figure out how to translate from idea to output,” said Spang.

    It’s also important to note that DX isn’t only relegated to public-facing platforms. Having a quality developer experience is just as crucial for internal software. The urgency to improve internal developer experience is increasing with the surge of APIs being developed, especially since the majority of them (58%) are private APIs, according to Postman’s 2022 State of API Report. Depending on the size of a company, internal DX can encompass many areas.

    Best Practices for Investing in Developer Experience

    So, what are some methods to improve developer experience across the board? Well, having up-to-date documentation, code samples, better examples and standardized documentation rank high as positive developer experience traits. Spang also shared some helpful best practices to improve DX:

    Provide scaffolding for the most common cases. Measure patterns around the kind of things people are building with the platform and offer scaffolding to support the common use cases. This might equate to a getting started guide for a common scenario.

    Offer sample code libraries. It’s a lot easier to edit code than write it from scratch. With that in mind, create pre-baked environments where developers can play around. Offering working apps, use case templates and glue code can be a practical means to help developers get going more seamlessly.

    Start with the reference manual. Walkthroughs and sample code should never replace a complete reference manual. It’s essential to have up-to-date documentation to cater to advanced users from the get-go. From here, you can generate Postman Collections or interactive sandboxes built around the reference specification.

    Measure DX success and iterate. One way to monitor developer experience metrics is to record the onboarding flow and measure conversion rates. Where APIs are concerned, this can be tracked by asking how many people get through to making calls? What is the mean time it takes to make the first call? Knowing such metrics can inform how effective your tool’s self-service features are.

    One point that’s important for DX is walking the fine line between too much custom work and focusing on the core project. On that note, Spang recommended “making sure whatever you’re building maps to the overall vision of the company.” In essence, if you’re not a consulting shop but a product company, you should stay true to that objective.

    “You want to make the path for what people commonly want to do very easy,” said Spang. “Yet, you don’t want advanced users to feel constrained by the platform.”

    Examples of Quality Developer Experiences

    For those creating developer-facing services, it’s helpful to have a framework to model. So, what are some examples of quality developer experiences?

    Well, top public APIs are great examples of where the bar is set for developer expectations these days, said Spang—services like Twilio or Stripe demonstrate relatively seamless developer journeys. Spang also pointed to companies with a strong DevOps and CI/CD background, like Etsy, who have for years invested in usable backend infrastructure that accelerates internal development.

    For other sources of quality developer experience, consider the high-ranking developer-favorite technologies from the latest 2022 Stack Overflow survey. Engineers love working with technologies such as PostgreSQL, AWS, Phoneix and Docker. The newer, trending languages tend to be increasingly usable, too. For example, 86% of developers said they love working with Rust while 76.65% dread working with Objective-C.

    The Overall Benefits of DX

    An investment into developer experience can help improve agility and developer satisfaction, said Spang. For one, an easier path for development increases the velocity in how you ship and evolve projects over time. Secondly, developer experience equates to less burnout and less turnover, both of which can have real business impacts.

    The software development industry is growing like wildfire, bringing in waves of entry-level developers each year. Interestingly, the average experience level is decreasing, increasing the need for more abstracted tools and toolkits, said Spang. In this environment, developer experience undoubtedly shines as a competitive advantage.

    So, if you’re creating developer-facing tools, consider the experience others will have when using them. Increasing developer experience may just be a defining factor in the project’s success and the long-term happiness of your developer community.

  • NewOps? AIOps? NoOps? Just Don’t Call Me Late for Dinner

    NewOps? AIOps? NoOps? Just Don’t Call Me Late for Dinner

    Once again, we are seeing an uptick in the use of the term NoOps. I always felt that NoOps was a misleading and, in fact, empty phrase. I don’t care what magic you think you have; you are never going to eliminate the need to operate your software, applications and infrastructure.

    I first heard the term NoOps early in the maturation curve of DevOps. Back then, the idea seemed to be that Dev was going to absorb Ops. Between that and the cloud, there really wasn’t a role for traditional Ops to deploy. Managing apps would be easy with the cloud and automation. At least, that was the pie-in-the-sky thinking—but I never bought that.  

    There were other terms that popped up, like NewOps and AIOps, though that became something else entirely. But really, I think the rise of the systems reliability engineer (SRE) role put the NoOps movement in its grave (where it probably belonged). SRE became the shiny new identity of the Ops crowd and SRE continues to be one of the most popular topics here on DevOps.com.

    This latest incarnation of NoOps seems to be a little different. From what I have seen, it is not really NoOps; instead, it is more of a “not your Ops to worry about” movement. It is shifting who is responsible for Ops from the company developing and using the apps to a service provider (or SaaS provider) who is responsible for Ops. It is more a “MyOps” not “YourOps” movement, but there is still most certainly an Ops there.

    In my neighborhood growing up, we used to have a saying, “I don’t care what you call me, just don’t call me late for dinner.”  Originally, to me, NoOps was very much like that. We changed the name of something, but it didn’t go away or fundamentally change the thing itself.

    Now, we still have Ops, it is just a question of who is doing it. That is not NoOps to me. It is “somebody is doing MyOps for me.” 

    We saw a similar pattern in security. The idea of outsourcing security was never called “NoSec,” because the idea of no security is, frankly, downright scary. Instead, it just meant relying on a cloud vendor or an MSSP to handle your security for you; it was outsourcing your security. An important lesson learned from that was that you can outsource your security ops, but you can’t escape your security responsibility. That is to say, when your customers’ information is breached, saying “We had someone doing this for us!” did not absolve you of responsibility.

    The same thing holds true for this new “OutsourceOps.” The outsourcer may do a better job than you at Ops. They may give you SLAs and SLOs that give you reasonable expectations of performance and remedies if those SLAs and SLOs are not met. But it is still your company’s name and reputation on the line.

    So is what we seeing as NoOps really NoOps? No, it is Outsourced Ops. But as we said in the old neighborhood, I don’t care what you call it, just don’t call it late for dinner.

  • Everything is DevOps

    Everything is DevOps

    It’s funny how we in IT tend to be absolutists, shoving everything into the current bucket. XML was going to eliminate programming—even though it wasn’t even particularly good at data representation. NoCode was going to eliminate programming (yeah, that’s a theme, I’ll skip the other 50 or so ‘going to end programming’ cycles we’ve been through), AI will eliminate IT, you must have a mobile app, even if no one will ever use it, my OS/browser/language is better than yours and will win—you get the idea.

    We’re currently coming to the end of the “Everything is DevOps” phase. DevOps is a great methodology that helped solve several intractable IT problems but, like everything, marketing and a ton of smart people that want to be “right” have taken it too far. Or have they?

    The thing with DevOps is that contrary to what those who try to make a separate market out of DevSecOps or SRE try to tell you, it was designed to literally encompass all of human IT activity. We can excuse the DevSecOps crowd, since DevOps’ roots had a definite “Security is an unimportant bottleneck” feel to it. The SRE crowd, on the other hand, appears to be another case of “my silo is special”. Or, better yet, a stompy marketer saying “We’re late to the DevOps game! Let’s invent something just like it, claim we do it more broadly and give it our own name!”

    Let’s look at what each does, for those of you who are skeptical. 1) break down silos. Check. 2) Monitor everything. Check. 3) Use monitoring results to improve product performance and stability. Check. 4) Design and implement products and product features. Check. There’s more, but you get the idea.

    Do you know what all of this ignores? You.

    One of the issues that our absolutism brings about is that marketers get to dictate what is important. Sometimes that is what enterprise IT needs. Far too often it is what the marketer is paid to dictate.

    I don’t care if you call it DevOps or SRE, I care that your organization feels like it is getting its money’s worth out of IT—something, I might add, that most organizations did not feel prior to DevOps. At least most of the ones I dealt with. I even had a job where they created a whole new department and hired me to run it to “get around those people in IT.” I spent as much time educating business leaders about not duplicating entire groups like storage services and InfoSec as I did building and deploying new products. So avoiding that kind of issue is near and dear to my heart. And we’re more ‘there’ than we have ever been.

    I do care about whether you call it DevSecOps or not. It should not be different. Shifting security left is the appropriate solution to the double-edged sword of security staffing shortages and increased adversary capabilities. So if your developers are getting secure coding feedback in their IDE or each time a build is kicked off, great! But call it DevOps. Say it is part of the DevOps process. Same with configuration reviews like cloud configuration management—it’s just part of the DevOps process, not a security step to be thought of differently.

    I could go on, but hopefully I’ve spurred your imagination a bit and don’t need to.

    You rock. Streamline your thinking to streamline your processes, ignore absolutism and call it macaroni for all it matters. Just keep doing what needs doing—at the most convenient place to do it. And keep developing, deploying and monitoring the systems that keep the company running.

     

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    CapitalOne

    Annapolis

    Director of Software Engineering – Risk Management and Compliance

    $190,000

    Dice.com

    Nigel Frank International

    Remote

    Senior Azure DevOps Consultant

    $165,000 per year.

    Indeed.com

    ROM Technologies

    Brookfield, Conn.

    DevOps Engineer

    $120,000 per year.

    SimplyHired

    Comcast

    Philadelphia, Penn.

    Senior Engineer Cloud Infrastructure

    $109,932 – $164,898.

    Monster.com

    Target

    Remote

    Lead Engineer – High Performance Distributed Computing

    $105,800 – $190,500

  • F5 NGINX Delivers Modern Management Platform

    F5 NGINX Delivers Modern Management Platform

    F5 NGINX has revamped an implementation of its management suite as part of an effort to make the platform both more accessible and simpler to use.

    Eric Braun, vice president of product management for F5 NGINX, said NGINX Management Suite 1.0 is based on a modular platform that makes it possible to dynamically scale instances of NGINX proxy software, application delivery services, application programming interface (API) management workflows and the company’s security offerings.

    That approach makes it possible to automate the deployment of F5 NGINX software without relying on manual processes that are prone to misconfiguration, Braun noted.

    The platform is based on a modern architecture that also makes it possible for administrators to enable development teams to self-service their own requirements within the limits of a set of policies defined via a portal, he added.

    The NGINX Management Suite replaces NGINX Controller, a more monolithic platform that is not based on an API-first approach to managing services, said Braun.

    The core modules of the NGINX Management Suite are an Instance Manager for the open source and commercial instances of the company’s proxy software, an API Connectivity Manager, App Delivery Manager and an App and API Security module. NGINX Management Suite will enable organizations to use NGINX App Protect Web Application Firewall (WAF) to protect applications and APIs while the App Delivery Manager module will be extended to enable configuring, securing, monitoring and troubleshooting of NGINX Plus when used as a load balancer.

    The revamp of the NGINX management plane is the latest in a series of efforts to modernize application and IT infrastructure management using a microservices-based platform that more easily scales as more resources are required. The more modular approach also gives IT teams more granular control over how various modules are accessed.

    It also makes it simpler for IT teams to deploy, for example, a service mesh or API gateway without having to add additional management platforms, noted Braun. That capability should significantly streamline the process of deploying those platforms because the need for a dedicated platform to manage them has been eliminated, he added.

    It’s not clear to what degree that latter capability will enable IT organizations to shift responsibility for managing various tasks further left toward application development teams. However, it is clear application development teams want to be able to self-service their own IT requirements and make services available without intervention from a centralized IT organization. In effect, IT organizations are trying to strike a balance between the benefits of centralization and the need to build and deploy applications faster within the context of a DevOps workflow.

    It may be a while before most IT organizations are able to consistently strike that balance. In the meantime, however, as IT management platforms continue to be modernized using APIs it should also become easier to integrate them. It will be up to each IT organization to then decide how many management platforms are going to be required, but at the very least, the various management silos that make up an IT environment today are finally starting to break down.

  • Postman Survey: Increased Usage of APIs Results in More Security Incidents

    Postman Survey: Increased Usage of APIs Results in More Security Incidents

    A survey of more than 37,000 developers and application programming interface (API) professionals published this week by Postman, a provider of a platform for developing and managing APIs, suggests that as more APIs are deployed, more organizations are seeing a rise in cybersecurity incidents.

    The survey finds more than half of respondents (51%) reporting that more than half of their organizations’ development effort is spent on APIs. About 20% also noted they are responding to API security incidents or breaches at least once a month at their organization. Overall, more than half (52%) said API security incidents occur less than once a year.

    Kin Lane, chief evangelist for Postman, said that while a lot of the concerns over API security could be classified as “theater” being put forth by providers of API security platforms, it’s clear there is a need for a zero-trust approach to building, deploying and maintaining APIs.

    The bulk of APIs are used primarily to interconnect internal-facing applications and systems, with a subset then used to integrate partners. Only a comparatively small percentage of APIs are externally facing. However, Lane noted many organizations fail to appreciate how quickly an internally facing API can become externally facing over the course of its lifecycle. As such, IT teams need the tools and platforms required to manage and secure APIs as they evolve, he noted.

    In fact, nearly three quarters of respondents (72%) said being able to build APIs remotely is very important to them. That would suggest best DevSecOp practices will need to be extended to API development teams that are often working from home.

    Despite those concerns, however, a full 89% said Investments in APIs will increase or stay the same over the next 12 months to drive, for example, digital business transformation initiatives. However, the survey also suggests most organizations are still coming to terms with API development and deployment. Only 8% of respondents identified themselves as API-first leaders, which Postman identifies as an elite group that produces APIs faster, deploys more often, has fewer failures and recovers sooner when failures occur.

    Lane said the survey makes it clear that while APIs are playing a crucial role in advancing business goals, there is a need for increased visibility as more APIs are deployed across the enterprise. That’s especially critical as more types of APIs employed also continue to expand. Most APIs in use today are based on the REST format, but there are also now APIs based on GraphQL, event-driven architecture and various messaging platforms. None of these newer APIs are going to supplant REST APIs any time soon. Rather, they are being applied to drive additional processes alongside REST APIs, noted Lane.

    It’s not clear how many organizations are adopting a design-first approach to building APIs before they write application code, but as more APIs are deployed, the way IT is managed is rapidly changing. Application services are essentially becoming more disposable so long as the API used to expose them to other applications remains stable. In fact, it’s now only a matter of time before most organizations fully appreciate the degree to which their entire IT strategy now revolves around their APIs.

  • Agile Sucks (Redux) | Plus: DevOps on Mars

    Agile Sucks (Redux) | Plus: DevOps on Mars

    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: Agile is bad, but “Wagile” is worse.
    Plus: This prod is even worse than yours. (more…)

  • Survey Shows Steady DevSecOps Progress

    Survey Shows Steady DevSecOps Progress

    A survey of 200 DevOps and IT/information security professionals published this week by Mezmo, a provider of an observability platform, conducted in collaboration with the market research firm Enterprise Strategy Group (ESG), finds only 22% report their organization has a formal DevSecOps strategy to integrates security into their software development lifecycle (SDLC) processes.

    Among those that have adopted best DevSecOps practices, however, 60% saw an acceleration in incident detection, while 53% saw a reduction of incidents in production environments.

    Overall, the survey finds 62% of respondents report their organization is actively evaluating use cases for, or has plans to implement DevSecOps.

    Mezmo CTO Rob Fry said the primary challenge organizations face when it comes to DevSecOps remains cultural. In fact, 99% of survey respondents said establishing a culture of collaboration between development and cybersecurity teams is either critical (51%) or important (48%). Building cross-functional DevOps teams that have the required level of security expertise, however, is a major hurdle when there is a general shortage of cybersecurity expertise, noted Fry.

    The survey finds that on average it takes 17.5 person hours to triage and understand security incidents, an amount the survey finds that 82% of respondents desire to reduce.

    However, organizations are also struggling with the sheer volume of data collected by DevOps teams. More than half the respondents (52%) said the variety of data to be captured, analyzed and be acted on throughout the software development lifecycle (SDLC) hinders security efficacy/efficiency. A total of 43% said the scale of data to be captured, analyzed and acted on throughout the SDLC also hinders security efficacy/efficiency.

    Organizations surveyed capture several (54%) or even hundreds (32%) of terabytes per month, with 6% capturing a petabyte or more per month. Well over two-thirds (69%) do not capture certain data sources because of the high cost of storage/retention, which Fry noted is going to be problematic if there is an incident. Log data (35%), followed by metrics (29%) and traces (22%) account for most of that data, the survey finds.

    In all, 84% of respondents said getting the right data and tools to developers is key to achieving success. A full 91% of respondents are using multiple tools to get the most value out of their data. Two-thirds (66%) have dedicated logging analysis tools, while 59% have a security information event management (SIEM) platform. Cloud to two-thirds 64% have a data lake hosted in the cloud, while 55% have one in an on-premises IT environment.

    A full 87% are using open source tools as part or all of their observability stack because they are more customizable. However, 84% noted that over time it will become challenging to manage, adapt and scale with these solutions. Nearly all survey respondents (98%) said they will likely investigate a managed observability solution over the next 12 months.

    The application security issues that plague organizations today have been around for decades, so it’s not likely they will be resolved in a few short weeks. On the plus side, at least, there’s now a lot more awareness of the root cause of the problem than ever.

  • Civo Report Surfaces Growing Cloud Lock-in Concerns

    Civo Report Surfaces Growing Cloud Lock-in Concerns

    A survey of 100 IT professionals conducted by Civo, a provider of cloud services based on Kubernetes, finds a total of 82% currently rely on either Amazon Web Services (AWS) or Microsoft for public cloud infrastructure. However, more than a third (34%) of respondents also report they now feel locked into the public cloud service provider.

    The primary reason survey respondents cited for feeling that way is data transfer costs are too expensive to move off their current cloud (65%).

    Simply inertia also seems to be a factor. A third of the total respondents (33%) said they had always used the same cloud service provider. Nearly two-thirds (62%) also noted they were concerned that alternative cloud providers would suffer more outages. At the same time, however, 45% of respondents conceded they are under growing pressure to reduce cloud costs.

    Civo CEO Mark Boost said it’s already apparent that cloud outages are not just limited to alternative cloud providers. In fact, most application workloads are relatively simple in the sense they can run equally well with the same level of resiliency on any number of cloud services at a lower cost than the major hyperscalers currently charge, he noted.

    In effect, cloud computing, except for some more complex workloads, should largely be viewed as a commodity, added Boost.

    Cloud service providers, of course, discourage migrations using exorbitant data egress charges that often make moving data off their platforms cost prohibitive. In fact, most applications are deployed on a single cloud versus in a truly hybrid cloud model because data management can become exceedingly complex. Ideally, IT organizations would like to be able to play one cloud service provider off another to reduce costs. In practice, however, once an application is deployed, it rarely moves to another platform.

    On the plus side, however, microservices-based applications deployed on Kubernetes clusters are easier to move because each instance of a Kubernetes cluster exposes a consistent set of APIs. However, stateful applications deployed in Kubernetes environments can like any other application become dependent on, for example, a proprietary database.

    The tradeoff, of course, is that each cloud platform added to an enterprise IT environment tends to increase total costs. IT staffs typically need to hire additional specialists that require tools to manage each cloud. There are, naturally, platforms that span multiple clouds but the cost of acquiring, provisioning and maintaining those platforms can be considerable. In the meantime, more organizations find themselves separately managing and attempting to secure multiple clouds simply because individual departments prefer one cloud service versus another.

    It’s not clear to what degree organizations may soon decide to consolidate cloud workloads as part of an effort to reduce costs. However, a lot of workloads in the immediate aftermath of the COVID-19 pandemic were shifted to the cloud with little regard for cost. Now that organizations are adjusting to the so-called new normal, many of those decisions are, at the very least, being re-evaluated to see what might make the most financial sense as the general economy seems to become less predictable with each passing day.