Introduction to Microservices

Lazaro Ibanez

Microservices are very popular in the development world nowadays. The companies work to create larger and more complex products that are better developed and managed as a combination of single, small and meaningful functional features. Each of these functionalities are usually one single service that has it’s own process and communicate with a lightweight mechanism, deployed in one or multiple servers, working cohesively together for a larger, application-wide functionality.

This is a form of service-oriented architecture style, however it is not possible to say that there is a formal definition of the Microservice architecture. The applications are built as a collection of different smaller services rather than one big app. Instead of the typical monolithic software from years ago, you have several independent services that can run on their own and may be created using different programming languages. Big and complicated products can be made up of simpler and independent programs that are executable by themselves. These smaller programs are grouped together to deliver all the functionalities of the big, monolithic app.

As a first approximation, we can say that services map to runtime processes, but that is only a first approach. A service may consist of multiple processes that will always be developed and deployed together, such as an application process and a database that’s only used by that service. Because each of the involved programs are developed independently, then can be versioned, executed, and scaled also independently, which is one of the biggest advantages of the Microservices. They can interact with other Microservices and can have unique URLs or names while being always available and consistent even when failures are experienced, which is a characteristic point of this architecture.

When looking at split a big software into parts, the management team usually look at the technology layer, leading to frontend teams, backend teams and database teams for example. When the development is organised in this way (in some kind of big organisations is almost impossible not to do it), even simple changes can lead to a cross-team project taking time and budgetary approval.

The Microservice approach to division should be different, instead of focus into software layers, it splits up into services, organized around business capabilities. Such services take a broad-stack implementation of software for that business area, including the user interface, backend and any external collaborations. The Microservice’s owner is usually cross-functional, agile team, with the full range of skills required to be in charge of all the development life cycle.

One of the consequences of centralised governance is the tendency to standardise on single technology platforms. The Microservice architecture aims to use the right tool for the job and while monolithic applications can take advantage of different languages to a certain extent, it isn’t that common.

Microservice engineers usually have come from an evolutionary design background and see service decomposition as a further tool to enable application developers to control changes in their application without slowing down change. Change control doesn’t necessarily mean change or time reduction, but with the right company culture and tools, it is possible to make frequent, fast, and well-controlled changes to the software.

Whenever you try to divide a system into components, you’re faced with the decision of how to divide up the pieces. What are the principles on which we decide to slice up our application? The key point of a component is the notion of independent replacement and upgradeability, which implies we look for pieces where we can imagine rewriting a component without affecting other pieces. Indeed many microservice groups take this further by explicitly expecting many services to be scrapped rather than evolved in the longer term.

Benefits of Microservices:

  • Each one is small and focused on a specific feature / business requirement.
  • They are independent, in terms of development and deployment. If you have an application that consists of a multiple functionality in a single process, a change to any single component results in having to redeploy the entire application. But if that application is decomposed into multiple services, you can expect many single service changes to only require that service to be redeployed. That’s not an absolute, some changes will change service interfaces resulting in some coordination, but the aim of a good microservice architecture is to minimize these through cohesive service boundaries and evolution mechanisms in the service contracts.
  • Allows easy and flexible way to integrate automatic deployment with Continuous Integration tools (for e.g: Jenkins, Hudson, etc..).
  • Easy to understand, modify and maintain for a developer because of separation of code, small team and focused work.
  • Opportunity to take advantage of emerging and latest technologies (framework, programming language , programming practice, etc.).
  • Can be developed using different programming language.
  • Only code for business logic. No mixup with HTML,CSS or other UI technologies.
  • Improved scalability based on demand.
  • Can deploy on commodity hardware or low / medium configuration servers.
  • Easy to integrate 3rd party service.
  • Every microservice has it’s own storage capability but it depends on the project’s requirement, you can have a common database for all services.
  • The agility and low costs can also come from being able to reuse these smaller programs on other projects, making it more efficient.

Disadvantages of Microservices:

  • This architecture brings a lot of operations overhead.
  • Remote calls are more expensive than in-process calls, and thus remote APIs need to be coarser-grained, which is often more awkward to use. If you need to change the allocation of responsibilities between components, such movements of behavior are harder to do when you’re crossing process boundaries.
  • Duplication of effort.
  • The distributed systems are complicated to manage .
  • Difficult to trace the problems because of the distributed deployment.
  • When the number of services increases it makes more complicated to manage the whole product.

Case where Microservices architecture is the best fit ?

When you need to support Desktop, web , mobile, Smart TVs, Wearable, etc… or you don’t know in future which kind of devices you need to support.

Which companies are using Microservices architecture?

Most large scale web sites including Twitter, Netflix, Amazon and eBay have evolved from a monolithic architecture to a Microservices architecture.

Via: Martin Fowler, Stackify, Java Code Geeks and

Examples of code on GitHub: Repo 1 and Repo 2

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade