Magento 2 Open Source Community Monorepo Fork vs Adobe Commerce Cloud

In version control systems, a monorepo (“mono” meaning ‘single’ and “repo” being short for ‘repository’) is a software development strategy where code for many projects is stored in the same repository. As of 2017, various forms of this software engineering practice were over two decades old, but the general concept had only recently been named. Many attempts have been made to differentiate between monolithic applications and other, newer forms of monorepos.

Magento Monorepo means using one repository that contains many dependencies.

Monorepo is a nickname that means “using one repository for the source code management version control system”.

A Magento monorepo architecture means using one repository, rather than multiple repositories.

For example, a Magenеo monorepo can use one repo that contains all composer dependencies (vendor), all compiled files (generated), and for all 1-st and 3-d party extensions (vendor and app).

Monorepo is also known as one-repo or uni-repo.

Google, Facebook, Microsoft, Uber, Airbnb, and Twitter all employ very large monorepos with varying strategies to scale build systems and version control software with a large volume of code and daily changes.

Advantages of the Magento mono repo

There are a number of potential advantages to a Magento monorepo over classic repositories which have only composer files:

• Ease of code reuse — Similar functionality or communication protocols can be abstracted into shared libraries and directly included by projects, without the need of a dependency package manager.
• Simplified dependency management — In a multiple repository environment where multiple projects depend on a third-party dependency, that dependency might be downloaded or built multiple times. In a monorepo the build can be easily optimized, as referenced dependencies all exist in the same codebase.
• Atomic commits — When projects that work together are contained in separate repositories, releases need to sync which versions of one project work with the other. And in large enough projects, managing compatible versions between dependencies can become dependency hell. In a monorepo this problem can be negated, since developers may change multiple projects atomically.
• Large-scale code refactoring — Since developers have access to the entire project, refactors can ensure that every piece of the project continues to function after a refactor.
• Easy to install what you need just to run setup:upgrade. You don’t need to hire developers just to install Magento anymore.

What is Magento Community Fork?

Magento Forking is to take the source code from an open-source Magento community and develop a better version of the forked software.

Forks occur when Adobe (owner of the repo) decides not to address use cases that other members of the Magento development community feel are important: performance, developers' experience, broken architecture, the direction of the product.

The right to fork is open source software’s greatest strength. A successful Magento 2 fork can save development time, inspire other uses for old code, and create new business opportunities. this new Magento fork remains compatible with the original program (shallow fork).

The name fork is derived from the POSIX standard for operating systsems. In this context, a fork is a process that generates a copy of itself.

We will use this community Magento 2 Fork which uses monorepo architecture:

magenx/Magento-2

This repo is a Magento Open Source (Community) fork with optimized performance and without garbage core Magento 2 modules: chat, adobe stock integration, MSI, etc + another necessary community extension.

Why the fork?

One of the main reasons for the forking was the discontent over the way in which Adobe was handling the project and killing the Magento open source in favor of Enterprise offerings: Magento Commerce, Cloud, 3-d party companies.

Some of the core contributors tried working with Adobe to move the project into a structure where the contributors and community could step in to solve the problems that make a profit for Magento and Adobe(bugs, issues, test coverage, issue reporting). However independent developers want to improve Magento and its ecosystem without any big corporate bullshit.

We don’t want to have just one person who’s appointed by a company making decisions. We want contributors to have more control.

Big tension between the Adobe corporate owner of an open source project and the community of developers contributing to it.

How to install Magento 2 monorepo.

Create instance C6g 16.xlarge

This instance is known as Magento Cloud killer. with 64 physical core and better performance than Intel with the fraction of the broken Magento Cloud Cloud cost:

Monthly Magento AWS Hosting Cost :

Yearly Magento AWS Hosting Cost:

Similar Adore Commerce Cloud could potentially cost over $500K per year .

Connect instance :

Instance ID

i-084576599640dedf5

1. Open an SSH client.
2. Locate your private key file. The key used to launch this instance is test-key.pem
3. Run this command, if necessary, to ensure your key is not publicly viewable.
4. chmod 400 test-key.pem
5. Connect to your instance using its Public DNS:

Example:

1. ssh -i “test-key.pem” ec2-user@ec2–54–151–39–218.us-west-1.compute.amazonaws.com

To install everything on clean Linux you need just:

sudo yum install git -y
git clone https://github.com/Genaker/Magento-AWS-Linux-2-Installation.git
cd Magento-AWS-Linux-2-Installation
sudo bash ./install-monorepo-git.sh

You can find Magento automated installation script here :

Genaker/Magento-AWS-Linux-2-Installation

If you have any questions how about this architecture ask me at: yegorshytikov@gmail.com

Magento 2 Community Fork vs Adobe commerce Cloud

Let’s test the performance of our Monorepo Magento Fork vs Adobe commerce Cloud

As an example of Adobe Commerce Cloud, we will use this website: www.sugarfina.com created by certified Adobe partner Corra.

This site is pretty simple just selling candies online.

Our Magento environment will have disabled FC for better representation of what’s happening we will test the test customer login Page. (https://www.sugarfina.com/customer/account/login/)

Why login page?

This page is not cached and is really easy for rendering without any complicated functionality. If the login page doesn’t work well any other PDP, PLP pages will not work as well. To test infrastructure performance you don’t need complicated and redundant JMeter tests. So we can test base infrastructure Adobe Cloud vs C6g Graviton 2 AWS instance without Magento monorepo repository performance using this.

We will use the next metrics in our test:

Waiting (TTFB)- the time between writing the last byte of the request and receiving the first byte of the response. Note that Processing includes this time.

Median — middle value of all requests. To get this value you would have to list all the result values in numerical order and find the middle number.

Max — The maximum number of milliseconds a request took.

Concurrency -number of multiple requests to perform at the same time to Magento server

We will repeat each test Concurancy x 2 times to have more accurate results.

Response wait time less is better

Magento 2 Monorepo Fork on AWS Graviton 2

Concurrency 1

Result: 87 ms to render a single page.

Concurrency 10

Result: 93ms

Concurrency 20

Result: 98ms

Concurrency 30

Result: 100ms

Concurrency 40

Result: 101ms

Concurrency 50

Result: 102ms

Concurrency 60

Result: 115

Concurrency 100

Result: 192 ms

We can see that our environment double the response time after 100 concurrent requests. if you don’t need this greater performance you can use a smaller size of the c6g Graviton 2 powered instance.

Resize AWS Magento instance:

1. Open the Amazon EC2 console.
2. In the navigation pane, choose Instances.
3. Select the instance and choose Actions, Instance state, Stop instance.
4. In the confirmation dialog box, choose Stop. It can take a few minutes for the instance to stop.
5. With the instance still selected, choose Actions, Instance settings, Change instance type. This action is grayed out if the instance state is not stopped.
6. In the Change instance type dialog box, do the following:
7. From Instance type, select the instance type that you want. If the instance type that you want does not appear in the list, then it is not compatible with the configuration of your instance (for example, because of virtualization type).
8. Choose Apply to accept the new settings.
9. To restart the stopped instance, select the instance and choose Instance state, Start instance. It can take a few minutes for the instance to enter the running state.

Adobe Commerce Cloud Performance

What Adobe wrote about theirs Commerce Cloud solution :

Optimized Performance

Run your commerce operations with the confidence that you can exceed customer expectations. Confidently exceed customers’ expectations.

By working with the global leader in public cloud delivery and performance, you get more than a commerce platform — you get peace of mind. Our cloud-based solution provides a reliable Amazon Web Service (AWS)–based environment that supports any size of ecommerce deployment.

Improve your commerce performance with 24x7 proactive monitoring and scaling from a team of experts.

Accelerate store performance using the built-in integration with Fastly’s content delivery network (CDN)

Let’s check Adobe Commerce Optimized Performance.

Adobe Commerce Cloud Performance https://www.sugarfina.com/

Concurrency 1

Result: 344 ms

Concurrency 10

Result: 525ms

Concurrency 20

Result: 639ms

Magento Cloud doubles response time after 20 requests per second.

Concurrency 30

Result: 794ms

Concurrency 40

Result: 940ms

Concurrency 50

Result: 1141ms

Concurrency 60

Result: 1236ms

Concurrency 100

Result: 1552ms

We can see Adobe commerce cloud provides 10 times worse throughput performance and 5 times worse base response time. You can also improve AWS Graviton performance by moving the database to a separate RDS Aurora Database instance. Also you can offload Elastic Search and Redis to dedicated instances. But, you cant improve Adobe Commerce Cloud performance you can just use it as is and you site will be slow and you will lose conversion and customers.

So, don’t waste your time and money on Magento Commerce cloud and top-rated certified development partners. Use community-driven projects with the help(paid) of the developers from the community.

Magento Community Fork vs Adobe Commerce Cloud

Pivot Table

less is better