Alternative Micro-services architecture

There has been a lot of talk and movement around micro-services. With the current architecture, micro-services provides real benefits, while having some challenges.

WHY MICRO-SERVICES?

Promise of micro-services is for faster development, isolation of failure/management, and scale at deployment by breaking down an application into many separate pieces which work together either through a process that pulls them all together, messaging middleware, or a common datastore. If you are working on a solution that is too large to develop, deploy, and maintain as a single application, micro-services provide you with an architecture that can be used to break the application down into manageable pieces.

WHY NOT MICRO-SERVICES?

A single process application is much easier to manage then an application broken into 100 different processes. Breaking down an application to many micro services means these micro services need to be managed during development, deployment, and operation. Application is still being created from scratch. It is just being broken down into smaller pieces, which introduces an added challenge of managing them. While managing processes is nothing new to operators, managing a large number of processes that change often is not an easy challenge. Concept of DevOps is introduced to take on this challenge, but the end result is added development burden on the operations staff that has proven to be a challenge of its own. Even the development environment needs to be managed with all the many required micro-services for a solution to work.

When deployment is not directly handled by the organization developing the solution, current micro-services architecture is a problem. In the time where even IT is moving towards a one-click deployment, getting a solution based on current micro-services architecture to be easily deployable becomes a challenge.

MICRO-SERVICE PRE-REQUISITES

There is a good article by Martin Fowler regarding pre-requisites for micro-services. He argues that following needs to be ready before an application is broken up into micro-services.

  • Rapid provisioning
  • Basic monitoring
  • Rapid application deployment

Today, much of the above requisites rely on automation using traditional DevOps, often with various scripting languages. Pain of managing managing a number of micro-services through development, deployment, and operation is transferred from manual operation to another development activity now termed DevOps. Many products and services are also becoming available to make the pain a little easier. However, architecture of delivering micro-services has not changed. We are only trying to make it less painful.

ALTERNATIVE ARCHITECTURE

Applications can be broken up into micro-services at the following level.

  • Execution
  • Development
  • Functional

Most of the current micro-services architecture focuses on execution side of the equation. Concepts such as containers and related deployment tools help in taking an application into several separate executable pieces and creating a mechanism for them to work together as a solution. While this can help in isolating failures, parallelize development efforts, and enable scalability, it creates management challenges as number of micro-services needed for a solution increases. Many times, advantages of micro-services could be obtained through well defined application design and approaching application development in a different light.

One of the issues with current method of architecting micro-services is that applications are only being divided into separate execution instances. While it has its benefits, an architecture that enables micro-services in execution, development, and function will provide the many benefits while minimizing the disadvantages of today’s architecture. Alternative architecture will allow an application to be broken down into different execution pieces, development workspaces, and internal services.

Parallelizing development efforts is a need for many organizations. It can be achieved through micro-services, but also through well modularized code design. An alternative method is being proposed by Interactor®, where separate workspaces can be created within a single application instance, to enable parallel development and modular application design.

At its smallest granularity, application can be broken down into its functional services. While using separate micro-service process to achieve this will create a nightmare in application management, it can be achieved through deployment first architecture using Interactor®, where separate micro-services can be created within a single application instance.

Interactor® product provides ability for rapid provisioning, monitoring, and deployment, through its unique deployment first declarative backend that is well suited for micro-services architecture enabling separation at different levels of application.