Corporate systems with microservice architecture
Microservice architecture is one of the most popular topics in IT circles today because its implementation comes with numerous business benefits. The solution has no limits in terms of application, but we will focus on one platform, e-commerce development, and examine why it’s worth choosing microservice architecture for integrated webshops.
To explore this issue, it is worth first discussing the development process itself. Regardless of the e-commerce project, companies generally have three types of development options:
Boxed product – You can try to meet your needs with it, but you may eventually encounter obstacles and limitations because something does not work the way you want it to. At that point, it becomes inevitable to transform and customize the product.
Further development of a semi-finished product – In this solution, the market usually offers monolithic systems (such as Magento), which are capable but have a steep learning curve for both the user and the developer. With these, you have to keep a lot of components alive that you don’t even need to perform your business activities effectively.
Custom development – When needs are very specific, it is worth turning to custom development. Here, you can think in terms of a monolithic system or microservice architecture – we usually recommend the latter, and we will explain why in the following point.
Microservice Architecture vs. Monolithic Architecture
In a classic monolithic system, if we want to intervene in any process to make changes (e.g. we want to place a new component in the software), it will practically affect the entire architecture, the entire software. This makes the introduction always cumbersome, even if we only want to make minor modifications, as each such step will have many consequences.
On the other hand, in microservice architecture, instead of trying to solve everything with one large software, we create the system as a collaboration of several different small software. A good analogy for this logic is to think of football teams where players with different abilities play in different positions, and not all 11 players are of the same type, say striker. It is easy to see that such a system is capable of greater flexibility and has 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 easily replaced independently of each other. So if we find a better solution for one of the systems, for example, we want to change our user management, it won’t really affect the other components because the API endpoints, the interfaces with which the components are connected to each other, will not change whether we want to apply Solution A or Solution B to the system.
The small services that serve the entire system are networked, and these network properties can be easily or flexibly resolved – and service components can be easily replaced independently of each other. So, if we find a better solution for one of the systems, such as wanting to change our user management, it won’t really affect the other components because the API endpoints and interfaces through which the components are connected will not change whether we want to apply Solution A or Solution B to the system.
It is also important to note that the UI is specifically separated from the backend cores in the microservice architecture, so if there is a trend change, it is enough to touch only that layer, and we don’t have to rewrite our entire system.
Advantages of the microservice architecture
Scalability: The microservice world was fundamentally designed for scalability, and it was important to create systems that were flexible both horizontally and vertically. This means that the load capacity of individual components can be increased or decreased on their own. Just think about the fact that during a holiday season, many more orders are placed on a site – we don’t have to change the entire system load, but we only need to modify the critical points where higher load is coming in (e.g. in the order process or payment process-related data). One of the consequences of this is that it is probably advisable to develop using a cloud-based method, but this usually makes the process more convenient. And since individual components can be scaled independently, our costs decrease in the long run after implementation.
Independence from developers or development companies: since the components that make up the entire service are small and independent from each other, our dependency on developers also decreases. This also means that the learning curve that comes with learning each component does not have to be paid for by the client, as the logic of each part can be learned in just a few hours – so there is no long learning process as with a monolithic system, where it can take even half a year to fully understand and efficiently manage the system. All of this also means that further development can be more cost-effective with a microservice architecture.
Shorter development times: due to the low learning curve and network communication, development times can be shortened, which also makes development more cost-effective in the long run.
We are talking about integration-friendly architecture: since these network requests can easily be expanded or reduced in any direction, we can integrate new solutions (ERP, CRM, 3rd party solutions) much faster. This makes sense when compared to monolithic systems: we often encounter situations where a client has a unique marketing automation system, or the products were created in a completely different system, or the system needs to cooperate with some logistics chain. In such cases, we typically start trying to disable these services from the system in a traditional, monolithic e-commerce system. So, not only does integration take time, but we also have to disable the services that were previously created. In a current trend where we usually need to be able to work with at least 15-20 external services, the traditional monolithic system loses its meaning because we exclude so much that we are talking about a completely different software than the one we originally started with.
It increases user experience: since we can easily and quickly replace a service and its associated presentation forms, the user experience can be changed and adapted quickly to current needs, and the UX dependency will also be very low.
We are talking about integration-friendly architecture: since these network requests can be easily expanded or reduced in some direction, we can integrate new solutions (ERP, CRM, 3rd party solutions) much faster. This makes sense compared to monolithic systems: often we encounter situations where a client has a unique marketing automation system, or the products are produced in a completely different system, or the system needs to cooperate with a logistics chain. In these cases, with a traditional, monolithic e-commerce system, we typically try to disable these services from the system. So not only does integration take time, but also disabling the services they created earlier. In a current trend, when we usually have to work with at least 15-20 external services, a traditional monolithic system loses its meaning, as we replace so much that we are almost talking about a completely different software than the one we originally started with.
Increases user experience: since we can quickly and flexibly replace a service and its associated display formats, the user experience can be quickly changed and adapted to current needs, and the UX dependency will be very low.
Software developers like working with it: working with microservice architecture represents a lot of greenfield investments or solutions, as only certain elements can be reused due to changing customer needs, and some need to be designed according to our own tastes, and many new types of requests can appear in the software. We do not have to take over previous codes or programming styles, we can easily create new services at a very low cost.
Technologically independent: in an average monolithic system, we can usually work with one programming language, and we cannot try how we could react even faster and more efficiently to something. This can be easily done with microservice architecture without it being a big cost for the client. Each service is implemented with the ideal technology for it, which on the one hand increases the flexibility and efficiency of the end result, and on the other hand, this is also a flexibility that developers really like.
Safer: the API Gateway/BFF can be developed uniformly and can cover the data paths well, which are typically only accessible through them, making the system easier to maintain from a security standpoint as well. Microservice-based system components involve more testing, which also helps the security of the entire system.
The disadvantages of microservice architecture
Of course, just as we talked about the advantages, we also need to discuss the disadvantages, but fortunately, there are relatively few items that outweigh the benefits.
Since we are talking about the collaboration of many components and the services are networked with each other, there may be a slight performance decrease.
The design phase is also more resource-intensive, and colleagues with extensive experience in security and deploying need to be involved in the process.
Each service needs to have its own deployment written, which does require additional resources from the development team – but these resource investments will pay off later.
However, in the long run, some of the disadvantages can be turned into advantages. Since these systems are independent of each other, it will never happen again that we have to replace the entire system, we only need to touch the components affected by the specific developments. So after the initial higher investment, there will be a longer-term return.
Those who already work with microservice architecture
It’s always a big question who are those who have already chosen a certain solution. The good news is that major players in the market, from Amazon to eBay and AliExpress, all use microservice architecture.
An interesting fact is that Amazon requires more than 1200 microservices to collaborate for just the appearance of the homepage. Of course, an average company does not require this level of servicification, but it’s important to see that these major players all work with this solution. In addition to the previously listed advantages, this is also the reason why they can more easily handle technological changes, no matter which direction the market moves.
