devopsy.kinsta.cloud

Tag: application lifecycle management

Salesforce vs Dynamics 365 CE DevOps: A Practical Comparison for Enterprise Teams

Most organizations running CRM platforms eventually face the same challenge: how to deploy changes safely, consistently, and quickly. While Salesforce and Dynamics 365 Customer Engagement (CE) support modern DevOps practices, they approach application lifecycle management differently. Understanding these differences can help teams design more effective deployment pipelines and avoid common release issues. As these platforms become increasingly critical to business operations, the need for effective DevOps practices has grown significantly.

Unlike traditional software applications, CRM platforms combine configuration, metadata, security models, workflows, integrations, and custom code into a single ecosystem. A deployment rarely consists of code alone. It often includes business processes, user interface changes, security updates, automation rules, and integration modifications. This creates a unique challenge for DevOps teams. A seemingly small change can affect multiple business functions across departments. A modified field may impact reports, workflows, integrations, security permissions, and user experience simultaneously.

As organizations expand their CRM footprint, managing these interconnected components becomes increasingly difficult. This is where mature DevOps processes become essential.

Salesforce: Metadata-Driven Deployments

Salesforce is one of the most widely adopted cloud platforms for customer relationship management and business process automation. As organizations build increasingly complex applications on the platform, DevOps practices have become essential for managing changes efficiently and maintaining system stability.

Salesforce development revolves around metadata. Nearly every customization within the platform can be versioned, tracked, and deployed as metadata.

Business logic is distributed across numerous components including Apex classes, Lightning Web Components, Flows, Validation Rules, Permission Sets, Custom Objects, and Profiles. These components collectively form the application landscape. This architecture provides significant flexibility but also introduces complexity. Dependencies are often spread across multiple metadata components, making it difficult to fully understand the impact of a change before deployment. For example, a modification to a custom field may affect Apex code, automation flows, reports, validation rules, integrations, and user interfaces. While deployment tools can identify technical dependencies, they cannot always predict business impact.

As Salesforce environments grow, managing metadata relationships becomes one of the primary responsibilities of DevOps teams.

Dynamics 365 CE: Solution-Based Deployments

Dynamics 365 Customer Engagement (CE) is a cloud-based business application platform that helps organizations manage sales, customer service, field operations, and customer interactions. As businesses increasingly customize and integrate the platform with other enterprise systems, DevOps practices play a critical role in ensuring reliable deployments and maintaining application stability.

Dynamics 365 Customer Engagement follows a different model. Instead of deploying individual metadata components, organizations typically package changes into Solutions.

A Solution acts as a container that groups related customizations including tables, forms, views, plugins, business rules, security components, model-driven applications, and Power Automate integrations. This packaging model provides a structured deployment mechanism that many enterprise teams appreciate. Rather than moving hundreds of individual components, teams can transport business functionality through managed solutions. However, Solutions introduce their own challenges. Solution layering, dependency management, and managed versus unmanaged customization strategies require careful governance.

In large organizations, troubleshooting deployment issues often involves understanding how multiple solution layers interact with each other. While this approach offers strong packaging capabilities, it can also create complexity when multiple teams contribute to the same environment.

Source Control and CI/CD

Source control and CI/CD form the foundation of modern DevOps practices. By maintaining a single source of truth for application changes and automating deployment processes, teams can improve release consistency, reduce manual errors, and accelerate software delivery.

Both platforms support Git-based development and automated deployment pipelines. Salesforce generally provides greater visibility into individual component changes because metadata can be tracked independently. Dynamics 365 CE focuses more on solution packaging, which can make source control management slightly less granular. From a CI/CD perspective, both platforms integrate well with GitHub and Azure DevOps. The biggest difference is not tooling but deployment philosophy: Salesforce moves metadata, while Dynamics moves solutions.

Testing and Release Quality

Testing remains a critical component of any DevOps strategy. Salesforce requires Apex tests to be executed before deploying custom code to production, creating a built-in validation mechanism that helps reduce release risk. Dynamics 365 CE provides greater flexibility, allowing organizations to define their own testing and validation processes. Regardless of platform, automated testing and release validation help improve deployment confidence and reduce production issues.

Conclusion

After working with both platforms, one lesson becomes clear: most deployment failures are not caused by the platform itself.

Problems usually stem from inconsistent development practices, insufficient testing, poor source control discipline, or unmanaged environment changes. Teams that establish strong DevOps fundamentals—version control, automated deployments, testing standards, and clear governance—tend to achieve successful outcomes regardless of the CRM platform they use.

For practitioners, the most important factor is not choosing the “better” platform. Each platform presents unique challenges, but both can support reliable and scalable enterprise delivery processes when backed by strong DevOps practices. Success depends on implementing consistent DevOps practices that reduce risk, improve release quality, and support long-term scalability.

June 23, 2026
LeanIX Extends Application Management Reach

LeanIX today unveiled a catalog that enables DevOps teams to more easily track the relationships between microservices as they are built and deployed.

At the same time, the company also revealed it has acquired Cleanshelf, a provider of a platform for managing software-as-a-service (SaaS) applications.

LeanIX CEO André Christ said the Microservice Intelligence catalog will make it simpler for IT organizations to keep track of their ongoing software development efforts, while Cleanshelf provides the mechanism for centralizing management of SaaS applications that are now widely employed across the enterprise.

The Microservice Intelligence catalog is the latest addition to the LeanIX Continuous Transformation Platform used to manage enterprise applications. It automatically captures and correlates metadata being generated across disconnected toolchains, pipelines and Kubernetes clusters to create a 360-degree view of microservices and their dependencies, said Christ.

In addition to being integrated with the LeanIX Enterprise Application Suite, Microservice Intelligence comes with out-of-the-box connectors for Kubernetes, Jenkins, GitHub Actions and Red Hat OpenShift platforms.

By monitoring deployment frequencies, mean-time-to-recovery (MTTR) and failure rates, Christ noted it will become easier to make software engineering decisions based on data and insights surfaced via the Microservice Intelligence catalog. DevOps teams can also annotate the microservices recorded by the catalog to provide additional information, Christ added.

The Microservice Intelligence catalog provides the added benefit of making it easier to onboard new developers, said Christ. Each new member of a development team can, on their own, explore the overall application environment without requiring an IT team to dedicate someone to describe it each time a new member of a DevOps team is hired, Christ noted.

At the same time, other stakeholders, such as cybersecurity teams, can explore the application environment to better understand dependencies as well as the potential impact of a newly discovered vulnerability, Christ added.

In general, Christ said, as application life cycle management across the extended enterprise becomes more complex it’s clear new platforms will be required to manage legacy monolithic applications, emerging microservices-based applications and SaaS applications that, in the wake of the COVID-19 pandemic, are being used to enable employees to work from home. The Cleanshelf platform, in particular, will be rebranded as LeanIX SaaS Intelligence to address that latter issue. A SaaS discovery and cataloging capability will also be made available as a free component of the LeanIX Application Portfolio Management module in the second quarter.

IT environments have never been more distributed, and it’s clear most organizations are under pressure to reduce the total cost of IT by centralizing management functions. It’s too costly to dedicate a management platform for each type of application deployed across an extended enterprise. LeanIX is making a case for a platform that enables IT organizations to finally centralize the management of application environments.

It’s unclear at what rate that centralization may occur, given the level of inertia that exists within most IT organizations today. However, as application lifecycle management continues to evolve, the centralization of the management of application portfolios that continue to grow is all but inevitable.

March 24, 2021
How to Synchronize Jira Projects Between 2 Jira Instances
Most of us are aware that Jira is a highly regarded application lifecycle management tool. One of its main features is team collaboration. Sometimes, however, collaboration between a business team and its partners can pose a challenge due to their network restrictions.

In this article, we will see how this problem can be addressed and the available options.

Jira Business Case

As an external partner, we supported an embedded system customer who already was using Jira for its internal users. During that time, the customer had tight security measures in place and its IT team was unable to grant us access to its systems and tools; instead, we had to use a customer-provided laptop with VPN connectivity. This setup wasn’t efficient and led to more investment and procedures to follow when a new external user needed access, so we set out to find an alternative solution to run the business more effectively with good collaboration with everyone through the Jira portal.

Many vendors have addressed this problem with automatic synchronization as a Jira plugin.

Some of those plugins are:
- Backbone Issue Sync.
- Exalate Jira Issue Sync.
- Issue sync – Integration for Jira.
This article takes a look at Backbone Issue Sync and how the synchronization of Jira projects can be done between two instances.

Backbone Issue Sync

Backbone Issue Sync helps users synchronize Jira projects, enabling collaboration across departmental and B2B borders. Its setup and configuration are very simple compared to other plugins.

Backbone Issue Sync is a paid plugin developed by the K15t Group. It is available in the Atlassian marketplace.

This plugin supports the following Jira versions:
- Jira Cloud.
- Jira Server from 6.2–8.6.1.
- Jira Data Center 6.3–8.6.1.
Key Features:
- Automatic bi-directional issue synchronization between Jira projects.
- Control issue, comment, field and attachment mapping.
- Map workflows.
- Uses JQL to define issue syncing, filters and limits.
- Sync comments and attachments.
- Defining workflow mapping and specifying distributed responsibilities.
- Simple setup, configuration and admin UI.
- Performance, reliability and scalability proven by enterprise installations.
- Full privacy and security control.
- Synchronization of data via HTTP(S), file and email.
- In-product troubleshooting support available.
- Partners/vendors can sync unlimited projects and issues.
Let’s consider we have a business team and external partner where they want to work together in a Jira issues on daily basis but they have a network restriction between each team.

In this case, we need to set up a separate Jira instance and create a project with the same name on both sides.

Prerequisites:
- Install Jira on both sides.
- Create a Jira project with the same name in both Jira instances.
- Create a Jira user named “syncuser” on both instances.
- Grant “syncuser” Jira permission to Browse Projects, Create Issues and Edit Issues.
Establish a Connection Between the Projects
1. Open the Jira Project in the first Instance, then select Project Settings > Issue Synchronization > New Synchronization. To make things simple, select Centralized Configuration (this is Backbone’s ‘default’ synchronization type and is recommended for most use cases).
2. Set up the synchronization:
  1. Enter the base URL of your Jira in the first Instance and the base URL of the external partner’s Jira URL in the second Instance.
  2. In the Sync User field, enter the synchronization user’s username (in this example, that’s syncuser).
  3. In the Password field, enter the synchronization user’s password.
3. On the next screen, select which project you want to synchronize with. Select the same project name in both instances.
4. Next, assign the synchronization a name and description. When you create multiple synchronizations for a Jira project, descriptive naming is important to avoid confusion. For now, we will go with default values.
We have established the connection between Jira projects of two different instances. Now, let’s configure what are all the data will be synchronized between the projects of each instance.

Configure Synchronization Settings
1. In the below step, we’ll configure the synchronization data, telling Backbone what data it should synchronize between the projects of two instances.
2. Click … > Configure to go to the configuration UI:
3. Click the Edit Configuration button to start configuring.
4. On the Issue Types tab, click Start with simple mappings and select an issue type to synchronize in both directions between two instances of Jira projects.
5. Now, map which fields should be synchronized at Fields – Mappings > Start with simple mappings.
  1. Enable the checkbox for Summary and Description field and click Create.
  2. Click the Publish Draft button to save the configuration, then select Start to start the synchronization.
Synchronization with Backbone Issue Sync is now configured.

Let’s verify the synchronization:
1. Create a new issue with type Task in the first instance and enter some content in the Summary and Description fields.
2. Open the Jira Project in the second instance: You should see that the issue has been synchronized.
3. Open the synchronized issue and edit the summary and description in the second instance.
4. Go back to the issue in the first instance: You should see the edits have been synchronized.
Conclusion

Backbone Issue Sync helps overcome the challenge of collaboration between a customer and external partners over a restricted security network. Using this plugin, many highly secured business teams are able to collaborate effectively without issue.
July 2, 2020
Survey Finds IT More Challenging to Manage Than Ever

A survey of 415 IT executives published today shows IT teams are struggling to keep up as the number of platforms that need to be managed continues to expand rapidly.

Conducted by Propeller Insights on behalf of Volterra, a provider of a distributed computing platform, the survey finds 97% are planning to distribute workloads across two or more clouds. The top three reasons cited for adopting multiple clouds were the need to maximize availability and reliability (63%), meeting regulatory and compliance requirements (47%), and leveraging best-of-breed services from each provider (42%).

At the same time, the survey finds 70% of survey respondents said it’s “very important” to have a consistent operational experience between the edge and public and private clouds.

The survey, however, also makes it clear IT leaders understand that achieving the goal will be a significant challenge. The top issues identified when employing multiple clouds are establishing secure and reliable connectivity between providers (60%), employing different support and consulting processes (54%) and navigating different platform services (53%).

The rise of edge computing is going to further exacerbate those challenges. The survey finds the difficulty in managing apps across multiple edge locations (44%) and an inability to accommodate the IT infrastructure needed to host and operate at the edge (38%) as the two major edge computing issues identified by survey respondents. In terms of specific technical challenges identified, integrating cloud-native workflows such as automation, continuous integration/continuous delivery (CI/CD) and performance management (69%) and trouble installing a full set of application infrastructure spanning compute, storage and network and security (67%) top the list of issues.

As far as lifecycle management at the edge is concerned, the two biggest long-term issues identified are the lack of resources or time to keep applications and infrastructure up to date (37%) and managing silos of distributed clusters (26%).

Mark Weiner, chief marketing officer for Volterra, said the survey makes it clear there soon will come a day when IT organizations will need to centralize the management of an increasingly extended enterprise. IT organizations may have adopted public clouds aggressively, yet 70% to 80% of all workloads still run in an on-premises IT environment. At the same time, the number of workloads that will be distributed to edge computing platforms is set to explode. The survey identifies the primary reasons more workloads will be deployed on the edge as the need to control and analyze data locally (54%) and the amount of latency experienced when sending edge data to public cloud-based apps (47%).

Ultimately, the goal is to have a hybrid cloud computing environment through which the management of IT is as centralized as possible. While the cost of deploying workloads in a public cloud is comparatively inexpensive, it turns out the total cost of IT continues to increase as IT teams find themselves managing more distributed platforms than ever. It may be a while before IT teams have the tools and processes in place to rein in those costs. However, at this point, it’s more a question of how and when that goal will be accomplished, not if.

— Mike Vizard

March 9, 2020
LightStep Adds Regression Monitoring to APM Platform

LightStep this week announced it has added a Service Health for Deployments module to its namesake observability platform designed from the ground up for microservices and serverless computing frameworks.

Talia Moyal, senior product manager for LightStep, said Service Health for Deployments will make it possible for DevOps teams to monitor performance regressions both during and after an application is deployed.

DevOps teams can also take advantage of aggregate trace analysis functionality such as latency histogram comparisons, operations diagrams and an automated correlation engine for performing rapid root cause analysis to understand why a regression is occurring.

Finally, a built-in instrumentation scoring capability enables DevOps teams to compare performance before, during, and after a deployment; compare latency across instances to estimate the size and scope of a regression; correlate tags that have the biggest impact on latency; and map critical path latency for each operation or service.

As organizations embrace microservices and serverless computing frameworks, the overall IT environment becomes more complex to manage. As an application performance management (APM) platform, LightStep makes use of OpenTelemetry software to gather metrics that are then fed into a statistical engine to detect anomalies, which the APM can then record and replay. By employing OpenTelemetry, LightStep is able to employ distributed tracing to surface more context than traditional APM tools, said Moyal.

Given the costs involved in employing APM platforms, most IT organizations historically have limited their use to their most critical monolithic applications. However, the dependencies that exist between microservices and serverless computing frameworks that make up a modern cloud-native application are now requiring IT organizations to apply APM platforms more broadly. In fact, observability is a core principle of best DevOps practices that many organizations are embracing more widely as they build and deploy cloud-native applications. Many of those applications will run just fine when initially deployed, but over time performance can degrade for a whole host of reasons that span everything from increased storage access latency to too many calls being made to the same application programming interface (API).

Of course, there is no shortage of options when it comes to APM platforms. LightStep is making a case for OpenTelemetry because it provides a single set of open source APIs, libraries, agents and collector services to capture distributed traces and metrics. That approach makes it easier for developers to instrument their applications in a way that allows platforms such as LightStep to surface more insights into application performance. LightStep claims it has already employed that approach to analyze more than 1.4 trillion traces. OpenTelemetry is currently being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

It’s too early to say to what degree traces will supplant traditional sampling methods to analyze application performance. The one thing that is certain is as developers are held more accountable for application lifecycle management, many of them are demanding access to more sophisticated APM tools to provide the visibility they require to resolve application performance issues faster.

— Mike Vizard

January 30, 2020
CollabNet Merges with VersionOne for ALM Supremacy

Thanks to the rise of DevOps, there has been a lot of focus on various forms of application lifecycle management (ALM) spanning multiple application development methodologies. But as IT organizations become more comfortable with multiple methodologies, it turns out they are not replacing one with another as much as simply trying to figure out where to employ one over another. That, in turn, is driving some consolidation across the ALM category.

CollabNet this week announced it is merging with VersionOne, a provider of an ALM framework optimized for agile application development. While CollabNet has made some forays into the space, historically its primary focus has been on waterfall methodologies commonly used across larger enterprise IT organizations. CollabNet CEO Flint Brenton says the goal now is to combine the best of the ALM tools provided by both companies to enable IT organizations to leverage agile and waterfall methodologies as they best see fit. In fact, he says the biggest ALM issue facing organizations today is the need to balance developing applications faster and the inherent risks associated with potentially moving too quickly.

Robert Holler, formerly the CEO of VersionOne, will assume the post of chief strategy officer for the combined company. He says there’s very little overlap between the two company’s product portfolios, and the one thing that will distinguish CollabNet going forward is an open approach to ALM that enables organizations to employ whatever tools they prefer. Instead of forcing organizations to rip and replace those tools, Holler says ALM frameworks need to foster collaboration rather than trying to impose a closed ALM environment. That environment also needs to be deployable on-premises or in the cloud, depending on the requirements of the customer.

Holler notes that once any segment of the IT industry reaches a certain level of maturity, consolidation is all but inevitable. The opportunity CollabNet has is providing an ALM environment that makes it possible to automatically package and deploy applications that includes strong version-control mechanisms. Those capabilities will become even more critically important as IT organizations expand usage of microservices based on, for example Kubernetes, alongside traditional virtual machine deployments across the enterprise. Accomplishing that goal will require a common management layer capable of spanning both environments, he says.

The combined companies have more than 20,000 customers. That number may not collectively represent the lion’s share of the ALM market, but it does make CollabNet a serious contender against a host of rivals that are both a lot older and larger. CollabNet’s challenge now is convincing customers of competitive organizations to switch to an ALM platform that CollabNet contends is a whole lot more flexible.

In the meantime, it’ll be interesting to wait and see if the combination of CollabNet and VersionOne will drive any additional acquisitions at a time when IT organizations are becoming a lot less religious about what type of application development methodology gets employed by who and when.

— Mike Vizard

August 10, 2017
Top Reasons to Use Node.js

When considering the architecture of a new web app, it might be a good idea to include Node.js in the discussion as a key part of that architecture. Node.js could provide you with additional speed, can be used on numerous platforms and has an active community from which to get modules and other assistance.

What is Node.js?

Node.js is a server-side platform developed by Ryan Dahl in 2009. It was built on Chrome’s V8 JavaScript engine and designed with a non-blocking, event-driven I/O. It is also cross-platform, able to be run on Windows, Linux and OS X. Its non-blocking I/O is due to its use of asynchronous functionality, which keeps the server from waiting on data to be returned before being able to move on to other tasks.

Why Use It?

Given the architecture of Node.js, a number of advantages are provided both to developers and the resulting apps they develop. A few of these advantages include speed, programming language consistency, real-time apps developed easily and a large number of modules/packages for developers to use while creating new apps.

Speed

Node.js offers speed advantages in many cases. First, it uses the Google V8 engine, which is optimized for JavaScript speed. Also, its use of non-blocking asynchronous behavior can ease the time it takes for users to see actions as complete, since things can be going on in the background while the user moves on to other tasks.

One Language

JavaScript is listed as the most popular programming language. Source: Thenewstack

Using Node.js, front-end and back-end code can both be in JavaScript, so your developers don’t have to transition between languages as they move through the stack. Some architectures, such as the MEAN stack (MongoDB, Express.js, Angular.js, Node.js), are designed around this principle. In this case, the stack uses JavaScript for Express, Angular and Node. MongoDB uses BSON for database queries, which uses the same syntax as JSON (JavaScript Object Notation).

Seeing full-stack developer as the largest occupation and JavaScript as the top language among both back-end and front-end aligns with what we’ve been seeing in overall JavaScript adoption.

Source: Mikeal Rogers, Node,js Foundation Community Manager

For developers, this can help both with moving across the stack during development as well as help communication among developers, as they will be referencing the same language (JavaScript) while discussing programming decisions.

Real-Time Apps

Node.js is a great platform for creating real-time apps. With a module such as Sockiet.io, you can create real-time chats, games and more. Along with its non-blocking asynchronous architecture, real-time apps can be developed with plenty of speed and responsiveness.

Modules

The Node Package Manager (NPM) makes it easy to install packages that others have developed to perform any number of tasks. This helps to encourage code-sharing among developers and to reduce the amount of custom development that has to be done when one or more packages can take care of that coding for you.

Notable Examples

Some notable examples of Node.js use are Paypal and Uber, showing that it can, indeed, be useful for large projects.

Paypal

Node.js and an all Javascript development stack helped PayPal bring efficiencies in engineering and helped rethink and reboot product, design and operational thinking.

Source: Sameera Rao, Paypal Sr. Business Products Engineering Manager

Back in 2012, Paypal had a single app running all things, including UI, API and more. This included a lot of duplicated code that was copied and pasted from one app to another to make apps for different locations.

Using Node.js, the company was able to modularize and clean up its code and processes, which in turn sped the development of apps it needed at any given time.

According to Paypal’s engineering team, they were able to build the Node.js app with 33 percent fewer lines of code and 40 percent fewer files, and were able to build it twice as fast and with fewer people than before. Certainly, Node.js proved to be advantageous to their development.

Uber

Uber used Node.js from the beginning, and its distributed system was a perfect fit, since a lot of network requests are made. The non-blocking asynchronous I/O used by Node.js helped to ensure those requests could be made and handled quickly to provide the best service possible.

Conclusion

The benefits of Node.js have been proven. It helps speed development, can be used on numerous platforms and has an active community from which to get modules and other assistance. Include Node.js in your future conversations about website architecture.

— Brian Wheeler

January 4, 2017
Walmart OneOps Won’t Be One-Upped
One of the biggest names in retail also is kind of a big deal in DevOps. Walmart has developed its own platform, OneOps, designed to streamline operations and keep its application development schedule in check.

“OneOps is an open source cloud and application lifecycle management technology platform with benefits including cloud portability so developers can seamlessly move applications, databases or entire cloud environments from one cloud provider to another,” says Brian Johnson, VP of Engineering, Platform, Walmart Labs. The latter feature allows developers to leverage the broad selection of cloud environments and pricing schemes to their advantage.

The OneOps platform deploys Walmart website adds/changes, launches new mobile features such as Walmart Pay, and creates APIs so third parties such as Hiku can tap into Walmart’s online grocery offerings, at speed and with a lower investment in the cloud, says Johnson. The OneOps platform once only managed the Walmart.com e-commerce site, but now it also serves individual Walmart stores and supports other initiatives.

According to Johnson, OneOps undergirds and empowers the work of developers as follows:
- OneOps continuous lifecycle management continuously auto-pilots the process of automating application scaling and repair whenever any unforeseen changes take place.
- OneOps promotes accelerated innovation so software engineers can spin up new environments for app hosting in minutes, since the DevOps platform skirts the need to specify the intricate details of any one cloud environment by modeling that for the developer.
- This abstraction of the cloud environment gives developers control over the tools and technologies they select regardless of the cloud provider they use.
Life Before OneOps

“Before OneOps, the process of updating Walmart’s website was so tedious that we rolled out updates only every two months. The process used hundreds of manual steps and required significant resources,” Johnson says. “This was time-consuming and created room for manual errors.”

Before OneOps, A/B testing was expensive and time-consuming, taking months to set up multiple cloud environments and conduct tests. By the time testing was done, the rationale for the new feature had waned and whatever opportunity it was created to take advantage of had passed, he says.

At that time, creating enough virtual machines (VMs) in time to handle peak shopping events and traffic would have taken teams of people months to complete, at the risk of exorbitant operating costs, Johnson adds.

The OneOps Afterlife

OneOps now fully manages the Walmart e-commerce platform such that in a typical day the site sees more than 1,000 new software deployments, which developers execute on demand in a span of minutes on average, says Johnson.

OneOps serves a variety of customers such as consumers of Walmart.com, who on black Friday found their shopping experience supported by the tens of thousands of VMs OneOps was able to spin up across multiple clouds to cradle the peak traffic, Johnson says. OneOps is the DevOps and cloud platform for SamsClub.com as well.

Solving the Single Cloud Provider Dilemma

Walmart targeted OneOps to use multiple cloud providers easily, because of the pitfalls of being locked in to a single provider. “The fear of vendor lock-in is the major challenge to cloud service adoption. Cloud vendors like AWS don’t make it easy for customers to move from one cloud to another. The complexities of cloud service migration mean that many customers stay with a provider that doesn’t meet their needs simply to avoid the cumbersome and expensive process of migration,” says Johnson.

Further vendor lock-in concerns, he notes, include:
- Contracts of lengthy duration geared toward ensuring higher server utilization, maximum ROI and profitability for the cloud provider but providing little benefit for the cloud customer.
- Lack of freedom of choice where storage space, processing power, bandwidth and tools and technologies are concerned.
- Because it is typically difficult to find any two cloud providers that use the same tools, compatibility is an issue. “You can’t simply port your site to a new provider without rebuilding it using the new provider’s toolsets,” says Johnson.
- “While you build and test your site on the new cloud platform, you are still paying to maintain it on the old provider, doubling your costs,” says Johnson.
This is why OneOps abstracts the use of differing cloud providers, making porting easy.

The Big Question Is …

OneOps solves a unique set of DevOps challenges related to the cloud. Can you name another platform that does something similar?
May 4, 2016