In recent times there is a lot of talk about “micro-services”, but what are they actually, and how can they be used effectively and profitably?

In recent times there is a lot of talk about “micro-services”. This sudden surge in popularity in itself is remarkable: never has so much attention been paid to a style / practice of software architecture. In fact, the subject of software architectures has always been the prerogative of sector specialists, and seeing such a subject echoing across various media certainly leaves us amazed.

Micro-service architectures (a.k.a MSA) are used for the creation of application service layers of systems or platforms. The architecture, at an elementary level, consists of a set of processes (micro-services) that interact with each other. Each micro-service behaves independently from the others and is able to communicate via the network by means of structured synchronous or asynchronous software interfaces (e.g. REST, Message Queue,…). Each micro-service deals with managing a resource or a business function, and has its own technological independence (languages, frameworks) and its own persistence layer. A good design in micro-service contexts also allows you to divide the implementation work amongst several potentially independent teams.

Seen from this perspective, therefore, any given single micro-service is not very different from a classic application service layer on a limited perimeter of functionality. So how can a technical artifact such as this MSA make so many waves? Is it really innovative? Is it really a “game changer”? Or is it simply yet another reinterpretation of concepts that are by now either best-practices or commonplace?

From a purely technical point of view, and in relation to the single micro-service, the answer to the last question is “there is no big difference”.

The key to success basically stems from micro-service architectures being the evident apex of a whole series of other methodologies and technologies: Agile, API First Design, Behavior Driven Development, Code Infrastructures, and DevOps just to name a few.

In fact, when evaluated together with the latter technologies and methodologies, MSA assume, to all intents and purposes, the characteristics as to be a “game changer”.

Why adopt an MSA-based solution?

On the internet one often comes across endless lists of advantages and disadvantages resulting from the implementation of a micro-services architecture; so many in fact that the reader ends up confused and at times, overwhelmed. In this article, I summarize some of the significant advantages that may justify the adoption of MSA.

Let’s start by making a distinction between purchasing an MSA-based solution and building one. Clearly, the advantages one obtains in the case of ‘purchase’ also apply in the second case – building the MSA – after the necessary effort has been expended for the first realization.

In the first case (purchase) the solution has the following features “out-of-the-box”:

Independence from the environment. The solutions are based on ‘containers’. Therefore, provided you have an orchestrator available (ex: Kubernetes, OpenShift, Mesos), it can be installed “on-client-premises” or on any public cloud provider and can be relocated if necessary.

Independent scalability. Each micro-service can be scaled (replicated) independently of the others by adapting the entire solution to the required load. Eventually, for impulsive loads, the single micro-service can be down-scaled to zero and activated only when needed.

Limited functional decay. Since the micro-services are independent of each other, the failure of one of these would not result in the malfunction of the entire system but rather, the malfunction is only limited to the affected micro-service.

Quick, “hot” upgrade. Each micro-service can be updated independently from the others in a “plug & play” fashion. It is also possible to update the entire solution very quickly with zero to limited disruption (minutes vs hours).

If, however, you decide to create a solution from scratch (or to migrate an existing solution to a MSA), the architecture in this second case has the following features:

Parallel realization. Since the micro-services are independent of each other, it is possible to parallelize their realization thereby decreasing the Time to Delivery, and consequently, the Time To Market.

Technological independence and polyglotism. The individual micro-services can be created with different languages, frameworks and technologies. This allows to use the technology more in line with the need imposed by the business function that the micro-service supports, and to exploit the skills already available in the various teams.

Reusability of artifacts. Some micro-services that exhibit standard functions (ex: logging, auditing, accounting, file storage) may already be available and can be used in a “plug & play” logic in the context of implementation.

Maintainability. Each micro-service is replaceable with a different and improved version as long as it respects its service interface. Also, since its source code is typically relatively small, it is easily maintainable and testable.

Expandability. Should it be necessary to expand the functionality of the system, it would be enough to add additional micro-services.

Is it always advantageous to build microservice architectures? Not always. Such an architecture has been shown to be effective for feature-rich systems or systems that are planned to expand in the future. If the implementation were small and its perimeter perfectly defined, other architectures would be more “cost effective”.

Skills necessary for introducing MSA into your Company:

MSAs, like all distributed architectures, require the presence of a Software Architect for their implementation. This figure is increasingly flanked by figures, hitherto scarcely present, such as DevOps Engineers, Testing Engineers and Cloud infrastructure Architects.

The work complexity moves from coding (relatively simple once interfaces and functionalities are defined) to planning and design. A revision of the design patterns is necessary to meet previously circumventable or non-existent problems.

The advent of MSAs led to some existing terms being reinterpreted, and even the coinage of new ones. Some noteable examples include: Event Sourcing, CQRS, Circuit Breaking, Saga, Eventual Consistency, API Gateway, Service Mesh.

Creating a platform based on this architecture introduces two important themes that must be taken into account: cultural change as well as up-skilling and re-skilling of resources

The main success factors behind an MSA implementation are the approach and methodology rather than the technologies themselves.

MSA implementation success-cases:

From a global perspective, MSAs came into being at the Enterprise level about 6 years ago. One of the international forerunners of MSA implementation was the Netflix video streaming platform, followed almost simultaneously by the Spotify audio streaming service, the AirB&B booking platform and the Zalando clothing E-commerce site. Each of them has contributed to the success of MSA by sharing their experiences and “lessons learnt”.

Perhaps the most emblematic case of business success due to the use of microservices architecture is that of Amazon[1]. The original website for the purchase of online books was in fact a monolithic application, in which adding new end-user functionalities was very complex both from a technical and organizational point of view, and which offered limited scalability in the event of peak requests.  Amazon has therefore embarked on an application re-engineering path with microservices dedicated to individual business features (such as the shopping cart), each managed by a single development team, and standardized and automated release processes with CI / CD practices. This has allowed Amazon to create millions of new features every year, and to gather new and significant skills in the creation of highly scalable infrastructures, which led to the founding of AWS in 2006, generating a new business for the company.

Following these successful examples, there are currently countless enterprises in the B2C / B2B sectors that are cresting new platforms that are ‘MSA-by-design’ or are migrating them from different architectural styles to a more MSA-oriented one.

For some years now, large Italian companies have also been migrating some of their business systems geared for B2C or B2B use towards a MSA style recognizing its applicability and benefits, and driven by the market pressures such as Digital Transformation and migration to the Cloud.

MSAs, today, have nearly become the de facto standard for building the service layer of systems and platforms.

Microservices @Bip xTech: an end-to-end offer

Bip xTech has been following its customers for years in the introduction and implementation of innovative technologies. Among these, in relation to software architectures, are micro-service architectures (MSA), serverless architectures (BaaS, FaaS), and event-driven architectures (EDA).

Our roster of professional figures includes Software Architects, Infrastructure Architects, DevOps Engineers, Testing Engineers and Developers who are able to cover end-to-end any given implementation cycle.

Since 4 years, nearly since the advent of MSA, Bip has been supporting our customers in the design and implementation of enterprise applications based on MSA, mainly in B2B sector.

Towards the future, together

Knowledge of technology and the ability to deliver are the necessary and indispensable ingredients for any technological achievement, but they are not the only ones.

Bip has always guided and accompanied its customers in the development of their business and helps to govern projects on all scales of complexity.

Knowledge of the domain and the ability to manage projects combined with technical competences are the key to the success of projects, always aimed at maximum benefit for our customers.

---

If you are interested in learning more about our offer or would like to have a conversation with one of our experts, please send an email to [email protected] with “Microservices” as subject, and you will be contacted promptly.

---

See you with the next article that will deal with the field of “serverless architectures”!

[1] Werner Vogels “Modern applications at AWS”, https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html