Microservice Architecture

To explore this topic, it’s worth starting by discussing the development process itself. Regardless of the type of e-commerce project, it’s generally true that companies can choose from three development approaches:

1. Boxed Product – You can attempt to fulfill the needs you have with it, but it’s possible that sooner or later, you’ll encounter obstacles and limitations because things don’t work the way you want them to. This inevitably leads to product transformation and customization.
2. Further Development of a Semi-Finished Product – In this solution, the market generally offers monolithic systems (e.g., Magento) which are capable but have a steep learning curve for both users and developers. With these, you have to maintain numerous components that you don’t actually need to perform your business activities well.
3. Custom Development – When the requirements become highly specific and unique, turning towards custom development is advisable. Here, you can think in terms of a monolithic system or a microservices architecture – we usually recommend the latter. In the following point, we’ll explain why.

Microservices Architecture vs. Monolithic Architecture

In a classic monolithic system, if we want to intervene in any process to make changes (e.g., add a new component to the software), it will practically affect the entire architecture, the entire software. Because of this, introducing changes is always cumbersome, despite intending to make only minor modifications, as every such step carries numerous consequences.

However, in the microservices architecture, instead of trying to solve everything with a single large software, we create the system as a collaboration of various small software pieces. A good analogy for this logic is to think of soccer teams where players with different abilities play in different positions, and there aren’t 11 identical players, say, forwards. It’s easy to see that such a system is capable of higher flexibility and offers different possibilities.

The small services that serve the entire system are connected to each other in a networked manner, and these network properties can be relatively easily or flexibly resolved – in fact, the services can be swapped out from each other independently. So, if we find a better solution for one of the systems, let’s say we want to change our user management, it won’t really affect the other components because the API endpoints, the interfaces connecting the components, won’t change whether we want to implement Solution A or B on the system.

It’s important to highlight, in the context of the microservices architecture, that the UI is distinctly separated from the backend cores. So, if any trend shift occurs, it’s enough to touch that layer, without needing to rewrite the entire system.

Advantages of the Microservices Architecture

Scalability: The microservices paradigm was fundamentally devised for scalability, allowing the creation of flexible systems both horizontally and vertically. This means that the capacity of individual components can be increased or decreased independently. Consider a scenario where significantly more orders are received on a website during a holiday season. In such cases, there’s no need to alter the load of the entire system, rather focusing on modifying critical points where the heavier load occurs (e.g., order processing or payment data). As a consequence, it’s likely that a cloud-based approach is ideal for implementing development, which generally streamlines the process. Additionally, since individual components can be scaled independently, our costs decrease in the long term after implementation.

Independence from Developers or Development Companies: Since the components that make up the entire service are small and independent, our dependence on developers diminishes. This also implies that the learning curve associated with mastering each component doesn’t need to be covered by the client, as the logic of individual parts can be acquired in just a few hours – eliminating the prolonged learning process typical of monolithic systems, where it might take six months to a year for a developer to fully understand and efficiently manage the system. Furthermore, this indicates that the microservices architecture allows for more cost-effective further development.

Reduced Development Time: Due to the low learning curve and network communication, development times can be shortened, making development more cost-effective in the long run.

Integration-Friendly Architecture: Because these network requests can be easily expanded or reduced in various directions, integrating new solutions (ERP, CRM, 3rd-party solutions) can occur much faster. This also makes sense when compared to monolithic systems: often, we encounter situations where a client has a unique marketing automation system, or products are generated in an entirely different system, or the system needs to collaborate with a logistics chain. In such cases, with a traditional monolithic e-commerce system, we usually start attempting to disconnect these services from the system. So, it’s not just the integration itself that takes time, but also the process of disconnecting the services previously implemented. In a current trend where generally at least 15-20 external services need to be interoperable, the rationale for a traditional monolithic system diminishes, as we exclude so many things that we’re essentially dealing with a completely different software than what we initially started with.

Enhances User Experience: As we can swiftly exchange individual services and their associated presentation forms in a flexible manner, user experience can be rapidly changed and adapted to current needs. Additionally, the UX dependency becomes very low.

Preferred by Software Developers: Employing a microservices architecture often means a significant reduction in greenfield investments or solutions. Due to varying customer demands, only specific elements can be reused, while some need to be custom-developed. Also, numerous new types of requests can arise in the software. There’s no need to inherit previous code or programming styles; new services can be created comfortably, with minimal costs.

Technologically Independent: In a typical monolithic system, we mostly work with a single programming language and can’t explore how we could respond even faster and more efficiently to certain issues. This can be easily achieved in the microservices architecture without imposing substantial costs on the client. Each service is executed using its ideal technology, which not only enhances the flexibility and efficiency of the end result but also provides the developers with a level of flexibility they greatly appreciate.

Enhanced Security: The API Gateway/BFF can be developed uniformly and effectively cover the data paths, which are typically accessible only through them. This makes maintaining system security easier. Components of microservice-based systems undergo multiple tests, thereby boosting the overall system’s security.

Disadvantages of Microservices Architecture

Of course, just as we discuss the advantages, we must also address the disadvantages. Fortunately, there are relatively few aspects here that outweigh the benefits.

Since we’re dealing with the collaboration of numerous components and the services are network-connected, a slight decrease in performance might be observed.

The design phase requires more resources and involves colleagues with significant experience in security and deploying.

Each service must have its own deployment written, which indeed demands additional resources from the development team. However, these investments in resources pay off later.

In the long run, some of these disadvantages can actually turn into advantages. Because these systems are independent from one another, it’s unlikely that we will ever need to replace the entire system; we’ll only need to make adjustments to the components affected by the specific developments. Hence, after the initial higher expenditure, long-term return on investment follows.

Those Already Using Microservices Architecture

It’s always a big question to identify those who have already chosen a particular solution. The good news is that major players in the market, from Amazon and eBay to AliExpress, all use microservices architecture.

An interesting fact is that Amazon requires the cooperation of over 1200 microservices just for the appearance of its homepage. While a typical business doesn’t need such extensive service-ification, it’s important to recognize that these major players are all working with this solution. Beyond the previously listed advantages, this approach allows them to manage technological shifts more easily, regardless of the direction the market moves in.

Our Colleagues are real professionals.