Microservices Architecture –

Microservices : what are they, what can they do for you and what do you need to be aware of?

In software engineering, microservices – or micro-services – may simply be a term for something already being used, but by giving something a name and defining it, we sometimes give ourselves the advantage of recognizing a tool we perhaps should be including in our systems. Microservices may be defined as simple standalone components that can run and be tested independently, which could help create consistency in the final system.

According to Wikipedia, “Microservices is a specialisation of an implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems. Services in a microservice architecture (MSA) are processes that communicate with each other over a network in order to fulfill a goal.”  In other words, each microservice can usually provide an API endpoint itself.

Martin Fowler of MartinFowler.com says the “term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”

Again, the idea is that by designing systems and applications build as suites of standalone components, it is possible to test each component independently, thus being able to determine which ones may be lagging and thereby creating delays in the overall system.

The Open Source resource for microservices states in their opening paragraph, “The idea behind microservices is that some types of applications become easier to build and maintain when they are broken down into smaller, composable pieces which work together. Each component is developed separately, and the application is then simply the sum of its constituent components. This is in contrast to a traditional, “monolithic” application which is all developed all in one piece.”

In a nutshell, this offers the tremendous advantage of being able to quickly develop and fully test each component, rather than waiting until the entire application is completed.  It also means that each component can be updated individually, which is another huge advantage in today’s very demanding market which often forces application architectures to evolve quickly. Users automatically expect a rich, interactive and dynamic experience across many platforms, including mobile devices. Applications must be highly available and scalable, and able to run on the cloud. Many organizations want to be able to release updates, sometimes multiple times in one day. It’s therefore no longer enough to produce simple, monolithic website apps serving up HTML to desktop browsers.

Another advantage is from an engineering standpoint.  By separating the various components of an application, they can be developed concurrently and tested across multiple servers or even multiple data centers.  If a single component dies, you can bring up another without it affecting any of the others.

Scaling becomes more efficient, by allowing the possibility of scaling out with duplicates of the heaviest used components, rather than scaling up on bigger, more robust machines.

There are disadvantages to working with microservices that also must be considered.

According to a criticism on Wikipedia, this approach is subject to criticism on a number of points:

• “Services form information barriers
• The architecture introduces additional complexity and new problems to deal with, such as network latency, message formats, load balancing and fault tolerance, ignoring one of these belongs to the “fallacies of distributed computing”
• testing and deployment are more complicated
• Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process
• Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure
• The complexity of a monolithic application is only shifted into the network, but persists: “You can move it about but it’s still there!”— Robert Annett: Where is the complexity?“

Mr. Annett’s statement really sums it all up:  You can move it about, but it’s still there.  In other words, problems still need to be dealt with.  Microservices architecture is not a way to get rid of problems or shuffle them off to someone else, but a way to isolate them so that one problem doesn’t crash the whole system.  When a problem arises, it needs to be dealt with where it occurs.

Furthermore, when issues arise, they need to be fixed where they arise by the team working with that part.  This helps to reduce the other issues and may be the difference between using microservices successfully or tearing your hair out and wishing you had stuck with the “lesser evil” of the monolithic application.

As with any organization, planning is required before implementation.  There are many advantages to using a microservices architecture, but there are also disadvantages.  They must be weighed for the particular organization and application before choosing this architecture over the more traditional. However, for many developers, today, microservices are not just a good fit, but a great fit.

What is your experience?  Share in the comments, below.