The term Microservices was first introduced by Martin Fowler and used at a software architects’ workshop in 2011 for the first time. It is making a tremendous popularity among the development organizations’ day by day. Likewise, the demand of Microservices developers is increasing exponentially. But have you ever thought that why it is becoming so popular? If you are not aware of Microservices Architecture, you just need to spend some minutes with me. You will observe that maximum number of your doubts are already clear, and the remaining you will be able to clear yourself while developing a project using this concept.
However, theoretically taking on microservices is easy, but practically it is often not so straightforward. Needless to mention, each new concept is always not like a piece of cake at the beginning.
Microservices offers increased modularity, making application development, deployment, testing, change management, maintenance processes easier. Few organizations such as Netflix, PayPal, Amazon, eBay, and Twitter are currently using microservices. Even some other organizations are also constantly working on it, therefore you will see more names in this list very soon.
If you are planning to appear in any interview on Microservices, you need to pay attention to every word of this article. In this article, we will have a crystal clear understanding of Microservices concept. Let’s start our topic ‘Microservices Architecture’ and other related concepts.
What is Monolithic Architecture?
Before jumping directly into the Microservices, it is important for everyone to first understand what is Monolithic Architecture. Don’t forget that in a Microservices based Application, each autonomous service by itself is first implemented according to monolithic architecture. Hence, having knowledge of Monolithic Architecture becomes mandatory.
However, the Monolithic word derived from the monolith, which normally means an object made from a single large piece of material. In a Monolithic architecture, an application is built as a single unit and has a single logical executable. A standard enterprise application has a multi-layered architecture, generally presentation layer, service layer and data layer.
Sometimes even, the integration layer to communicate with another application via messaging or REST API. Hence, some people in the industry sometimes call it multi-tier architecture. It may also have multiple modules to implement business features, but ultimately It will have a single build system which builds entire application and/or dependency as a single executable.
Benefits of Monolithic Architecture
1) Simple to develop (dividing it into multiple layers e.g. Presentation Layer, Service Layer, Data Access Layer just simplifies the development process)
2) Easy to test (Testing a single application is always easy)
3) Easy to deploy. We just need to copy the packaged application(jar, war, etc.) to a server.
4) Simple to scale (We can perform horizontal scaling by running multiple instances behind a load balancer)
Drawbacks of Monolithic Architecture
1) Even for a small change in the code, entire application needs to be re-built and re-deploy.
2) This type of Applications sometimes is not reliable. If any bug in the application, it may affect complete service down or application may not work as expected. Hence, one small problem may affect the entire application.
3) Adding new concept/technologies/new Integration may become very complex. Sometimes major application design needs modification.
4) As the number of modules increase, then application size increases, downtime for re-deployment may also increase accordingly. As a result, the code becomes complex which is then hard to maintain.
What is Microservices?
Microservices is an architectural style that organizes an application as a group of smaller services instead of a single bulky service. Moreover, these smaller services have the following behavior:
♦ Loosely coupled
♦ deployable independently as a single entity
♦ Highly maintainable and testable
Apart from that, these services need smaller team for development and they are perfectly organized around business capabilities. Practically, We divide a big application into smaller modules(services). However, the implementation of each module happens as a single application. When integration of all services(modules) takes place, the complete application architecture is known as Microservices. In simple words, Microservice is all about distributing or breaking a large application into small pieces(services).
Moreover, instead of sharing a single database schema with other services, each service has its own database schema. However, having a database schema per service is necessary if you want to take advantage from microservices, because it ensures loose coupling.
According to Martin Fowler, who wrote extensively about the topic for the first time, The term Microservice Architecture is 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 the organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
While applying microservices architecture in our application, we separate out business functionality into multiple independent modules that are independently responsible for performing specifically described, standalone tasks. These modules communicate with each other through simple, globally accessible application programming interfaces (APIs).
Microservice architectures offer you to break applications into distinct self-governing services, each managed by separate groups within your development organization. It supports the separation of responsibilities critical for building highly scalable applications. Moreover, It allows a developer to work independently on individual services without impacting the work of other developers in other groups working on the same application as a whole.
How do internal services communicate with each other in Microservices Architecture?
Few microservices expose a REST, RPC (Remote Procedure call) or message-based API to be consumed by other microservices. On the other side, most of the services consume APIs provided by few services. These microservices may also implement a web UI to communicate with each other. There are many protocols, and choices that we can use for communication. However, it depends on the communication type you want to use.
If you decided to use a synchronous request/response-based communication model, protocols such as HTTP and REST techniques are the most common. They are very helpful, specifically if you are publishing your services outside the Docker host or microservice cluster. In contrast, you can use asynchronous, message-based communication techniques such as AMQP (Advanced Message Queuing Protocol).
Benefits of Microservices Architecture
1) Microservices offers high flexibility for changes. If we make any change in one service, we don’t need to stop other services.
2) If one Microservices is not working properly then it may not affect all other services. For example, Let’s assume Amazon shopping portal. If payment service is not working then it may not stop other services such as Product Search, Add items to Cart.
3) Modification, Upgrade, Enhancements to new technologies are not so complex as it is in Monolithic architecture.
4) If the number of Microservices increase, the code will never become complex. It will not be mandatory to make other services down as opposed to Monolithic application.
5) Scaling Service is easy, as Microservice architecture enables each service to be scaled independently. Memory will also be used in an Efficient way.
6) It makes continuous deployment possible for complex applications as Microservice architecture offers each microservice to be deployed independently.
7) It provides a choice of adopting new technologies in between the development instead of making choices at the start of the project.
8) There is always a possibility to replace small parts of the system easily, in case if any part is unreliable or client demands it to replace.
9) Easy to integrate with new systems and external sources via an API.
Drawbacks of Microservices Architecture
1) Microservices Architecture includes a complexity, just by the fact that this is the best choice for distributed systems. Complexity arises when we need to implement the inter-process communication mechanism, including the additional implementation to handle partial failures.
2) Testing a microservices also becomes much more complex as compared to monolithic. For a similar test for a service you would need to launch that service and other services that it depends upon or at least configure stubs for those services. Sometimes the outcome of one Microservices may be used as the input of another Microservices.
3) Sometimes a minor change becomes very difficult to implement in a Microservices Architecture based application. Suppose a change impacts multiple services, then you need to plan it carefully and coordinate changes to each of the services.
4) Deployment of a Microservices Architecture based application is also much more complex. Each service may have multiple runtime instances. Therefore, we need to configure, deploy, scale, and monitor each instance separately.
5) Microservices architecture involves multiple tools and technologies to develop. So, architecture becomes very big and it takes a bit more development time as compared to the monolithic architecture.
6) Even Runtime Environment needs very high configuration and tools such as AWS Cloud, Google Cloud, Azure Cloud, PCF Cloud etc. in Microservices Architecture.
7) Maintenance of Microservices Architecture based applications is also very Complex and Cost Effective. Multiple Log files, Admin UI (Actuator), Communication chains, Debug Application etc.
Monolith vs Microservice
In a monolithic based application, we put all functionalities of the application into a single process and scale it by replacing the whole application on multiple servers. In a microservices architecture, we put a single functionality or approximately similar functionalities into a separate service and scale it by distributing these services across servers and clone it as needed. Further to know crystal clear differences between Monolith & Microservice, kindly visit benefits & drawbacks of the same in above sections.
Microservices Tools and Frameworks for Java
Spring Cloud is the technology/framework which implements Microservices. Please pay a bit attention on the previous statement. As a bad practice, people in the industry sometimes use both the terms interchangeably which is incorrect. Microservices has been just an architecture or a concept to develop a large application in a different way as compared to a monolithic application. And we can develop a Microservices based application with the help of Spring Cloud. Every Microservice internally supports all Spring boot concepts and Integrations such as MQs, Batch, Email, Camel etc. It also supports DB operations using Spring Data JPA.
Common Tools & Frameworks with Spring Cloud
1) Generally, every module(service) is implemented as a single Project i.e. called as Microservices using a Spring Rest Controller concept.
2) Once we complete writing Microservices Application, it must be published by the Register and Discovery Server (R&D Server) i.e. Netflix Eureka. In short, we call it Eureka Server.
3) One Microservice can find and communicate with other Microservice using the Registration with Eureka only. When it gets published by Eureka Server, other Microservices can find it for further communication.
4) Common properties having similar values must be provided outside of all Microservices using the concept of Config Server. (via GitHub, GitLab etc.)
5) If any Microservice is throwing Exceptions repeatedly, then Stop Executing such Microservice for some duration and inform it to Admin Dashboard. In order to handle this, we use Circuit Breaker concept(via Netflix Hystrix). However, the new concept for Fault tolerance is Resilience4j as Hystrix is deprecated now.
6) If any Microservice incorporates Load Balance Support (multi-instances), then we need to use Load balancer Client (via Ribbon or Feign Client)
8) In order to use all tools, we need one entry and exit concept i.e. API Gateway (via Netflix Zuul). The API gateway is the entry point for clients. Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end. It supports Dynamic Microservice instance selection, request filtering, Single Sign On (SSO- One time login), HTTP support for Global Data in JSON format. The new implementation for this is Spring Cloud Gateway API as Zuul is deprecated now.
9) We can integrate with any type of HTTP client like Angular, Android Device, .Net REST API and many more.
After going through all the theoretical part of ‘Microservices Architecture’, finally, we should be able to answer all the questions related to Microservices Architecture including Monolithic as well. Also, we should be ready to start implementing at least a small Application using Microservices Architecture. Similarly, we hope that you will further extend this knowledge and also try to implement it in your project accordingly. In addition, in case if there is any update on our topic, we will also modify the article accordingly. Moreover, don’t forget to provide your comments in the comments section below.