Are you interested? Call us!

Ti abbiamo interessato? Contattaci!

Zainteresowaliśmy Cię? Odezwij się!

Check what we have been living lately

Scoprite con cosa abbiamo vissuto di recente

Sprawdź, czym ostatnio żyjemy

Do you want to know our offer and talk about the needs of your business? Write to us, we will surely find the best solution.

Leave a number. We will call you back within 30 minutes.

Chcesz poznać nasza ofertę i porozmawiać na temat potrzeb Twojego biznesu? Napisz do nas, na pewno znajdziemy najlepsze rozwiązanie.

Zostaw numer. Oddzwonimy w przeciągu 30 minut.

We bring value by using the best, the most reliable technologies available on the eCommerce market. Our team makes sure that our clients have the ability to achieve their business goals in a way that is safe, predictable and at the highest level.
We have been operating since 2011, and our team consists of 80 people whose competences and knowledge are certified. Our goal is to always achieve the goal, and our know-how is the selection, implementation and development of the best and the most reliable eCommerce technologies. The success in Europe, Asia and North America, along with our experience in numerous industries and in various business models have established our position in the eCommerce world. However, as we believe that the only constant is change, we remain one step ahead at all times, following global trends in the online sales market.

This website uses cookies. By staying on this website, you consent to the use of cookies. Find out more on the <a href="/en/privacy-policy"> website </a>.

Monogo has joined the elite club of Business Gazelles, a group of the most dynamically developing polish companies.

Business Gazelle 2022 for Monogo

Featured products:

<a href="tel:+48531338668">+48 531 338 668</a> <a href="mailto:hello@monogo.pl">hello@monogo.pl</a>

Monogo

Lublin (HQ)

Aleje Jerozolimskie 181, 4th floor Poland

Warsaw

Parkland, 7527 NW 61st Ter, Florida USA

Florida, USA

Parkland, 7527 NW 61st Ter, Florida Usa

<a href="tel:+48531338668">+48 531 338 668</a> <a href="mailto:hello@monogo.pl">hello@monogo.pl</a>

About Monogo

E-Commerce

AI AND AUTOMATION

CLOUD INFRASTRUCTURE

KNOWLEDGE BASE

KONWLEDGE BASE

Questo sito web utilizza i cookie. Restando su questo sito acconsenti all'utilizzo dei cookie. Scopri di più sul sito web <a href="/en/privacy-policy"> </a>.

Prodotti sponsorizzati:

AI E AUTOMAZIONE

6 most important aspects of choosing an e-commerce engine

Kubernetes is an open-source platform that enables the efficient management, automation, and scaling of applications. The word "kubernetes" originates from the Greek language, meaning "helmsman" or "pilot". Developed by Google in 2014 and currently maintained by the Cloud Native Computing Foundation, Kubernetes is sometimes abbreviated as K8S, which represents the first and last letters with 8 characters in between.

core/paragraph

Kubernetes is an open-source platform that enables the efficient management, automation, and scaling of applications. The word "kubernetes" originates from the Greek language, meaning "helmsman" or "pilot". Developed by Google in 2014 and currently maintained by the Cloud Native Computing Foundation, Kubernetes is sometimes abbreviated as K8S, which represents the first and last letters with 8 characters in between.

core/column

core/image

core/columns

In the beginning it was a "pod"

core/heading

<h3>In the beginning it was a "pod"</h3>

Let's start by imagining a regular cardboard box.

Let's start by imagining a regular cardboard box.

What can we say about it? It has dimensions and a certain capacity, and we can put anything we want inside, as long as it fits. To quickly determine its purpose, let's give it a color and a label.

What can we say about it? It has dimensions and a certain capacity, and we can put anything we want inside, as long as it fits. To quickly determine its purpose, let's give it a color and a label.

Going forward, yellow boxes labeled A will hold a specific application that fits perfectly inside. For example, a specific version of Wordpress with particular settings and dependencies. In Kubernetes, this is called a Pod, which is the smallest unit in the K8S structure. The name "Pod" comes from the English pod of whales or pea pod (a flock of whales/pea pod). A pod can have defined allocated CPU/RAM resources, which can be thought of as the box's capacity.

Going forward, yellow boxes labeled A will hold a specific application that fits perfectly inside. For example, a specific version of Wordpress with particular settings and dependencies. In Kubernetes, this is called a Pod, which is the smallest unit in the K8S structure. The name "Pod" comes from the English pod of whales or pea pod (a flock of whales/pea pod). A pod can have defined allocated CPU/RAM resources, which can be thought of as the box's capacity.

But what if our collection of ties grows so large that they don't fit in one box? We can either change to a larger box or add a second identical one with the same color, label, and size. To retrieve something specific, we must check the first box and then the second if we can't find it. In Kubernetes, this supervisor role is fulfilled by a Service.

But what if our collection of ties grows so large that they don't fit in one box? We can either change to a larger box or add a second identical one with the same color, label, and size. To retrieve something specific, we must check the first box and then the second if we can't find it. In Kubernetes, this supervisor role is fulfilled by a Service.

Now, let's say we have a group of boxes that perform the same function. How many boxes can the group hold, and how can we manage the number? We need at least one box for everything to work, obviously. We can rigidly set the number of boxes to three, for example, but each additional box takes up space, even if it's unused. What if we had a mechanism that adds or removes empty boxes (replicas) depending on our needs? In Kubernetes, this mechanism is known as Horizontal Pod Autoscaling (HPA).


The first thing we need to do is define the exact resources required for each container, such as CPU and RAM. We can then set a range for the minimum and maximum number of replicas, for example, minimum: 1 and maximum: 3. We can also establish numerical or percentage thresholds that trigger the addition or removal of replicas based on resource consumption. For instance, if CPU usage exceeds 70%, a new replica is added, and if it drops below that level, a replica is removed. With this approach, we can dynamically manage the number of containers based on their usage. While we can technically have an infinite number of replicas, the size of the cluster ultimately limits the practical number.



Do all of our boxes need to be the same color and size? Not at all! We have complete freedom to choose the containers that fit our requirements, including their configuration, size, and purpose.

Now, let's say we have a group of boxes that perform the same function. How many boxes can the group hold, and how can we manage the number? We need at least one box for everything to work, obviously. We can rigidly set the number of boxes to three, for example, but each additional box takes up space, even if it's unused. What if we had a mechanism that adds or removes empty boxes (replicas) depending on our needs? In Kubernetes, this mechanism is known as Horizontal Pod Autoscaling (HPA).


The first thing we need to do is define the exact resources required for each container, such as CPU and RAM. We can then set a range for the minimum and maximum number of replicas, for example, minimum: 1 and maximum: 3. We can also establish numerical or percentage thresholds that trigger the addition or removal of replicas based on resource consumption. For instance, if CPU usage exceeds 70%, a new replica is added, and if it drops below that level, a replica is removed. With this approach, we can dynamically manage the number of containers based on their usage. While we can technically have an infinite number of replicas, the size of the cluster ultimately limits the practical number.



Do all of our boxes need to be the same color and size? Not at all! We have complete freedom to choose the containers that fit our requirements, including their configuration, size, and purpose.

All of the mechanisms we've discussed so far apply to different groups of containers. In our analogy, we can group items like ties, socks, belts, and pins into containers of various colors, sizes, and labels.

All of the mechanisms we've discussed so far apply to different groups of containers. In our analogy, we can group items like ties, socks, belts, and pins into containers of various colors, sizes, and labels.

Let's go back to the cabinet we mentioned earlier and try to manage its interior using the containers we've prepared so far.

Let's go back to the cabinet we mentioned earlier and try to manage its interior using the containers we've prepared so far.

The cabinet in a cluster represents the physical resources, with each rack containing a specific CPU/RAM and disk space resource, expertly called a Node. When choosing the size of the cabinet, it's important to ensure that the largest box can fit comfortably. In the case of Kubernetes, it's advisable to have a minimum of two Nodes (cabinets), as the failure of one won't cause the system to go down.

The cabinet in a cluster represents the physical resources, with each rack containing a specific CPU/RAM and disk space resource, expertly called a Node. When choosing the size of the cabinet, it's important to ensure that the largest box can fit comfortably. In the case of Kubernetes, it's advisable to have a minimum of two Nodes (cabinets), as the failure of one won't cause the system to go down.

By default, the boxes in the cabinet can be placed chaotically, with socks lying next to pins.

By default, the boxes in the cabinet can be placed chaotically, with socks lying next to pins.

However, Kubernetes doesn't depend on the physical location of the boxes and will stack them wherever there is available free space. Even if there are many more cabinets, access to the boxes won't be affected.

However, Kubernetes doesn't depend on the physical location of the boxes and will stack them wherever there is available free space. Even if there are many more cabinets, access to the boxes won't be affected.

But it's possible to organize the cabinet in a more structured manner. For instance, we can group boxes by type so that each group is in one place and can't access another group.

But it's possible to organize the cabinet in a more structured manner. For instance, we can group boxes by type so that each group is in one place and can't access another group.

This can be achieved by putting a partition in the cabinet and a locked door. In Kubernetes, this role is played by a Namespace, which is a logical separation of components used to organize and restrict access between components. We can use Namespace to separate different types of environments, such as development, test, and stage.

This can be achieved by putting a partition in the cabinet and a locked door. In Kubernetes, this role is played by a Namespace, which is a logical separation of components used to organize and restrict access between components. We can use Namespace to separate different types of environments, such as development, test, and stage.

It's worth noting that Namespace isn't limited to a specific cabinet but applies to the entire set. However, for simplicity, let's assume that the illustration below shows how it would look with more cabinets.

It's worth noting that Namespace isn't limited to a specific cabinet but applies to the entire set. However, for simplicity, let's assume that the illustration below shows how it would look with more cabinets.

When it comes to the number of cabinets we can have and how to manage their quantity, we have two options. We can either define a fixed number of nodes, or specify a minimum and maximum and let the system monitor resource consumption and manage the current amount accordingly. However, it's important to note that Kubernetes doesn't have an autoscaling mechanism built-in. While many service providers that offer Kubernetes have implemented autoscaling mechanisms, some don't.

When it comes to the number of cabinets we can have and how to manage their quantity, we have two options. We can either define a fixed number of nodes, or specify a minimum and maximum and let the system monitor resource consumption and manage the current amount accordingly. However, it's important to note that Kubernetes doesn't have an autoscaling mechanism built-in. While many service providers that offer Kubernetes have implemented autoscaling mechanisms, some don't.

So how does autoscaling for the entire cluster work? It all starts with the boxes. The system monitors the current consumption of resources and adds more boxes if necessary using the Horizontal Pod Autoscaler (HPA) mechanism described earlier. If there isn't enough space in the rack for another box, Kubernetes will signal that there are insufficient resources. The autoscaling mechanism then detects this event and adds another cabinet (server/virtual machine) with additional resources according to the configuration. If redundant boxes are detected and removed, the autoscaling mechanism will remove an unnecessary cabinet if it's no longer needed.

So how does autoscaling for the entire cluster work? It all starts with the boxes. The system monitors the current consumption of resources and adds more boxes if necessary using the Horizontal Pod Autoscaler (HPA) mechanism described earlier. If there isn't enough space in the rack for another box, Kubernetes will signal that there are insufficient resources. The autoscaling mechanism then detects this event and adds another cabinet (server/virtual machine) with additional resources according to the configuration. If redundant boxes are detected and removed, the autoscaling mechanism will remove an unnecessary cabinet if it's no longer needed.

In theory, the number of cabinets is infinite. In practice, we have some limitations in the current version of Kubernetes:

In theory, the number of cabinets is infinite. In practice, we have some limitations in the current version of Kubernetes:

<li>- No more than 110 boxes per cabinet</li><li>- Not more than 5000 cabinets</li><li>- Not more than 150000 boxes in total</li><li>- Achieving such quantities for eCommerce is very difficult.</li>

core/html

<ul><li>- No more than 110 boxes per cabinet</li><li>- Not more than 5000 cabinets</li><li>- Not more than 150000 boxes in total</li><li>- Achieving such quantities for eCommerce is very difficult.</li></ul>

So what is Kubernetes? A container orchestration system that simplifies processes and speeds up deployments in various use cases, despite its seemingly complex architecture. It offers excellent scalability and modularity, while also enabling possibilities that are difficult or impossible to achieve on regular machines.

So what is Kubernetes? A container orchestration system that simplifies processes and speeds up deployments in various use cases, despite its seemingly complex architecture. It offers excellent scalability and modularity, while also enabling possibilities that are difficult or impossible to achieve on regular machines.

A few months ago, during a presentation of the Monogo Cloud platform to a potential client, I was asked to explain Kubernetes, a component of the system. Despite my best efforts to simplify the concept, I struggled to convey its essence effectively. Although the client eventually became our partner and remains satisfied with their choice, I am determined to take up the challenge once more. This time, I will explain Kubernetes using analogies rather than jargon to ensure better comprehension.

6 najważniejszych aspektów wyboru silnika e-commerce

How to design interfaces for m-commerce?

What exactly is Kubernetes?

Adobe Summit 2024  – 3 highlights from the conference

Monogo: AI media opitimisation in e-commerce