In its study of usage data from thousands of companies and more than 1.5 billion containers, the company found “roughly 45% of Datadog customers running containers use Kubernetes, whether in self-managed clusters or through a cloud service.” Which is impressive growth for a technology that is just over five years old.
Oftentimes, when companies adopt a microservice architecture on the backend, they will leave their front-end as monoliths; that’s how they are shipped anyway… This approach looks something like this:
However, this isn’t truly an end-to-end microservices architecture. While the backend is split up according to business requirements, the frontend is still all in one app. Over time, problems will begin to emerge, especially if your microservices & UI demands go hand in hand.
By using a micro-frontends architecture to complement the backend microservices, companies can split the entire application by business domain across the entire stack. This allows your front-end teams to take advantage of the same benefits of flexibility, testability, & velocity that your backend teams enjoy from their microservices. When containerization is implemented across the front- and backend, it looks more like this:
Are micro-frontends the right choice for you?
There are a lot of reasons to adopt micro frontend architecture, but it is not without adding complexities to your ecosystem. Before you jump right in and start modifying your application to use micro frontends, make sure to evaluate the payoffs against the complexity to measure the value that micro frontends will bring. Here are a few reasons why you may choose to adopt a micro frontends architecture.
Large apps with a ton of complexity
Micro-frontends really start to shine when your front-end app has grown so huge that no team—let alone one person— can understand how the entire thing works. Don’t jump on the micro-frontends bandwagon if your app isn’t at this scale yet, the added complexity may hurt you more than it helps.
Multiple contributing teams, different deployment cycles
Having each piece of the larger application separated into multiple micro-frontends allows each team to deploy their piece of the product without interfering with the release cycles of the rest of the organization.
Each micro-frontend is hyper focused at solving ONE PROBLEM, which will definitely help the code stay clean over the lifetime of the app
Increased choices in technologies
Building using a micro frontends architecture gives organizations and teams the flexibility of building using the technologies of their choosing. A page written with Angular can use a component from a React micro frontend and vice versa. The modal dialog for saving user data may be written in Vue, while the page underneath was done in Svelte. In a micro frontend solution all these different apps can work together.
Second, you are no longer reliant on a single web framework that may not exist the entire 5+ year lifespan of your application. A final benefit of the technology flexibility is that teams and new hires are able to get to work with a much shorter introduction period as they are able to use the technology they want and are comfortable using.
What does micro frontends look like in practice?
Another big benefit of adopting micro-frontends as an architecture is that it forces you to think about your application as various business requirements rather than a collection of items on a page. Take an e-commerce site for example. When you are creating a list of requirements and breaking apart the various functionality:
•There should be a way to shop for items
•There should be a checkout “cart”
•There should be a way to see order history
Without having any designs, we have already identified 3 separate parts of the application that can be developed in isolation from each other. Furthermore, each micro-frontend is hyper-focused at solving ONE PROBLEM, which will definitely help the code stay clean over the lifetime of the app.
Of course, these micro frontends will eventually be stitched together into a single page, but dividing our micro-services by business domain rather than page design allows us to quickly set up alternate flows or versions of the e-commerce site. If the checkout cart is in the top right, we can easily move that CTA anywhere on the page we want without having to worry about data-flow or CSS inheritance problems.
Conclusion
Micro frontends are not a silver bullet. They can help and provide value when the circumstances are right. It is a big endeavor both from a technical but also from an organizational point of view, because you have to include the business people, UI/UX experts and basically everyone in the IT department.
On the other hand, it solves a lot of problems, especially one that large organizations struggle with: The inability to react quickly to new business ideas and requirements. Additionally it alleviates other challenges brought about by a monolith front ends such as: high costs due to the same UI functionality needing to be implemented multiple times with different technologies, complex systems that require a long training period for developers, and the constant fear of making the wrong framework decision that ultimately blocks innovation. If none of the reasons above play have any importance for you then chances are high that you don’t need a micro frontend solution.
When you go for a micro frontend platform be sure to check out Entando.
