Magento 2 on Kubernetes
Zento's headless approach has a PWA frontend with a Magento 2 backend. While the PWA frontend
The Magento 2 layer of the Zento application is running on Kubernetes clusters created using AWS EKS (Elastic Kubernetes Service).
How does traditional hosting work?
Traditional applications are running on a server and all the visits to it are routed to that server's IP address. This dedicated server approach has difficulties scaling up when traffic increases and also needs to be provisioned at a relatively large size in order to function well under higher than average loads, while during sale campaigns it can crash with peaks of traffic; another problem with this approach is reliability, as when something happens to the dedicated server, the entire website is offline, which is called a single-point-of-failure.
A slightly better setup is having multiple dedicated servers with a load balancer, which can scale up with new servers when needed. Although this setup can scale and is more reliable, problems generally revolve around keeping the multiple servers updated and in-sync. Scaling up can also take quite a bit of time (generally anywhere between 5 and 20 minutes for a Magento setup), which for sudden traffic spikes can be too slow.
So traditional hosting is slow to scale or not scalable at all, prone to failures or hard to keep up to date and overall expensive to run.
What is Kubernetes and how does it work?
Kubernetes is a container service, which means that applications are packaged inside small Docker containers (you can think of these containers as mini-servers running the application wherever they are deployed) and are called pods in Kubernetes; these pods are deployed on Kubernetes nodes (which are essentially dedicated servers running dozens of pods).
When an application needs to scale up, new pods are started in a few seconds and then take on incoming traffic, and when scaling down pods are just shut down and resources are made available to the node. In the Kubernetes cluster when the number of pods grows, new nodes are added in a couple of minutes and accept new pods to be deployed onto them. Also great is that when deploying an update to the application, pods with the new version of the code are created to replace the old ones in a matter of seconds and with zero downtime.
This clean approach allows an elegant way to deploy applications using components that have a single purpose, rather than having a single server fill multiple roles. Together with Serverless, Kubernetes is currently the best technology to run applications.
On Zento, our shops are distributed across many Kubernetes nodes (cloud servers) and they can scale with traffic in a matter of seconds, while maintaining a clean and secure isolated environment. If any node fails due to any reason, due to the distribution of pods, shops are not affected and can spin up new pods on another healthy node in seconds.
How does Zento handle media files?
One of the major problems with moving Magento from a single server to multiple servers or in our case to Kubernetes is with its media files. Beside the application code, Magento relies on having a media folder on disk storing all the product images and files; this is essentially data being co-located with application code, which is not a good practice.
The general solution to this problem is having a shared drive for the media folder on all the servers (technically called
mounting a NFS4 drive) so that to Magento it looks like a single folder, while data persists between servers. The problem with this approach is that it can be slow and prone to failures.
At Zento, we have a better approach: we rewrote Magento's disk storage layer to upload all media files directly to AWS S3, so that the frontend can then directly load the resources from S3 through the CDN. This is very efficient for the Magento Kubernetes pods that now only include application code, very fast to load on the frontend and extremely reliable, as AWS S3 is one of the most stable services on the Internet.
Since original media files are stored on S3, it allows Zento's frontend to request resized and optimised versions of the images that are generated and cached on-the-fly with Serverless functions. You can read more about how images are optimised and resized on the
Zento's traffic flow for Magento 2
All the visits directed to Magento are routed from the CloudFront CDN to an AWS Application Load Balancer (ALB); based on the host, it knows to route the traffic to the correct namespace and service in EKS, where the traffic is load balanced between the pods.
The shop's m2-http pods are responsible only for serving traffic and they never run heavy batch jobs that could affect their performance in serving user requests.
How are the batch jobs executed?
Magento has several heavy operations that are being executed in batch jobs. Unlike with dedicated servers, in Zento these jobs are never executed on pods that serve live traffic, but on special consumer pods.
Magento 2 has a queue system for these batch jobs, so when a heavy operation like creating or updating 10000 products is executed, 10000 jobs are created in a queue and then job consumers take jobs one by one and execute them. Zento's Kubernetes infrastructure spins up several consumer pods capable of processing jobs in parallel, in order to finish a queue fast; when it's completed, it automatically spins them down.
Zento runs Magento in a state-of-the-art Kubernetes setup, so that your shop can:
scale up in seconds when needed
have no single-points-of-failure
run reliably and store media files properly
execute heavy batch jobs in isolation, without impacting the user experience
seamlessly deploy updates with zero downtime
This is important for users as they'll have a good experience with a fast loading shop all of the time and experience no slowdowns or interruptions, which in turn for you as a merchant results in higher conversion.