That which does not kill us makes us stronger
Microservices adoption in traditional companies.
The introduction of microservices in big, traditional companies that do not belong to the software industry carries several difficulties that may put off or directly discard the decision of the adoption. In this article we put a close eye to those difficulties and provide some guidance to make a conscious decision.
The development of microservices requires the developers and infrastructure team knowledge in a certain amount of tools that were not traditionally used in the last decades. There is a really tough technical ramp-up that at a first glance is, to start with, a great difficulty. Although, what this fact hides behind is that actually the required change in microservices adoption is not a change in tools or in certain particular technologies but a change in paradigm. The practices needed in development, quality assurance, infrastructure handling for the implementation of these types of architectures, imply a deep conversion to a new methodological culture in the management of technological resources and the organization of people around that management.
In what development of software services is concerned, the difficulty is in the modelization and analysis using Domain Driven Design, an approach that makes possible the definition of the scope of each microservice and its alignment to the business domain. Besides, it’s of great importance the assimilation of the reactive manifesto as a principle: to enable the creation of autonomous services we have to use asynchronous communication and its support in the programming level, leveraging reactive programming, for example. These types of programming were not part of the toolkit of traditional programmers of traditional languages like java, for example.
When we move to the infrastructure side, the container abstraction of the physical server leads to the need of managing the resources in a flexible manner, dynamically and in mass, which makes us adopt the infrastructure as code approach. This allows us to have horizontal scalability, making possible the elasticity that the reactive manifesto states as one of its principles. The complexity in the installation and maintenance of a container orchestrator on premise, puts us really closer to the decision of moving to the cloud, and leaving that burden to the cloud provider. The cloud adoption is another paradigmatic switch in software production and of course in the traditional way in which the infrastructure is managed.
In the Quality Assurance and Quality Control area, the required transformation is automation. In the same way that hardware resources are no longer feasible to handle one by one, the individual and manual tests cannot be performed without impacting severely the production of microservices and finally its viability.
And finally, all the tasks that have to be performed by developers, infrastructure specialists and QAs, have to be done in an agile way and, as a consequence, in a cohesive small team that will be responsible for the construction and maintenance of one or several microservices. The technical processes required for the flow of artifacts between the different environments to reach production, maintaining their dependencies, adjusting their configuration and verifying their quality requires coding automation scripts and leveraging certain technological components and libraries. Currently, these tasks are performed by a new role in the team: devops. The responsibility of the devops team member is mainly the pipeline (the flow of artifacts) but the view or perspective that this team member has of the production organization makes him a key actor in the delivery process and an important player in all non-business logic coding.
Taking in consideration all these difficulties, we can conclude that starting to build microservices corporately is far away from a plain sailing. To complete this unfavorable scenario let’s add the well known characteristics of a traditional company: no adoption of software development culture, servers in data centers managed individually by a sysadmin IT area, no up to date QA practices with no or incipient test automation and finally a hierarchical organization structure in which each one of the areas implied in the software development project behaves as silos, with no fluent communication or no communication at all.
After all this journey full of obstacles the question that obviously comes up is: Is it worth it? The answer, as we generally are used to is “it depends”. We will not go deep in the advantages of this type of architecture, that we may leave to future articles. Although, maybe it’s enough to remark that a company for which the time to market is of key importance, should consider the evolution to the implementation of microservices a strategic decision to take.
Taking apart the evaluation that we have to go through before deciding to implement any architecture, it’s important to remark that all these preconditions that we mentioned here for the implementation of microservices are requirements that have to be covered for the professional software development with quality. Microservices architecture makes more evident and to a higher degree the need of these requirements. To put it more clearly: what you have not improved till now in terms of software quality and efficiency of organization, you have to do it to implement microservices and receive the full advantages of this type of architecture, that is mandatory to reach the digital transformation.
