Microservices Architecture – An Overview

Microservices is one of the most popular tech buzzwords – is gaining a foothold in enterprises of all sizes. Major companies, from Netflix to Spotify have acknowledged and promoted the values that microservices can provide. However, not many have a proper idea of microservices.

What are microservices? And what does a microservices architecture mean to application development in today’s enterprises?

Microservice Architecture (Microservices) is a method of developing software focused on building single-function modules. Microservices are a way to create applications that break down monoliths into smaller, individual services, that can be changed and developed independently from one another. Organizations that use microservices can see dramatic increases in agility and productivity because development is independent of any specific coding language. In other words, development teams are able to use the language tools they’re most comfortable with and still achieve synergy within the application development process.

Why the buzz around Microservices?

Let’s briefly explore the evolution of software architecture to understand.

• Monoliths

Towards the end of the 90s, most software were monolithic. In a monolithic design, the user interface and the data access code are combined into a single, self-contained program. Monolithic software design being self-contained, the interdependent nature posed a potential threat such that a failure anywhere in a program can cause the whole application to come crashing down. Some other issues that posed challenges:

• Reduced agility: The application’s codebase is released all at once. Developers need to code and deploy the entire stack. Rebuilding the whole application takes time and slows down the pace at which new features can be delivered.
• Complexity: Large applications become harder to understand and work with. There are side effects of changes that might not be obvious due to easy-to-overlook dependencies leading to issues that can be difficult to untangle.
• Less scalable: Scaling becomes a matter of adding new instances to run the entire codebase rather than adding instances to scale individual pieces of the app that might be used more than others. This can lead to some resources getting wasted while some others strain the server.
• Service-Oriented Architecture (SOA) became popular towards the early and mid-2000s. The SOA views an application as a collection of services running in parallel and connected by application programming interfaces (APIs). Here. each service is self-contained representing a specific business activity with the desired outcome. This approach brought in the following advantages:
• Easy maintenance: Distinct services can be updated without affecting other services.
• Platform independence: Create applications by combining services that use different solutions.
• Improved reliability: Easier to locate the problem and debug a small service without affecting the working of the entire application.
• Scalability: Individual services can scale by adding server resources as demand increases.

Microservice Architecture (MSA) is a variant of SOA. In fact, some consider the MSA and SOA to be one and the same. Nevertheless, microservices are hogging all the attention at present.

Microservices

When people talk about MSA they’re generally referring to software design that includes the following characteristics:

• Services are inter-dependent
• Services often containerized using a container tool such as Docker or in a virtual machine (VM)
• Asynchronous communication is handled via messaging or job queues and synchronous communication is handled via HTTP with JSON messages.
• Instance management automation
• Auto-scaling components

Source: Dzone

MSA views services purely as functional, unlike SOA which views them as distinct (as explained below).

SOA Views:

Business Services: Define core business operations represented through XML, Business Process Execution Language, and others.

Enterprise Services: Implement the functionality defined by business services relying on application services and infrastructure services to fulfill business requests.

Application Services: Confined to a specific application context, having a dedicated user interface to directly invoke the services.

Infrastructure Services: Implement non-functional tasks such as authentication, auditing, security, and logging, invoked from either application services or enterprise services.

MSA Views:

Functional Services:

• Specific support for business operation.
• Services assessment is done externally, and these services are not shared with other services.

Infrastructure Services implement tasks such as auditing, security, and logging as in the case of SOA, though they are not unveiled to the outside world.

Pros

• Simplicity: Microservice architectures are usually simpler, so they are easier to build and maintain.
• Cross-functional teams: Technical decisions can be made faster and by smaller groups.
• Flexibility in technology: Like the SOA approach, microservices allow a blend of solutions to work together.
• Flexibility in scalability: Microservices can scale independently so additional resources can be added exactly where they’re necessary
• Code Reusability: Same code can be used for similar business requirements

Cons

• Complexity: Having more and more of the code split out into individual services. Five or six services aren’t difficult to manage, but twenty or more can be!
• Cultural and Procedural Changes: Adopting microservices will also require the adoption of an agile coding approach and often require the formation of a DevOps team.
• Costly: Network calls made by APIs aren’t free. In addition, when the migration of architecture is involved, the labor costs of breaking up a monolith can create an otherwise unnecessary expense.
• Security Issues: Each inter-network communication path creates a new security risk that needs to be addressed and monitored.

While microservices offer distinct advantages over monoliths, building software from scratch as a monolith and then moving toward a microservice approach makes more sense. If development time is not an issue, taking a microservices approach from the beginning avoids the effort and expense of later refactoring. You could weigh the pros and cons of absorbing the time costs of starting with microservices versus delaying those costs and beginning with a monolith. Finally, it all comes down to the priorities of the company and its project.