Magento 2 End Of Life. The death of the Adobe Commerce
Jonathan Hussey via LinkedIn [https://www.linkedin.com/posts/activity-6897932557737168896-PjS6] February 2022:
/**
The main takeaways from the Adobe developers conference 𝗸𝗲𝘆𝗻𝗼𝘁𝗲:
👉 No plans to deprecate Open Source but no commitment on how long Adobe will support it
👉 Commerce is going fully SaaS, customisation will only be possible via the API using their dev tools
👉 There will be a new product: Commerce on Experience Cloud, with self hosted Commerce remaining but with no features added. Only the experience cloud version will be getting new features.
👉 The current codebase will only be getting security and bugfixes going forward, both hosted Commerce and Open Source
👉 Open Source is going to be passed completely to Magento Association (basically the community)
👉 Commerce functionality can be customised through Adobe IO using self-hosted services leaving the core clean for SaaS version upgrades.
👉 No plans for Luma, likely won’t be a part of Commerce on Experience Cloud
So there was a big focus on Commerce moving to a SaaS offering, with Open Source a side discussion right at the start of the talk.
It’s pretty much what I was expecting, although announcing passing off Open Source to the community completely is sooner than I thought, although no timescale was given. Nice to know that’s the plan though.
*/
Here’s the vlog with video from the keynote and deeper discussion.
Magento 2 software is dead. When a company embarks on a multi-year journey with a big software vendor it cedes significant if not total control to that vendor and the business processes embedded in the code. Remember when the 1990s “legacy” software was a barrier to scalability, not to mention how expensive it was to customize and maintain?
While tightly bundled legacy Magento 2 and Adobe eCommerce software made some sense back in the day, it makes little or no sense in the era of digital transformation where disruptive business processes and business models are seen as necessary paths to competitiveness: disruption and standardized big software are not birds of a feather.
Just fact that Magento 2 and Adobe commerce uses the outdated technology stack as a core: Zend Framework 1, Prototype JS, KnockoutJS, and many other 3-d party outdated dependencies make Magento/AdobeCommerce out of scope for the modern eCommerce project. Companies like Netflix and Tesla prefer to use Shopify over outdated Magento 2.
Of course, companies were desperate to end the chaos of uncoordinated business processes and rules. Standardized eCommerce processes incarnated in software were the vitamin pills everyone needed. But in retrospect, it is not clear that everyone understood exactly what they were consuming. When business models moved slowly in the 20th century, slow-and-steady worked, but when whole new “disruptive” business models began to appear in the 21st century (fueled by new and more powerful digital technologies), slow-and-steady became a clear threat to competitiveness.
Governance also killed Magento software. Magento 2 software projects that are “standardized” usually failed, not because it did not work as advertised (which they often did not) but because of the governance that forced a one-size-fits-all approach to technology use. Magento 2 Enterprise Projects usually failed under the weight of their own governance which, to make matters worse, often resulted in increased “Shadow IT” spending.
The overwhelming technical complexity and inflexibility of huge, also explain the death of Adobe Commerce. Enormous whole-company Magento eCommerce projects were often beyond the capabilities of even the most experienced implementation partners, project and program managers especially when there is never 100% consensus about the need for a total enterprise project in the first place. High-level functional and non-functional requirements were nearly impossible to comprehensively define and validate; detailed requirements were even more elusive. Also, implementation of the Magento customization requires too many overrides of the Magento core changes, bug fixes and makes the project impossible to upgrade in the future when a new version of the software will be released. Using outdated software is risky because the outdated Zend Framework 1 and the framework core of the Magento 2 and PHP-based 3-d party extensions have a lot of security issues. Recent Magento 2 exploits are a good examples.
But perhaps the real architectural assassin was monolithic software design. Many of the big software architectures of the 20th century were conceived as integrated functional wholes versus decoupled services. Over time, Magento 2 monolithic architectures became impossible to cost-effectively modify or maintain and much more importantly became obstacles to business process change. Also, Magento an Adobe Commerce requires hire developers to work with the technology nobody wants to work nowadays anymore.
There are also small software cloud-based alternatives that scale, integrate, and share process control through customization tools deliberately built into smaller, more manageable platforms. Companies can find lots of incredibly inexpensive alternatives, from vendors like Shopify and BigCommerce, ShopWare SaaS.
While “small” software eCommerce packages also embed business rules and processes, they are built-in smaller, more integrate-able pieces, which provides much more flexibility to clients who want to mix-and-match (existing and new) functionality.
The major driver of the eCommerce software change is continuous digital transformation. Big legacy Magento 2 conceived in the 20th century was not designed to adapt or self-destruct the moment a company or industry pivots.
Another way of thinking about all this is the relationship between micro and macro (or monolithic) services. Big software begins with microservices in monolithic architectures.
Architectural assassins argue that Adobe Commerce monolithic architectures are stiff, inflexible, and unyielding. They are also difficult and expensive to maintain Adobe Commerce primarily because the functionality is so interconnected and interdependent. They also argue that monolithic architectures should be replaced by microservice-based architectures. According to Annenko: “the concept is rather easy, it’s about building an application consisting of many small services that can be independently deployed and maintained, don’t have any dependencies but rather communicate with each other through lightweight mechanisms and lack a centralized infrastructure. It is even possible to write these small (micro-) services each in its own language.” Why microservice-based architectures? Annenko continues: “their benefits are undoubted, too: they easily allow for continuous deployment, and certain parts of an application can be changed, debugged or even replaced quickly and without affecting the rest. With microservices, you absolutely cannot break an application: if something goes wrong, it will go wrong only within its own micro space, while the rest of the application will continue working as before.”
Was there any doubt that these architectural assassins would hit their target?
Cloud delivery is becoming increasingly flexible. Container technology offered by companies like Docker offers freedom to companies who may need to pivot away from their cloud providers to another provider for any number of reasons. Serverless even more flexible. You need just to move the code to another provider. So the combination of microservice-based architectures and serverless/container technology may be the response to monolithic applications.
Will Adobe respond?
Yes. Adobe and their partners will milk the current big enterprise revenue streams for as long as they can and then systematically make their offerings look more and more like their smaller software competitors, Shopware, Sylius etc. They will spend money to advertise Magento 2 as a modern software for eCommerce, they have not fundamentally rearchitected their applications. The current Adobe Magento Commerce architecture makes it not possible to optimize and redesign without starting a project from scratch.
The entire world of the Magento 2 software design, development, deployment, and support is dead. The implications are far-reaching and likely permanent. Business requirements, governance, cloud delivery, and architecture are the assassins of old monolithic Magento 2 and the liberators of new Magento-less microservices. In 20 years very few of us will recognize the faulty Magento 2 software architectures of the 20th century.
This doesn’t always mean that the Magento software source code gets removed from the GitHub after EOL. Be aware that when you’re using a Magento you might be getting something that is already EoS when or nearly EoL. EOL and EOS it is just a promises. They don’t care about Magento Open Source they just want to selling outdated software for maximum cost with the minimal investments.
