Developing apps with a micro frontend architecture on top of a Kubernetes infrastructure offers a number of advantages to enterprises. Your teams can develop individual features and functionalities without being dependent on or negatively affecting other teams or part of the app. This allows your organization to innovate more quickly. Codebases are smaller and more manageable, and you can also better utilize your resources by only scaling up the parts of your app or site that are experiencing the most traffic. 

On the other hand, this development methodology also introduces a new level of complexity to your organization’s overall codebase. So they aren’t a silver bullet for every organization or every application. Nevertheless, they still offer a great deal of value in many situations, if you know how to get the most out of them. 

Here are 4 best practices and 2 pitfalls to consider when you’re considering developing apps with micro frontends in a Kubernetes environment. 

Best Practice #1: Organizational Readiness

One of the most important things about micro frontends structuring your teams to get the most out of the architecture and tools you’ve selected. So you’ll want to focus on enabling your teams to deliver their micro frontends independently. 

You can do this in a couple of key ways. The first is by creating clear responsibilities and goals with roles that everyone can agree on. You’ll also want to ensure that you have good API contracts between teams. Once you have established your structures, your teams will be able to move freely and independently to accomplish their given goals. 

Another way to make sure your organization is ready for this type of architecture is to align business requirements with modular delivery. If your business requirements are defined by a top down approach or in a way that requires everything to be defined at once, you’re not getting the most out of your micro frontends. You might have a micro frontend architecture, but you still have a monolithic organization. 

Pitfall #1: Premature Optimization

Instinct and history can lead developers and architects to seek “don’t repeat yourself” systems and to create shared libraries or shared utilities. This can be a downfall, as it may cause you to end up creating a distributed monolith rather than a microservice and micro frontend architecture. 

So when you have to make a decision, err on the side of repeating yourself rather than sharing code and libraries in micro frontends. You really want to create independence between teams, so that they can individually innovate and move quickly in small groups. Value independence and deployability over sharing things between libraries. 

Instead, you should take advantage of deployment automation capabilities to inject platform services where possible. Rather than focusing on shared code, focus on creating contracts and services.

Best Practice #2: Automate

Microservice and micro frontend architectures must have build and deployment automation. Otherwise, you risk gridlock. This is certainly true in any environment, but it’s especially important in a highly modular architecture. So focus on achieving continuous delivery. 

Test automation is key, and so is testing at multiple levels. Your goal is to ensure your testing provides enough confidence that you can move pieces of your architecture without risking issues when you get to your staging environment or into production. Therefore, focus on building testable contracts, making sure that contracts for micro frontends and microservices are not only clear but can be validated automatically.

Pitfall #2: Overzealous Application

Like all architectural patterns, micro frontends aren’t a silver bullet. And so if you over-apply the concept, you can end up over-fragmenting your application and creating things that don’t have any real value. There’s a great deal of literature that discusses the right size of microservices and what should or shouldn’t be built at a service. The same concepts apply to micro frontends. You don’t want to over-optimize.

When deciding how to define micro frontends, be aware of tradeoffs and watch for potential challenges. For example, module architectures require dedicated testing strategies, and you don’t want to end up with a distributed monolith that has tight coupling. So seek applications that benefit from the strengths of the architecture, such as those that will require independent deployment, that need to be dynamic and adaptable over time, or that could benefit from reuse. 

Best Practice #3: Search for Goldilocks

Finding the right size for your micro frontends is similar to thinking about how to size microservices. They need to be just right. If they’re too big, your application is too tightly coupled. If they’re too small, your application is fragmented. Consider how you might strike a balance. 

Unfortunately, there’s no golden rule when it comes to this. You need to access each application. But a good rule of thumb is that each micro frontend should have a definable business purpose in isolation. For example, you probably could build an individual micro frontend for every icon in a menu bar, but it would be wiser to build the entire menu bar as one micro frontend. If you need broader context to explain the value of a given micro frontend, maybe it should be built as a part of that larger picture. 

As you consider a micro frontend architecture, be sure to make these decisions in advance. It doesn’t have to be perfect, but how you divide your app should be fairly well defined. You also want to consider how you might reuse the same micro frontend to connect to different microservices and data sources to pull from. 

Best Practice #4: Inject Platform Services

Another best practice with micro frontends in a Kubernetes environment is to make sure that the things that you can treat as infrastructure are available to your entire application. 

For instance, you’ll want to use a common identity management system, so that you can have a common view of identity that all of your services can make use of. You’ll also want to focus on common deployment. While you can mix and match different languages and tools, you’ll still need a common set of patterns in the way you expect your microservices and micro frontends to arrive in your environment. You should also establish common rules for scaling, as well as bundling and reuse. 

Use Entando to build apps with micro frontends on Kubernetes.

If you run containerized deployments, you understand the benefits of Kubernetes. You also understand how complicated it can be and how difficult it can be to gain developer adoption. It feels like there should be an easier way. 

That’s why we created a platform that makes it easy to build applications on Kubernetes using modular components.

Entando is an application composition platform for building enterprise web apps on Kubernetes. We want to change the way enterprises think about building their apps, sites, and portals in order to promote developer productivity in a Kubernetes environment.

With Entando, you can:

• Bootstrap an application from a customized template.
• Accelerate app development to update iteratively.
• Simplify deployments by abstracting the complexity of Kubernetes.

We integrate trusted open source technologies and extend their functionality to give you a cohesive and streamlined developer experience with easy-to-use patterns. From deploying on Kubernetes to creating modular backend and frontend architectures using your current technologies, Entando helps you at every layer of the stack. 

Entando is open source with available enterprise support and services. Begin developing on the platform today, and get a quote to see how our team can help your enterprise build better apps, sites, and portals--faster.