What are microservices and miniservices?
This article discusses the differences between micro and mini services and the potential of a modern integration platform. It is intended for integration professionals and enterprise architects.
Where did micro-services originate from?
Service-Oriented Architecture (SOA) evolved a dozen years ago. SOA's purpose is to publish reusable business functions and hide business systems of different ages and abilities. The service interfaces made in one project are reusable and available in the next project, which reduces the total costs in overall development. We call these early SOA-based services macroservices due to their size and goal to be reusable.
The problem of macroservices is the excessive pursuit of universality. Companies tried to generalize and canonize the underlying data model on company-wide level. Canonization means that an information object, for example, a client with all its hundreds of attributes is the same company-wide and usable within any context. The reusability results of macroservice development were excellent at best, but the business unit paying the development bill was surprised by the costs and slowness of pursuing universal generality. Such services often became obsolete too fast as the business needs change rapidly. Sometimes, the slowly developed all-around service was obsoleted before it was published. This is the reason why the development of new macro services has been largely abandoned.
The birth of micro-services
In recent six years, microservice architecture (MSA) has grown in popularity. MSA contains the lessons learned from early SOA. They are suitably small services that encapsulate simple business functions and run entirely independently. The goal for excessive universality and canonization was removed as the time-to-market for business functions was more important. Micro-services can also be deployed independently. The nature of micro-services also includes scalability fully independently from other services and business applications. For this reason, cloud platforms are a natural self-scalable platform for microservices.
Microservice architecture also contains many disruptive features for today's organizations. The most challenging of which is probably that the microservice must own its business information. A microservice must be a completely independent business function that scales without restrictions that other systems might cause. This means that a microservice cannot have dependencies on other systems; thus, it is fully decoupled. The micro-service cannot rely on, for example, a business management system or customer information system or anything else concerning its core information. For this reason, the implementation of a microservice architecture requires a significant change in familiar thinking at least for integrators. It is at its best when creating a new backend for entirely new business applications. One could say that MSA is best for application development, not as a traditional SOA that relies on the legacy systems. In other words, use MSA if you cannot use ready-made business systems as a platform and be aware: you will have the costs of full system development, including bug fixing, implementing monitoring, etc. The best-known example of a solution based on a microservice architecture is Netflix.
The frends integration platform can be used to build and publish microservices. According to the puritanical definition of microservices, frends is also just a development platform that supports CI / CD processes. It enables the development, execution, and management of an API that can be flexibly scaled as needed in a container environment.
Make a microservice when ...
- complete independent scalability is a requirement and possible;
- you are developing a new application and need tailored backend;
- you cannot use more cost-effective ready-made business applications.
What is a miniservice?
The term miniservice originated as a middle-ground term between macroservices and microservices. The miniservice is essentially like a microservice without the requirement of complete independence: the miniservice can be loosely coupled from other systems and interfaces.
Similarly, the miniservice can, if necessary, own and manage its data, i.e., include its data repository, though this is not mandatory by definition as it is with microservices. Often the granularity of a miniservice, meaning how large entities and functions the service contain, is also close to the microservice. The miniservice - like the microservice - must also be independently installed and as scalable as possible. However, unlike in microservices, scaling must consider the limitations of even loose dependencies: does the system connected to scale with the miniservice, or does an intermediate data warehouse need to break the dependency on the back-end system or service. The limit to scalability is almost always formed by the legacy and performance of connected Legacy systems and their interfaces and data warehouses.
Often IT-suppliers are seen marketing their microservices when, in fact, the miniservice with its loose dependencies is revealed from the under-the-hood. This is called "microservice-washing". Microservice-washing is done for two reasons: not understanding what a microservice really means or consciously wanting a trendy term for your marketing use.
The frends integration platform has been a development platform for miniservices for more than a decade. Today, frends is the most modern API platform on the market, which acts as a microservice platform or miniservice platform when needed. It is essential to understand that miniservice capability is not a separate area but a part of the capabilities of a modern integration platform.
Make a miniservice when ...
- general use is important;
- time-to-market is the most important thing;
- you build services on top of existing systems;
- you want your service production to be based on the DevOps model.
The near future of service architectures
In its "Innovation Insight for Miniservices," Gartner predicted that miniservices would be the next architectural paradigm to become a hit in 2019. History proves that they did not become a hit, but miniservices became part of the everyday life of the integration development. Miniservices represent a pragmatic architecture that considers the modern environment and responds well to the needs of a digitalizing world. For example, a company developing a mobile application to support its own old business may not be ready to discard its other core systems. A typical overkill solution is to build redundant microservice architecture to line-of-business systems just for the sake of microservices when miniservices would have fulfilled the business needs.
Sources: * Innovation Insight for Miniservices, 2/21/2017, Anne Thomas, Aashish Gupta * (requires paid Gartner service)
*Microservices, 25.3.2014, Martin Fowler, https://martinfowler.com/articles/microservices.html