Microservices or agility at the service of its customers

2019-02-14T14:16:53+02:002019-01-22|Innovation in the spotlight|

The adoption of mobile internet has profoundly modified the way in which consumers buy and interact with applications. The rhythm of the change is fast-paced. The need for speed in the development of applications is greater than ever. Armed with superior agility, newcomers are questioning positions acquired. More and more big accounts are reacting by placing their bets on microservices.

To be more efficient than their competetitors, some businesses aspire to greater flexibility and greater independence. Benefiting from an Agile structure has appeared as a necessity. But too many companies still keep architecture and an organization which does not lend easily to its adoption.

This is a mistake because agility follows one main objective: to reduce delays to market in order to improve customer experience. That involves, therefore, an optimized organization without being based on monolithic architecture.

With such architecture, agility will be a very difficult objective to reach. There are in fact too many restrictions:

  • All processes are closely paired and function as a sole service. That means that if one process of the application has peak demand, the entire architecture must be scaled.
  • Several application functionalities cannot be created and deployed at the same time.
  • The addition or improvement of functionalities of a monolithic application becomes more and more complex as the source code increases.
  • The monolithic architecture has increased the risk of application unavailability. In fact, several processes, dependant and closely paired, increase the impacts of one process failure.

The result is that this complexity limits experimentation and makes the implementation of new ideas difficult.

On the other hand, microservice architecture is a set of architecture patterns capable of responding to monolithic upgrading problems.

Appearing in 2012 and popularized by Martin Fowler (this computer scientist is author of a reference work on refactoring) the term ‘’microservices’’ represents an architectural and organizational approach of software development in which the software is composed of little independent services that communicate on well-defined API. Microservice architecture facilitates the growth in supporting applications and speeding up their development. It allows innovation and a reduction of time-to-market of new functionalities.

Netflix, the model

Microservices are registered in an Agile approach which allows a response to specific expectations through the creation of small applications or services with limited perimeter and on top of that, added value for customers.

This major interest is explained by the fact that small I.T. and operational teams can work together on a project. With this type of project, an application is created as independent components which execute each application process like a service. These services communicate via a well-defined interface using light API. The main objective of the implementation of microservices is to divide the application into a service separated for each functionality kernel and API services, and to deploy it independently on the cloud. Netflix has been one of the first companies to adopt microservices.

To simplify, this architecture presents some interests:

  • If one of the application services does not function, the system continues to function.
  • Different languages and technologies can be used to create different services from the same application. This also reduces the negative impacts resulting from one technological option that doesn’t last. In the worst case, a microservice can be quickly rewritten and without excessive costs.
  • Individual components can be scaled according to needs (they are deployed on independent servers or dedicated containers). It’s not necessary to scale all components together.


Two pizzas!

But be careful that a microservice does not become as ‘’big’’ as a monolithic application. To want to be as big as the cow, the frog swelled up ‘’until he burst’. In relation to our subject, this means that agility researched in such a way will fall flat. The microservice won’t be as scalable because it won’t be centered anymore on a sole and unique functionality.

The size must be adjusted all the time. Agile development methodologies allow access to a very practical dashboard to follow a microservice. If this becomes slower and less productive, it may be time to envisage the decomposition to allow teams to be more efficient. Jeff Bezos of Amazon calls this ‘’the two-pizza team’’: a team that is quite small (with Dev, testers, administrators, product administration, etc.) to be fed with only two pizzas.

Before taking the decision to deploy them, make sure you also know the automatisation tools which are available to you and which also support your microservices.

To deploy several services is more difficult than deploying one service. To reach independence of application services, a team must be able to cover the entire life cycle. This could require organizational changes, as well as increased configuration management. For each microservice, you must create a construction pipeline and dedicated delivery which will be taken over by fast interconnections and at low latency between each service.

Moreover, making HTTP requests (via an API customer) and handling them (via API Java for RESTful Web Services or JAX-RS) between microservices is more laborious than relying on one monolithic application.

In view of the maturity of DevOps with containers (vs the heaviness of a virtual machine which has its own operating system), microservices let you make of the most of agility and reinforced productivity.

But the deployment of microservices is not the universal remedy. It won’t resolve all the I.T. needs of your company. However, you can use microservices with other existing architecture. The priority is to find the good compromise.

2019-02-14T14:16:53+02:002019-01-22|Innovation in the spotlight|
the digital agitator
our newsletter
media library
our ressources
the digital agitator
our blog