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:

• Managed class resolution/loading and interception
• Monkey-patching and inheritance chain disruption
• Global configuration load and merging
• Module load sequence manipulation
• Route and controller (MVC) overloading and manipulation
• Synchronous event-observer pattern

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

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:

• In-process extensions can be faster to implement, having fewer dependencies
• In-process extensions allow developers to go further in optimization
• Out-of-process extensions are limited by the capabilities of APIs

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:

• I/O Events for Commerce: Over 2000 internal Adobe Commerce events are now exposed to the I/O event bus in the Adobe Experience Cloud, allowing external apps and microservices to process them asynchronously.
• Webhooks: The same events can also be forwarded to external microservices for synchronous, interrupt processing of key transactional operations to control process flow remotely.
• Admin UI SDK: Backoffice screens and features may now be embedded using externally loaded apps (akin to Shopify Admin Apps and Commercetools Merchant Center Extensions).
• App Builder: Build apps in a Node runtime and deploy them to Adobe's Experience Platform infrastructure to observe external events, process webhooks, serve admin apps, or establish microservices to extend and integrate your Commerce application.
• API Mesh: Orchestrate your APIs within and outside of the Adobe Experience Cloud to streamline your integrations upon a centralized GraphQL endpoint.

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:

• Use in-process after you’ve determined out-of-process doesn’t expose the capability you’re extending
• Use in-process when you need additional performance optimization beyond your reach with out-of-process extensions
• Use in-process when you are adding major functionality to core features (ex: new product types, checkout steps, etc.)

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.