Cloud Native
Micro Frontend Framework Guide: Adaptability for Teams
It’s not you, it’s me. Why breaking up your monolith is the best course of action to design and deploy scalable web apps.
Save to Folio
Related articles in the Micro Frontend series:
In the previous post of this series, we highlighted a use case that would call for a Micro Frontend architecture. In this post, we dive deeper into how Micro Frontend can scale with your evolving organization, especially if your teams have already embraced the microservices approach for backend development.
Micro Frontend optimizes software delivery
Micro Frontends are a natural extension of microservices architecture that optimizes software delivery by decomposing one web application into smaller and independent apps. This allows frontend teams, or teams with frontend developers, the same level of development flexibility, testability, and velocity to release and deploy that backend teams receive from their microservices architecture.
Software architecture that can support evolving team models
If you’ve ever worked for a large organization, you have likely witnessed the way teams are set up and interact is often based on past projects and/or legacy technologies, which might be years, if not decades, old. This is due to Conway’s Law:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”
— Melvin E. Conway
To increase an organization’s chances of building effective software systems optimized for changing business needs, a reverse Conway maneuver (or inverse Conway maneuver) can be used to organize teams to match the desired architecture. Additionally, the software architecture needs to be sustainable to accommodate the evolving organizational structure.
Here’s a breakdown of the different phases of the architectural evolution over organizational changes:
1. Breaking the monolith phase
Imagine a new project begins with a full-stack team that builds and maintain the monolithic 2- or 3-tiered enterprise application with shared databases that power the core business or is on the critical path of value stream (Figure 1: The Monolith). Depending on the scale of the monolithic application, and the team’s capability to handle requirement and code changes, the system may last, but eventually, it will meet its demise. More on that, later.
After breaking up the monolithic application and hiring more developers with the specialized skills (such as Java) to support different parts of the technical stack layers, the teams are split up and owns its backend or frontend monolith (Figure 1: Front & Back). For example, after the split, there can be an API-based React Frontend and REST APIs in the backend.
There were valid historical reasons for the monolithic enterprise applications and monolithic frontend SPAs—until DevOps and microservices gained traction. As the number of development teams continue to grow, the backend architecture begins to evolve for a more scalable systems architecture (microservice), which can be owned by multiple microservice teams (Figure 1: Microservices).
Frontend monolith with microservices
To reap the full benefits of microservices, the cloud, containers, serverless (enables automation and powers both the infrastructure-as-code [IaC] and backend services), consider how to enable ourselves with the similar capability for building frontend web applications. Things get complicated when microservices is used as building blocks for a frontend solution. While the division of backend is often transparent from the user, the question is how good we are at integrating them in a user’s browser, web platforms, or devices?
At this point, if we are playing the “spotting the monolith game,” it would be obvious to spot the frontend as the monolith bottleneck that delivers the customer value in the last mile of the value stream path (Figure 2: Microservice Backend + One Frontend Monolith).
Organization could have multiple frontend monolithic SPAs built with the old or new frontend framework such as JSP, PHP, React, AngularJS, Vue, Ember.js, Knockout.js, Svelte, Next.js, Gatsby, etc. This increases the complexity across many folds as lines of code of JavaScript in the same code repository continue to grow to catch up with the latest feature requests. This is fine if this single shared frontend is the software architecture we want. However, it will suffer from the downsides of any monolithic system:
- Too large and complex for anyone to fully understand and make changes quickly and correctly
- Any breaking change on any part of frontend code could potentially affect the entire website. Worst case scenario, it brings down the whole website
- Any change on any part of frontend code needs to be redeployed, increasing build time linearly and directly in proportion to the number of features and lines of code
Despite the above disadvantages, the traditional frontend-backend working model will still suffice if both the scale of team and frontend is limited. Micro Frontend architecture only becomes desirable when we would like to scale the team and frontend beyond this, which is the case for many leading organizations.
2. Breaking the frontend monolith and collaborating across service teams
If a business wants have parts of website UI developed from different product/services teams, the frontend architecture needs to support this.
With the capability to compose a unified UI from several Micro Frontend web applications, this gives us the opportunity to further improve the flow of value to the customer, as well as the flow of business change pressure.
Initially, due to the lack of familiarity and technical competency to develop Micro Frontend, a Micro Frontend enabling team would be necessary to facilitate the enablement of this new architecture and capability across different teams (Figure 3: Micro Frontend).
Key objectives in this phase are:
- Autonomous: Each product team can operate with minimal dependency from other product team, such as development, build, and testing
- Independent deployments: Enable product teams to release on their own schedule and innovate without affecting the entire application
- Operational responsible: Empower product teams to own the operation of the managed services
3. Service team can own the full-stack end-to-end and the entire feature lifecycle
Once each service team has gained the necessary skills, they can own and operate the entire stack backed by both microservice and Micro Frontend architecture (Figure 3: Micro Frontend + Microservices).
Each of the frontend piece created by individual team since the Micro Frontend can be further combined to form a unified UI. They are now customer focused teams with only one mission: build and ship UI that provides the best UX for feature X, without having to step on other team's toes, or worry about other parts of the system. (Figure 4: End-to-End Stream-aligned Teams).
Once we reach this stage of organization structure, teams are now organised around a single, valuable stream of work, such as a single page feature like dashboard Micro Frontend, service offerings with a full SPA Micro Frontend, a single user journey, or a single user persona.
With the Micro Frontend architecture, they are also enabled and encouraged to build and deliver customer value as quickly, safely, and independently as possible, without requiring communication and handing off overheads to other teams to perform parts of the work. This helps us move towards Conway's equilibrium with stable teams and reduce the need of painful re-organization every few months or years.
Impact of Micro Frontend
Here is the summary of the problems that Micro Frontend can help address in our organization:
- Architecture that enables and encourage fast flow within each team
- Produce software systems architectures that are sustainable over time
- Evolvable system with DevOps: strangler pattern
- Increase the lifetime of legacy web applications without the need to rewrite everything upon integration
- Allow new frontend framework to coexist with on the old/legacy web application
- End-to-end autonomy within a business domain
- No shared codebases and conflicts
- Decouples development dependency
- Avoids building a monolith
- Independent deployments on the team’s own schedule and the ability to innovate without affecting the entire application
- No shared codebases and conflicts
- Do one thing well and own the complete value stream
- Owns the full stack end-to-end and the entire lifecycle
- Operational responsible
- DevOps: Have Conway’s Law work to our advantage
- Can easily scale the development of web apps horizontally with multiple teams engaging frontend work concurrently
Next steps
Now that we understand the motivation and challenges of using a Micro Frontend from an organizational design perspective, we will cover the technical approach in the next post.
