Evolution of System Design, Webservices to Microservices

In the previous article, we discussed one of many possible journeys for the evolution of ‘System Design’ in search of nirvana of Independence, i.e. Independence of development, technology, deploy-ability, scalability, and team structures (autonomous).

If we weave this whole journey so far, it is evident that effort and direction were always to achieve the following goals of System Design:

• Keep implementation clean, readable so it can be maintained and extended easily — Smaller in Size, SPR, Clear Intent using naming convention, right package/project structure, Reuse code (DRY)
• Modular Structure, Domain-Driven — Small self-contained unit of code that can be developed independently, by autonomous smaller teams
• Independently Releasable — Code, Data everything bundled together without cross dependencies
• Independently scalable & fault-tolerant - Making it easy to scale any specific unit of implementation
• Freedom of using any technology & communication protocol — Technology-neutral interfaces and discovery mechanism, so implementation of individual units can be technology agnostic.

What is Microservice

‘Microservice’, one of the most talked-about panacea for the above goals nowadays.

Let us understand what is Microservice.

• The name implies that Microservice must be smaller than a small service.
• And it should be a service.

Service means ‘an act of doing work for someone’.

Which is correct for microservices, similar to any other service-oriented pattern (EJB, Rest, Webservice..).

‘Micro’ (small) is a bit ambiguous, as there is no defined parameter for size. It is similar to the size of function or class, as we discussed in one of the previous articles.

Right parameter for size should be clear intent combining with principle of single responsibility.

Hence, similar to any other service pattern, microservice should also have clear boundaries to contain single responsibility and clarity of intent.

Lines of code is not the right parameter for size. Although it could act as guide rail.

But both of the above attributes do apply to every service, and not only for microservice. Then what is special about microservices.

To understand this, let us move beyond the name.

Deep Dive to Understand Microservice

Following are few goals of system design evolution which we discussed in the previous article:

• Modular Structure, Clean Code, Clear intent, Single Responsibility
• Ease of maintenance, ease of understanding
• Independent ownership of a unit of code (service in this case)
• Independently deployable, Independently Release-able
• Independently scalable
• Technology Agnostic

Other than the last three points above, the rest all could be met with monolith design also.

The rest of the points possibly ‘can be’ met with webservices (or any other service-oriented pattern).

Webservices are independently deployable, scalable, and are technology agnostic. Interfaces are exposed using WSDL. Communication is through any of the open standards with XML (mostly SOAP over HTTP). Moreover, these are discoverable also using service registries and protocols (ex: UDDI).

If webservices is meeting all the needs, then why do we need microservices?

Here comes the small difference created by that ‘micro’ word with service, which makes a big impact on intentions.

Webservices are mostly used as an interface of one application for another application. It is not focused on fine-grained smaller implementation, rather it mostly follows coarse-grained structure (Session Facade Pattern). It focuses more on performance and hiding complexity.

The difference is in the motive of the pattern.

The motive of webservice was to enable device to device, system to system communication. It is one of the ways to expose an interface for a system. This is what webservices were used for.

Webservice is a technology neutral way to expose the interfaces for (monolith) applications.

However, the motive of the microservices pattern is to promote structure that enables the collection of loosely coupled services, which are small, fine-grained, and are lightweight.

Microservices pattern recommends all goals of clear intent, independent development, and deployment as we discussed above.

Hence naturally whole microservice ecosystem and all the frameworks are geared to enable smaller implementation, lightweight interaction protocol (like REST), independent development/deployment/release, etc.

Size (micro) and intention to have independently deployable service with a single responsibility and clear intent, plays a major role in setting the direction and whole thought process to design the application.

The following diagram represents a pictorial view of microservices.

Webservice (and many similar) could have all ingredients from a technology perspective to meet the above goals. However, as a pattern, ‘microservice’ is designed to promote these.

In brief, microservice architecture promotes:

• Smaller size loosely coupled services
• Which can be developed independently, mostly by autonomous smaller teams
• Able to deploy (and release) independently
• Independently scalable, fault-tolerant
• Can be build using any technology, and technology-neutral communication

This is the key difference between webservice and microservices.

Microservices, the Panacea?

This really looks so awesome, like a panacea for all the problems we were facing. This is like a ticket to dreamland where there will be no problem...

But, ahh.. nothing is perfect in this world, neither are microservices for every use case.

There are various drawbacks, challenges for microservices as well (similar to any distributed system pattern). It is very important to keep these in consideration before choosing microservice architecture for the application.

We shall discuss various microservices challenges and possible solutions in the coming articles.

Till then, stay tuned, happy learning...

If you have any suggestions, feel free to reach me on Linkedin: Mohit Gupta