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.
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 macro-services due to their size and goal to be even too reusable.
The problem of macro-services is the excessive pursuit of universality. Companies tried to generalize and canonize the underlying data model company-wide. 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 macro-service 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.
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.
Micro-service architecture also contains many disruptive features for today's organizations. The most challenging of which is probably that the micro-service 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 micro-service 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 micro-services. According to the puritanical definition of micro-services, frends is also just a development platform that supports CI / CD processes. It enables the development, execution, and management of an AP that can be flexibly scaled as needed in a container environment.
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
The term miniservice originated in the middle ground between macro services and micro-services. The mini-service is essentially like a micro-service without the requirement of complete independence: the mini-service can be loosely coupled from other systems and interfaces.
Similarly, the mini-service can, if necessary, own and manage its data, ie, include its data repository, though this is not mandatory by definition as it is with microservices. Often the granularity of a mini service, meaning how large entities and functions the service contain, is also close to the microservice. The mini-service - like the micro-service - must also be independently installed and as scalable as possible. However, unlike in micro-services, scaling must consider the limitations of even loose dependencies: does the system connected to scale with the mini-service, 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 micro-services when, in fact, the mini-service 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 by HiQ has been a development platform for mini-services for more than a decade. Today, frends is the most modern API platform on the market, which acts as a micro-service platform or mini-service platform when needed. It is essential to understand that mini-service capability is not a separate area but a part of the capabilities of a modern integration platform.
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
In its "Innovation Insight for Miniservices," Gartner predicted that mini-services would be the next architectural paradigm to become a hit in 2018 and 2019. History proves that they did not become a hit, but mini-services became part of the everyday life of integration development. Mini-services 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 move its other core systems to the museum. 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