Architect Angle


The Rise of Microservices (µServices)

Microservices are an increasingly popular approach to architecting applications. They are simple, single-purpose, lightweight architectural components that enable you to deliver software faster. The aim of Microservices is to deliver extremely agile software solutions which are easier to maintain and manage.

 

Architecture all the Way Down!

 

As complexity is an issue at all structural levels, modularity and loose coupling must apply at all structural levels.

 
The increasing popularity of Microservices, while perhaps suffering from a dose of hype, is actually addressing, and being driven by, a fundamental issue.

Modularity and loose coupling have silently driven the IT industry over the last two decades, underpinning a number of well-known technology trends including:

  • Business Process Management – The codification and modularization of business workflow.
  • Service Oriented Architecture (SOA) – The move from rigidly coupled applications and business systems with proprietary protocols to loosely coupled ‘services’ accessed via common protocols.
  • Cloud Computing – The decoupling of applications from the underlying compute resources upon which they run, encouraging a more modular runtime and allowing services to be remotely deployed and accessed.

Yet, each of these transformations only addresses a small portion of the fundamental problem.
 

Within every SOA solution, within every Cloud deployment, lies a rotting codebase that continues to accrete Technical Debt.

 

It gets worse…

As a pragmatic Architect, you understand that applications and business systems must be able to evolve to meet new unforeseen business requirements. Also, different Business Units may require the same functional solution but need very different runtime personas. For some, the ‘Service’ may need to be optimized for performance, responsiveness and data durability, for others a simple to manage and low cost ‘Service’ may be of primary importance. And yet traditional middleware ‘strategies’ invariably lock your organization into a particular architectural approach and usually a particular implementation.

Therefore, a successful architectural solution must:

  1. Accommodate diversity and the evolving nature of business requirements
  2. Enable optionality in each solution’s non-functional design

And so a successful architecture must be modular in nature.
 

The Service Fabric – the Microservices runtime

The increasing popularity of Microservices, the decomposition of a large system into a discrete set of smaller services, is a direct response to this problem. In principle, more modular Microservice solutions lead to applications and Business Systems which are easier to maintain and adapt. Yet, it is essential that these Microservices are simple to deploy, manage and maintain in highly distributed runtime environments. The Paremus Service Fabric directly addresses this management issue.

The Paremus Service Fabric is the industry’s leading, standards-based, Microservice runtime. The Service Fabric enables software components to be dynamically deployed and configured, along with the middleware components upon which they depend.

 

The Implications are Profound

The Paremus Service Fabric is agnostic to your architectural choices. Meaning?

Your Microservice architecture is no longer locked into a runtime middleware ‘stack’. When your applications are hosted by a Service Fabric, the runtime environment is no longer the inflexible stovepipe into which you inadvertently lock your applications and systems.

Rather, the Service Fabric dynamically responds to the runtime requirements of each deployed service. Middleware, if required, is dynamically deployed, configured and maintained, just like any other software component. Hence, the Service Fabric enables you to use the most appropriate architectural patterns for each business solution and incrementally evolve these over time.

For Greenfield applications, the Service Fabric enables the full power of OSGi, the open industry standard for Java modularity, to be leveraged. Without code change, an application may be evolved from a simple entity deployed to a single runtime Fibre (a container in the Service Fabric), to a network of distributed, horizontally scaled, synchronous or asynchronous Microservices with adaptive load-balancer, circuit breaker or back pressure behaviors, as required.