Decomposing an application into smaller, functional components is an effective way to reduce the complexity of development and update processes. Each of these pieces can be self-contained, incorporating just a few lines of code, without losing the application's underlying business logic.
Today, there are two unique approaches development teams can use to achieve this type of decomposition. One of these is to incorporate microservices development, which focuses on turning otherwise bulky applications into neatly organized collections of functional, back-end logic. The other -- micro app development -- enables software teams to dismantle an application's UI into similarly function-based components.
While many development shops may find themselves well-served to adopt both techniques, there are still some major differences between the two that are important to know about before diving in. Let's go over those differences to better understand when, why and how these are both effective application design approaches.
What are micro apps?
A micro app is purposefully designed to accomplish a single, UI-related application task. Rather than rewrite the same piece of user interface for an application, developers can configure an existing micro app to meet their needs. This helps ensure consistency across user interface experiences, and it provides a quick way to extend and customize individual UIs.
Developers design sharable micro app components for reuse across multiple application interfaces. In some cases, this can also help minimize the time spent dealing with compliance and security approvals. The efficiency this adds to overall development processes allows teams more time to focus on new feature additions and user feedback.
While there are all sorts of UI types that micro apps serve, many use cases revolve around social media and messaging applications. For instance, Google Hangouts, WeChat and Facebook's Messenger likely put a sizeable number of micro apps into action.
What are microservices?
Microservices refer to an architectural approach that breaks complex applications into collections of lightweight, loosely coupled services. Rather than interact directly, these services communicate primarily through a mix of APIs, event triggers and other integration components. The independence this design style fosters allows development teams to build, version, scale and deploy individual services and feature sets in isolation, and can also provide increased levels of fault isolation and resilience.
Because microservices are meant to align with a single business responsibility or function, the design principles associated with microservices development dictate that individual services must remain lightweight. To that end, many experts also stress that these services should retain as little state information as possible. If persistent state information is a requirement, it's recommended to manage that data through an abstraction layer, such as a sidecar proxy.
Today, many of the use cases for microservices revolve around refactoring legacy e-commerce applications buried in complex webs of business processes and functional logic. However, many organizations are using microservices to revamp internal applications related to finance and HR, as well as build sophisticated real-time data processing systems. On top of that, an increasing number of development shops are also looking at use cases for microservices in AI and IoT scenarios.
Micro apps vs. microservices
The primary difference between microservices and micro apps lies in their relative scale and placement within the stack. A collection of micro apps will reside and operate within the front end of a larger, overarching microservices-based infrastructure. The microservices, meanwhile, are mainly concerned with things like back-end communication and data retrieval processes.
The process of working with micro apps is relatively straightforward -- a web or mobile application may consist of multiple micro apps that are simply deployed to the same server or across multiple, related servers. Microservices adoption, on the other hand, often represents a comprehensive restructuring of an organization's software architecture and development strategies, especially for large-scale legacy applications.
From a storage perspective, the micro app approach leaves a minimal memory footprint. Micro apps don't usually handle any storage processes on their own, instead relying on separate storage components that move between the front and back end. While it's not a recommended practice, microservices are still capable of storing their own data, such as state information and transaction histories, when needed.
Despite their simplicity, however, micro apps will work well only when development teams clearly define contextual and functional boundaries between the individual modules within the UI. The borders between those high-level modules should correspond to things like user types, unique feature sets and, if possible, the structure of the development team itself. This will require communication and cooperation between individual developers and development teams, as well as any operations or security teams that support the associated applications.
Meanwhile, complexity is still a major differentiating factor between micro apps vs. microservices. The decentralized nature of microservices necessitates frequent messaging between them, often through extensive communication procedures. These high levels of messaging can easily hurt network performance and integrity when left unchecked, and it means that microservices components must be closely and carefully monitored. This is complicated, given their ethereal nature, and almost always requires the support of automated management tooling.