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.

1. Microservices – what are they and why use them?
Microservices – what are they, what can they do for you and what do you need to be aware of?
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.

2. 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:
1. "Services form information barriers
2. 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"
3. testing and deployment are more complicated
4. 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
5. 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
6. 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.
Jean-Christophe Huc (Jay C)
Follow me on Twitter @cto_software,
and visit my blog for more articles www.jchuc.com