Out-Of-Process Extensibility: Is It the Future of Adobe Commerce?

Adobe is taking big steps to modernize its commerce platform, moving traditional integration approaches away from in-platform customizations to out-of-process extensibility. We are seeing an ecosystem shift towards delivering merchant capabilities using external, edge-powered microservices built on new Adobe Experience Platform capabilities like App Builder and I/O Events.

This shift is impacting the skills required to build and integrate Adobe Commerce, the scalability of the platform, and time-to-value realization for businesses. Is this the future of Adobe Commerce integrations? Before answering that, let's take a closer look at what out-of-process extensibility really means and why it's important to the Adobe Commerce community.

What is Out-Of-Process Extensibility?

In broad software development terms, out-of-process extensibility refers to the idea that customization or extension of software functionality is to be both developed and integrated outside of internal processes. This is the opposite of in-process extensibility, which allows for customizations to occur within or alongside software functionality.

In modern, cloud-native web application development, this may seem trivial, for almost all extension of software is accomplished from the outside. But for self-hosted, on-premise, or open-source software, it is often the case that in-process extensibility is an alternative, if not the preferred, approach.

In the context of Adobe Commerce, for some, out-of-process extensibility presents a radical change in how we approach solution design. To understand how, we have to know its history.

A Brief History and Detour

Since its creation over 15 years ago, Adobe Commerce (formerly Magento Enterprise Edition), a "PHP monolithic application" has been driven by a core framework that not only powered its own core features (modules), but that same framework (called the "Magento framework") also was made available to developers for both modifying core functionality and extending the application to support new functionality. In the days of Magento 1, this was achieved using a unique module registration system. In Magento 2 / Adobe Commerce, the same core concept has been retained but significantly enhanced with the help of Composer for package (module) management.

Thus, the primary means for extending or customizing the application was to build, package, and deploy your changes with the core platform as a single solution. In other words, your custom modules would sit alongside the core modules, and they would run together under a common framework. Moreover, they were not isolated from one another except by convention or best practice, a "gentleman's agreement." Those of us who have been in this community for even a short time might be laughing at this, and for good reason–leaving people to honor convention is often little more than idealistic.

Anyway, this approach to customization can be understood as "in-process extensibility." It should be easy to see the great power and great risk that comes with it. If it's not clear, consider some technical details. The Magento framework made in-process extensions possible through a combination of features, including:

In the right situations, these are invaluable tools for extending software safely. But as merchants, implementers, and maintainers have learned, in the wrong hands, these tools have given to tangled webs of unmaintainable software that have, in some cases, shipwrecked deployments or left merchants to pursue entire rebuilds, or worse, abandon the platform.

Coming to more recent history, as Adobe has invested in the maturity of the Adobe Commerce platform and has taken more responsibility for platform stability in enterprise applications, the intolerance for such risk has demanded an alternative approach to customization. Upon taking a step back and looking at more modern, MACH-influenced approaches to platform design, we begin to see that out-of-process extensibility may present a viable solution to this problem.

How Do Approaches Compare?

With the historical context behind us and having understood in-process and out-of-process extensibility, let's look at how they compare. We'll start from some simple use cases and attempt to suggest common solutions using IPE (in-process extensibility) and OOPE (out-of-process extensibility).

Use Case
Possible IPE Approach
Possible OOPE Approach
Real-time inventory check in WMS prior to order submission
Replace or extend core code to query external data source, allow or block action based on result.
Subscribe to observable synchronous events, query external data source from microservice or runtime, return normalized result back to application.
Add job status metadata to order from ERP after submission
Develop a custom module to periodically pull status changes from ERP and apply to orders.
Develop middleware service to forward job status change events from ERP into commerce order records via API.
Load attachment links to product records as downloadable resources (PDF, doc, etc.)
Develop a custom module to enhance the media gallery to support downloadable resources.
Develop a client-side request to fetch attachment data from an external microservice for the current product.
Improve performance of loading customer data
Modify core behavior to optimize data query and load operations.
Load customer data from an alternate external, faster source (existing or specially developed).

I'm intentionally omitting some details here. There are likely dozens of alternate solutions for these use cases. I'm suggesting just one for each approach and balancing the solution to be generally understood for any commerce platform.

What About the Benefits?

A few things should be apparent when comparing these approaches:

Does that make one better than the other? It depends. Choosing the right approach will vary by use case, environmental constraints, design principles, and probably a host of other factors. What's important is that out-of-process extensibility offers additional approaches to solving problems.

The Future of Adobe Commerce

Out-of-process extensibility is a new pattern for Adobe Commerce. The pattern itself has existed as long as the platform had web APIs. Developers from other ecosystems are keen to its benefits and may have already been applying it in practice.

Let's take a quick inventory of some important new features for Adobe Commerce:

Each of these capabilities are built on modern, MACH-oriented design patterns, and they provide the necessary tools a developer needs to employ out-of-process extensibility.

Not only is this future available today, but I think this is a clear stance from Adobe to position Adobe Commerce as a SaaS platform. If not for the existing user base and traditional extension marketplace, the platform may already be fully cloud-managed, the original PHP source being sealed off from customization forever. It's my hope that this day never comes, for the true power of Adobe Commerce has always been in the extensibility of its Magento roots. The open-source origins of the platform afford a degree of customization that a pure SaaS-delivered platform can never match.

Yet, I still think the future of Adobe Commerce is in out-of-process extensibility.

Cautions and Considerations

When I say out-of-process extensibility is the future of Adobe Commerce, I mean to say that these capabilities enable the platform to compete with cloud-native, SaaS-delivered engines. Organizations looking to bring their own frameworks, tools, and processes will no longer have to endure the learning curve and investment associated with Adobe Commerce. This is an important mutual win for Adobe and its customers.

However, as with all new tools, I tend to proceed with caution. I think we should understand the inherent limitations of customization from the outside or building a solution around something. There may be good, justifiable reasons for in-process customization. And “justified” is a critical word here because there are times when the right tool for the job is all you have onhand (read: capabilities), or it is what you are most comfortable with (read: efficiency), or it gives you more control (read: maintainability).

So when should you use an in-process vs. out-of-process extension? Here are some tips:

Choose out-of-process extensibility first, and when it reaches a boundary, move towards in-process customizations.

This is an exciting time for Adobe Commerce! The product is continuing to evolve and keep pace with changing conditions. Adobe appears to understand what competing platforms are doing well. They’re not just taking notes. They’re taking action. And this is to the great benefit of its development community.

If your business is looking to advance its commerce capabilities, contact the Blue Acorn iCi team today.

Subscribe to Our Newsletter

Get the latest insights from Blue Acorn iCi