What are microservices

Nowadays everybody is talking about microservices. Every major player in IT (google, amazon, netflix) use them as their core architecture, because they helped them to grow rapidly. So what are microservices and why should you use them?

Let’s start with definition from http://microserices.io:

Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.

Basically it means that you cut your application into multiple services (not modules) by domain (business) not by technical scope. So for instance if you have accounting software you will have separate service for product catalog, orders, invoicing, customers and so on. Loosely coupled services means that as an interface for communication between services you use Rest API.

Monolith vs Microservices

If you never heard of microservices and you will see picture above you will probably think to yourself that microservices are much more complex than monolithic architecture. Well that’s partially true.

Every microservice will probably have it’s own database, business layer, Rest API layer and a lot of different components. In monolithic architecture you just have one database, one module containing entities, another for handling business logic and than you will probably have one big deployment file which contains all modules together.

The main trouble with monolith begins when you need to add more and more functionality – you will add more entities, more business logic, more complex UI and everything has dependency to everything. Eventually you end with big fat dinosaur which is very hard to manage, it is not fun to develop a new functionality anymore and if you want to ship project to production you will need permission of all developers, testers, managers, architects and all aliens in the known universe. Shipping to production will become hell and instead of releasing new functionality several times per month you will be glad if you can do it once per year.

On the other hand with microservices you will have probably tens of separate services which solves only their responsibility. Microservices are very small and therefore easy to manage and understand. If you need to ship new functionality you just have to release some of the services not all of them which decrease complexity of releasing process.

Microservices architecture

Let’s discus main parts of microservice architecture:

Client

Client represents browser, mobile device, tablet, TV and so on.

Identity provider

Identity provider is used to provide security for our services. OAuth2 is often used for these use cases alongside with JWT (JSON web token).

CDN

CDN stands for Content delivery network and it is used to deliver static content with minimal latency.

API Gateway

The API gateway is the entry point for clients. Clients don’t call services directly. Instead, they call the API gateway, which forwards the call to the appropriate services on the back end. The API gateway might aggregate the responses from several services and return the aggregated response.

Management

The management component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes.

Service Discovery

Maintains a list of services and which nodes they are located on. Enables service lookup to find the endpoint for a service. Therefore you just need to know what is the identifier of service (for instance product catalog is identified by api.v1.product) instead of full url. You ask service discovery to give you actual url for microservice based on it’s identifier.

Service

Service represents one microservice. Usually every service is separate project with it’s own git/svn repository.

Remote service

It can be any service (web service, REST) which your microservice needs. For instance you are developing product for creating of events. One of your microservice which is responsible to send event may call google calendar API which will put event into customer calendar.

Advantages

improves fault isolation: larger applications can remain largely unaffected by the failure of a single module
eliminates long-term commitment to a single technology stack: If you want to try out a new technology stack on an individual service, go right ahead. Dependency concerns will be far lighter than with monolithic designs, and rolling back changes much easier. The less code in play, the more flexible you remain
makes it easier for a new developer to understand the functionality of a service
independent development and deployment
scaling per microservice – this is useful in cloud environments, especially Serverless applications (PaaS, FaaS provided by Google Cloud) where you can operate some of your services completely free (nightly batch jobs, report generations and so on). On the other hand if you need extra memory or CPU usage only for some microservices you do not need to buy extra resources (pay more money than you actually need) for microservices which are not so resource expensive.
small focused teams – ideal for scrum teams

Drawbacks

increased complexity – you need to manage multiple projects and handle communication between them
problem with transactions – in monolith application you create invoice, order and customer in one transaction. If something fails everything fails. With microservices there is no such think. However you can use several techniques including:
- entity driven approach – create root entity (order) and push it’s id to queue. Invoice and Customer services will than listen for changes and do their business logic accordingly based on order id pulled from queue
- retry pattern – https://dzone.com/articles/understanding-retry-pattern-with-exponential-back
- compensation – manual rollback of creation of invoice, customer when root entity (order) fails

SOA vs Microservices

Quite an often question to microservices is what is difference between SOA and microservices. So let’s look at architecture for both:

microservies — Microservices architecture

Comparison table of main differences

SERVICE-ORIENTED ARCHITECTURE	MICROSERVICES ARCHITECTURE
Maximizes application service reusability	Focused on decoupling
A systematic change requires modifying the monolith	A systematic change is to create a new service
DevOps and Continuous Delivery are becoming popular, but are not mainstream	Strong focus on DevOps and Continuous Delivery
Focused on business functionality reuse	More importance on the concept of “bounded context”
For communication it uses Enterprise Service Bus (ESB)	For communication uses less elaborate and simple messaging systems
Supports multiple message protocols	Uses lightweight protocols such as HTTP, REST or Thrift APIs
Use of a common platform for all services deployed to it	Application Servers are not really used, it’s common to use cloud platforms
Use of containers (such as Docker) is less popular	Containers work very well with microservices
SOA services share the data storage	Each microservice can have an independent data storage
Common governance and standards	Relaxed governance, with greater focus on teams collaboration and freedom of choice
You need a specialist	Any developer (JAVA, C#, PHP) can write a microservice because it is based on common concepts

Microservices are not invented. Enterprises such as Amazon, Netflix, and eBay used the divide and conquer strategy to functionally partition their monolithic applications into smaller units, and resolved many issues. Following the success of these companies, many other companies started adopting this as a common pattern to refactor their applications. Eventually the pattern was termed as Microservices Architecture. Nothing radically new has been introduced in MSA. MSA is the logical evolution of SOA and supports modern business use cases.

Conclusion – should I use microservices?

Well as everything else in IT world – it depends. If you are building something new from scratch, you can start with monolith. As your application expands you can decide anytime to switch to microservices. Later you decide, harder it will be to adapt to microservices. Same applies for existing monolithic applications.

My subjective advice is as follows:

Try to cut you application to several business scoped services (invoicing, ordering, product catalog). If there are more than 10 services, than you should start to migrate into microservices.

What should be my first microservice?

Again, my subjective advice is to create microservice from some minor parts of your application – for instance notification module (some people says that you should start with most valuable service, but I think this approach will stop you from migrate to microservice, because most valuable services are often the ones which are hardest to extract). Try to understand basic concepts of microservices and than start to extract more and more functionality into microservices – imagine it as a sculptor is carving a statues – in the beginning you have one block of stone (monolith), at the end you will have nicely carved separate sculptures (microservices).

Sources:

2 thoughts on “What are microservices”

Wildan Khairianto says:

October 10, 2019 at 9:29 am

so if im new, i better using monolith?

LikeLike

1. pohorelec says:
  
  October 10, 2019 at 10:04 am
  
  Depends on what you want to achieve. If you want to create small app – use monolith, if you know you are creating something bigger go to microservices.
  
  LikeLike