Cloud Native Microapps - small apps that build super systems

TL;DR

     Micro-apps share a common identity and access manager, and applications run in independent containers

Developing enterprise-grade software is a complex process requiring experienced developers and business analysts to work in tandem. However, the more features required, the more roles are needed, increasing the complexity and difficulty of development quadratically.

Cloud-Native Micro apps is a super-architecture development style that reduces complexity to a linear scale, building specialized apps in a common cloud-native framework that shares one service mesh, one identity and access manager, and one secure gateway.

Micro apps extend from microservices and are fully compatible with micro frontends. This architecture is agnostic to support other architecture types and pays special attention to reliability, resilience, and security. Benefits include better team organization, faster time to market, and lower development and maintenance costs while promoting agile business practices.

Quadratic vs linear complexity is a big deal for complex applications
    

Motivation

There is a need to have an architectural style that reduces the pain of developing enterprise-grade software without compromising resilience, reliability, and security.

Problem

Complex end-user applications are heavily coupled, even with pure microservices architectures, making developing new features or maintaining old ones difficult.

Solution

A cloud-native super-architecture style called “Micro apps.” Micro apps focus on the seamless unification of isolated and agnostic applications that individually solve specific use cases, which together comprise a greater system. All applications share one service mesh, one authentication and authorization manager system, one secure gateway, and a catalog of services.

Microapps Teams Fundamentals

This software development is achieved by running specialized applications that focus on specific business use cases. Each application has its own development and business team working together as one. As a result, all applications are part of a greater application or system that responds to the whole business strategy.

Architectural Design

“Cloud Native Micro apps” is a super-architecture that embraces other architecture styles to build complex systems. It extends the concept of containerized microservice architecture and self-contained systems to the UX/UI domain. The current trend is to create feature-rich and powerful browser or mobile applications, also known as single-page apps, which usually sit on top of microservices. However, other web architectures are still relevant, such as server-side HTML or AJAX. Until today, there exists an architecture style that reconciles different architecture types and technology stacks in one system.

The idea behind Micro apps is to think of isolated interfaces (uses cases) owned by independent teams. Each team has a specific business mission that they care and know about, making them experts in developing end-to-end business functionalities, from the database to the user interface. Teams can expose services to other teams as well.

This architecture style seeks reliability, scalability, security, and adaptability. To achieve these goals, the design must be as simple as possible. The following are the minimum required components:

Service Mesh: A layer that controls how applications share data and the gateway.

gateway: or proxy server that will interface the internet with the system. The proxy might extend additional services like firewall, web filter, cache, API gateway, etc. The goal of the proxy is to centralize in one single component all the apps contained in the system while controlling the access and authorization of each request.

Identity and access manager: resource to manage all user authentication and access.

resource: Any application or service that provides services to one or more apps. Resources are considered critical and must implement with high availability.

Application: Any app or service intended for final users is routed by the gateway inside the service mesh. Its access is controlled by the Identity & Access Manager.

Interfaces: Access to external resources or services outside the Mesh. Usually, third-party services are in a private or public network.

Implementation Principles

• Everything in the system is a service

• Every service is one or more services interconnected

• A service is considered a resource if they provide services to other services

• A service is considered an application if its purpose is to provide services to final users

• A resource is a shared and critical service

• Each application has its own life cycle

• Each service runs individually and isolated

• Each service has its own business owner

• Each service shares the same hierarchy level

• Each service is responsible for its interdependency

• Services are technology agnostic

• All services share the same gateway, service mesh, and Identity & Access Management

• Services can share databases

• Zero trust is obligatory

• Two services or resources cannot do the same thing

Best Practices

• Applications follow a unified UX/UI framework

• Applications and services run distributed and stateless

• Use an app integrator for consistent UX

• Test at the application level

• Organize the team based on the business use case

• Be sure there is only one team leader or product owner

• Follow the best testing practice for each stack

• Use the right stack for the right app

• Do not over diversify the stack

• Contain each application individually

• Keep all codebases at a similar level of maturity

• Build services that can communicate with each other

More best practices

Microapps Characteristics That Make it a Winner

• Highly maintainable and testable

• Loosely coupled

• Independently deployable

• Organized around business capabilities

• Organized by small, specialized, and efficient teams

• Technology agnostic

• Highly scalable

• Multi-cloud and edge by default

• Mix and match architectures

• User-centric approach

• Focus on uses cases, not technology

• Portable

More characteristics

Microapps Benefits

• Smaller, more cohesive, and maintainable codebases

• Scalable organizations with decoupled, autonomous teams

• The ability to upgrade, update or rewrite parts of an application in an isolated mode

• Allows for hyper-specialization

• Independent deployment

• Multi-stack

• Security is monitored as a whole, but risks are distributed and isolated to apps

• Testing is isolated

• End-users could perceive a seamless and reliable experience

• Errors are constrained and contained to specific apps

• It is cheaper to run

Microapps and others

By default, micro app architecture is designed to embrace other styles prioritizing the achievement of business goals without sacrificing reliability, security, scalability, and performance. Micro apps are an extension to the microservices architecture, taking advantage of the containerization advances achieved with the introduction of Docker in 2011.

• Monolithic architectures focus on a heavily coupled code base that contains all the components of an application. Monolithic architectures are very rigid by design but easy to develop and deploy until a certain point of complexity. Unfortunately, many legacy applications run on a monolithic architecture. As a result, they are expensive to maintain and migrate. Why Micro apps instead? It helps businesses integrate monolithic applications with more modern stacks while giving them time to upgrade software capabilities.

• Front and Back architectures fix many scalability problems of monolithic architectures. However, the front- and backend remain highly coupled, limiting the ability of the applications and businesses to adapt to new requirements. Why Micro apps instead? It helps specialized teams to keep small code while opening opportunities to migrate into more modern and flexible architectures, such as microservices.

• Microservices focuses on specializing the backend and the front-end separately. However, this architecture puts a lot of pressure on the front-end because that experiences more complexity in building rich UX apps. Teams then quickly experience monolithic front-ends. Why Micro apps instead? It helps separate both front- and backends and unify them by adding a single sign-on provided by the identity and access manager. As a result, developers can expose different front-end applications and backend services.

• Micro-frontends solve the problems microservices created and follows a design to decouple the front-end exclusively under the premise the business has one single app. However, this is not the reality when the enterprise has complex and diverse applications. Therefore, one single architecture is not the solution. Why Micro apps instead? It helps embrace micro-frontends as a clever solution for very complex single-page applications, but it also offers a way to decouple them into a smaller codebase.

Micro apps emerged as understanding the UI as a service, providing best practices to atomize applications into services that can or cannot follow the same UX/UI policies. Instead, this style promotes team specialization, reusing enterprise resources, and gaining the agility to develop new services, opening a new horizon in how to build enterprise-grade software.

Considerations

• Apps with different levels of maturity might create a non-unified user experience

• Duplication of dependencies can create security issues and inefficiencies

• Suitable for well-organized teams

References

Micro-frontends

Self-contained System (SCS)

Micro­service Websites

Microservices

Microservices vs. Self-Contained Systems

What’s a service mesh?

10 Microservices Best Practices for the Optimal Architecture Design

15 Best Practices for Building a Microservices Architecture

Adopting Microservices at Netflix: Lessons for Architectural Design

Author

Jay X Anaya
Software Engineer disrupting How Software Is Made On Earth And Mars 🚀
Contact me