Microservices Architecture

Process-level, Coarse-grained Components

A Microservice is a unit of software that runs in its own process and is independently replaceable and upgradeable. Each such service can be thought of as a unix-pipe in the classical sense, receiving one or more inputs, applying business logic and producing one or more outputs. Fiorano Microservices are 'coarse-grained' but not so big and complex as to have hundreds of interfaces. Each service has a few inputs and a few outputs, though there are no actual limits imposed on these numbers. By default, each Fiorano Microservice runs in a separate process, though it is possible to group multiple services and run them in a single process.

Application systems are composed of multiple services that interact with each other either via request/reply or via messaging. Since the underlying framework is standards-based JMS, which supports both request/reply and publish-subscribe, the implementation does not require any proprietary APIs. Importantly, if part of a system needs to be replaced/redeployed, then only the corresponding Service is replaced (or upgraded). There is no need to stop the overall application to replace a given service. This makes it possible to partition and redeploy an application at runtime, on an as-required basis.

Organized around Business Capabilities

Each Fiorano Microservice typically implements bounded business functionality. The Fiorano Microservice design approach attaches a User-interface (both for configuration and for interaction) with each Service. When a large system needs to be developed, the developers map the system to multiple components and then each component is implemented as a Fiorano Microservice, where each Service may (if required) also have a user-interface component associated with it.

When a solution needs to be changed or modified, one only needs to modify and/or replace a particular Microservice (or set of Services) in the system, without affecting the rest of the running Services.

Services as Independent "Products"

Each Microservice created on the Fiorano platform is an independent product in itself. Each Service is self-contained, includes all dependencies (such as libraries, etc.) as part of its packaging and is developed, tested and deployed independently of other services. As such, whenever a Service is modified or has functionality added to it, the changes can be made available to existing applications that use that Service at very short notice. The Fiorano runtime in fact allows "hot replacement" of services, where an upgrade to a service can be made at run-time, without stopping the overall application. Such changes are not allowed, for instance, in 'process-centric' integration platforms (those based on BPEL and associated standards).

End-point intelligence, raw transport

Fiorano Microservices are completely decoupled from and independent of each other and all business logic is managed by Microservices. Applications are built on the platform by choreographing Microservices using simple messaging (JMS) or REST protocols, in contrast to complex protocols such as Ws-Choreography or BPEL. Importantly, all logic relating to 'infrastructure specific' operations such as routing, caching, transformation and the application of business rules, etc. are also implemented in the form of "Infrastructure Microservices", allowing the transport to be a pure JMS server with a very limited amount of additional functionality that relates to deployment of Microservices as Agents over the cloud or enterprise network. The Fiorano runtime system allows the routing of data between Microservices to be specified as a simple graph that connects outputs to inputs, with the Microservices themselves deployed across a hybrid network.

Decentralized Governance and Multi-language support

Since each Fiorano Microservice is fully decoupled from other services, it can be developed in any supported language and governed independently. Fiorano supports the development of Microservices in Java, C, C++, C#, JavaScript and other scripting languages. Each Service can be governed, modified, replaced and deployed independently of the other, providing flexibility to both development and deployment teams.

Decentralized Data Management

Each Fiorano Microservice manages its own data as part of the business logic implemented in the Microservice. A centralized data-source, as in the development of a classical monolithic application, is not needed. Each Microservice manages its own persistence layer, which may be different instances of a single database technology or entirely different database systems in different Microservices. There are no "global variables" in such an architecture since there is no centralized data-store provided by the platform. All information is carried as part of the payload that flows between Microservices distributed across the network.

The use of separate persistence mechanisms across different Microservices mandates that error-recovery in distributed transactions be implemented by compensating operations. The emphasis in a Microservices architecture is on transactionless coordination between services, with transactions being individually managed within each Microservice using the inbuilt JMS support for distributed transitions or other Transaction Processing Monitors.

Infrastructure Automation

The Fiorano platform allows Microservices and applications assemblies created using the services to be moved between Development, QA, Staging and Production environments at the click of a button. Profiles for each of these environments can be set for each deployed Microservice, allowing the platform to lookup and apply the relevant profile at runtime. This movement across environments can be accomplished either via the provided graphical tools or via Scripts.

Failure detection and Exception Handling Services

The Fiorano Microservices platform uses JMS messaging as the default transport between Microservices at runtime. Since each service is built and tested independently of others, handling failures in a Microservices architecture is more complex when compared to monolithic application design. The Fiorano platform overcomes this problem with the use of an Exception Handling Microservice. For each application flow, a centralized Exception Handler can be specified and configured to manage all exceptions. All running services are also monitored in real-time, with configurable alerts based on a number of parameters including backlogs on queues/input-ports, run-status of components and more.