The Microservices buzz: Will it benefit your Enterprise IT?

Microservices is almost a buzzword today and most enterprises are embracing microservice architecture (MSA) to integrate services, applications, and data. 

Even in Sri Lanka, we’ve seen a trend of enterprises using Cloud-based, infrastructure as-a-service offerings and lightweight containers such as Docker. MSA, being highly focused on building small, reusable, independently scalable, and independently disposable services, goes hand-in-hand with these new trends. Therefore, there’s scope to significantly increase the usability of Cloud-based infrastructure offerings and reduce overall cost, making it a perfect fit for tech startups too.  

Before diving into the implementation part, let’s consider the essential components of an MSA and what you need to do first as an enterprise. For starters, there needs to be a certain level of organisational restructuring and, more importantly, a mindset change before embracing this software development methodology.  

Tech team shake-up to get things rolling 

A typical software company comprises teams that are formed based on technical expertise, e.g.  a database administrator (DBA) team, server administrator, quality assurance (QA), UI/UX, etc. In most cases, the ownership of a software solution is shared among these teams – for instance, design and maintenance of the database is the responsibility of the DBA team while defining user experience (UX) and design of user interfaces (UIs) is the responsibility of the UI/UX team. 

MSA discourages this traditional technical expertise-based team formation and instead promotes team formation based on business capabilities. What this means is a single team is responsible for all aspects of one business capability starting from requirement gathering to running and maintaining production level services. Such a team should ideally comprise individuals with technical expertise required to deliver underlying business capabilities, such as DBA, QA, and UI/UX expertise. And the key benefit of doing this is that it significantly improves business-level awareness within the team and enables them to deliver more focused, coherent, and a connected business level experience to end users. In the old-world architecture, a particular DBA expert will become involved in a set of projects at the technical level, but will focus less on understanding the business-level problems that each project is trying to solve; the DBA expert will more or less be limited to completing an assigned DB-related task only. With MSA, the particular DBA expert will be a part of the team from start to end being involved in every stage of the deployment and not just focus only on the database design. The expert will also continue to own the database and will gradually optimise the database as the business domain evolves. The real benefit here is that the DBA expert within the team will take ownership of identifying the required improvements and mismatches by closely analysing business domain changes as and when they happen. Nevertheless, it’s a misconception that MSA specifies the need to have a DBA expert, a UI/UX expert etc. in each and every team, which is clearly an overkill. 

Offering the benefits of single-scoped services 

From changing the way your team should be setup, let’s now look at the benefits it offers in terms of services. Traditionally, software systems are designed and implemented as a set of layers, and this paradigm is known as a layered-architecture. In such a system, each layer is defined based on technical details and not on business domains. For example, a system may consist of three layers (presentation, business logic, persistence); the presentation layer is purely about the implementation of user interfaces while the persistence layer focuses on how to persist and retrieve the data that belongs to the entire system. 

In comparison, MSA advocates a principle known as single-scoped services - this means subcomponents of a system should not be separated based on underlying technology and should instead be based on their business domains. To explain this more clearly, let’s consider an example of an online shopping cart system; here, inventory management, payment management, and the customer store should be defined as separate subsystems and each must have the capability to be designed, implemented, maintained, and replaced independently.           When a particular subsystem interacts with another, the underlying communication should be based on standard protocols, such as HTTP or MQTT, and should use standard message formats, such as JSON, XML, etc. 

By no means 

a silver bullet 

Like any other technology, MSA too should not be considered a silver bullet. While it solves many traditional problems, it also introduces a set of new challenges. In fact, some experts even say that MSA is possibly just a shift of complexities from one layer to another. 

When considering the key challenges, security can be described as an important one. In traditional monolithic applications all business capabilities and layers are packaged into a single unit, hence handling security when communicating between capabilities is not complex. However, with MSA, these communications happen over a network and are vulnerable to all types of network issues. To address this, the enterprise must have proper security mechanisms in place that support secure inter-service communications. 

Moreover, MSA involves a collection of services and it’s possible for some services to fail independently without affecting others. Yet, this kind of behaviour could trigger a failure in the entire system. To prepare for such challenges, the enterprise must include a very sophisticated monitoring system.  

It’s clear that adopting MSA will offer many advantages to an enterprise as it aligns well with modern Cloud and devops practices. But, it’s equally important to note that it needs to be done with some degree of caution given the many challenges that follow. 

       

(The writer is Associate Director/Architect at WSO2 and primarily focusing on the WSO2 Identity and Access Management offerings, he also specialises in JavaEE, Spring and integration technologies. He is also a key contributor of MSF4J Microservices framework.  In addition to his product development efforts at WSO2 he is a PMC member of Apache Axis and Apache Web Services projects and currently serves as the Vice President of the Apache Web Services project. He can be reached email [email protected]).