This guide helps Java developers to build production grade microservices by using Spring Boot, Docker, Kubernetes and other supporting components.

Why should I learn microservices?

The reason why you should learn and master microservices is, these days many organizations are migrating their monolithic applications into microservices.

Why ? The reason is microservices architecture makes applications easier to scale, faster to develop, enable innovation, and it is also going to help organizations by accelerating the time to take their new enhancements to the market.

So with all these reasons, microservice is going to be a demanding skill set.

Agenda : 

→ You need to learn how to containerize your microservices with the help of Docker. Because without knowing how to containerize your spring boot application, you cannot really build microservices.

→ Learning about Docker is a very basic need for a microservice developer.

GitHub link

GitHub Page Link

What are Microservices ?

In a simple language, we can call these microservices as one of the architecture styles that we can consider to build our web applications.

Example : So to understand more about microservices, let’s try to take a bank application with the name EasyBank and this bank application, just like any other bank application, provides various products to its customers with the name, accounts, cards and loans.

So for this EasyBank, in order to build a web application, there are multiple architecture patterns available inside the industry.

Monolith architectural style

The very first traditional approach that we have to build web applications is Monolith.

Whenever we are following the pattern of monolith, all the business functionality of a bank application, they will be deployed as a single unit.

If you see here inside a single server, it has a presentation layer related to logic like HTML code, JavaScript, CSS and post that there is going to be a backend business logic along with that data access layer.

And one more important feature of monolithic is it is going to have a single supporting database where we store all the data related to accounts, cards and loans.

This is the architecture style that companies or developers they use to follow back decades.

Advantages of monolithic architecture

1. The very first advantage is, this architecture style supports simpler development and deployment for smaller teams and applications.

If you have a small team or if your application is a very small application, definitely this pattern is going to make sense because it is going to ease your development and deployment.

With a single deployment all your web application is going to be deployed and it is going to be available for the end users.

2. Since we are deploying everything inside a single server, there are going to be fewer cross-cutting concerns.

When I say cross-cutting concerns, all your non-functional requirements like security, auditing, logging. This is going to be simple inside monolithic because all your code deployed inside a single server as a web application.

3. The next advantage that we have with monolithic is, it is going to provide better performance due to no network latency.

Why better performance? Because all the code is deployed inside a single server. If accounts business logic wants to communicate with cards or loans, it is just going to be a method call inside the same server. There is no network call with the help of web services.

So with this reason, monolithic applications are going to have better performance.

Disadvantages of monolithic architecture

1. The primary disadvantage is it is difficult to adopt new technology. Like whenever I want to enhance my web application with the new frameworks or with the new languages or new technology, either I have to update my entire codebase or I need to continue with the old technology.

Sometimes the accounts team members may want to move to a latest framework or latest language or latest version of the framework, but there will be pushback coming from the Cards and Loans team members.

So with all these reasons, it is going to be difficult to adopt new technologies and with that reason, very limited agility inside monolithic applications.

2. It is not going to work like you decided to move to a framework or a new language today. And you can’t do that immediately in a week or a month’s time.

It is going to take a lot of time to upgrade your monolithic application because your entire code is tightly coupled. We never know what issues it is going to create when we try to migrate.

With that reason a rigorous testing and regression has to be done on top of your web application.

3. Since we are going to maintain everything inside a single server, all the code related to your web application is going to maintain as a single code base, which is going to be difficult to maintain over the time as your application is growing with the new enhancements day by day.

4. The next disadvantage that we have here is your application is not going to be fault tolerant, which means you are going to be having frequent issues with the scalability, availability of your monolithic application.

5. The last disadvantage, you can see since you deployed everything inside a single server, if the loans development team, they want to introduce a small feature or if they want to make a small enhancement inside their codebase, it will require a full deployment.

Due to that reason your entire web application is going to be having downtime and this is going to be a super drawback whenever you’re dealing with the end users who use your web application 24/7 ?

Different perspective w.r.t Development

Let me try to explain monolithic by taking a different perspective inside our EasyBank web application. Typically, there will be development teams handling the accounts, loans, cards and UI, UX inside monolithic applications.

All these developers, they are going to work on a single code base. And using these single code base, we are going to deploy the entire web application into a web server or application server with the help of CI/CD tools like Jenkins.

Typically, we will package all our code base into a war format or an ear format and deploy into a single web application. And this single web application is going to be supported by a single database.

So here the major drawback is there is no flexibility to the organization and developers to introduce new features, to introduce new enhancements.

With that reason, since the companies are growing a lot and since that demand from the end users is increasing on a day to day basis, slowly the industry migrated to a new architecture pattern, which is SOA.

SOA – Service Oriented Architecture

The main enhancement that happened inside this SOA architecture compared to monolithic is, organizations can now segregate their UI logic and backend logic.

As you can see here, I’m going to deploy the presentation layer or UI logic into server 1 and inside the server 2, I’m going to deploy all my logic related to accounts, cards and loans with the help of web services.

With this pattern, at least I’m able to separate the tight coupling between UI and the backend logic.

But like you can see here, for these UI to communicate with the backend services, we should use a middleware component which is enterprise service bus.

So whenever a request comes to these ESB, this ESB is going to redirect that request to the corresponding service(SOAP service), like whether the UI application is trying to fetch the accounts information, cards information or loans information.

Accordingly, it is going to redirect the request to one of the web services inside the server 2.

So we are able to separate the UI logic and backend logic into two different servers.

Advantages of SOA Architecture

The advantages are like : 

• reusability of services
• better maintainability
• higher reliability and 
• Parallel development.

The reason why we have these advantages is you have separated all your logic into separate components.

Like all your accounts related logic is going to stay inside the account service. Similarly for loans and card service and coming to the UI code, it is going to be separated into a separate code base and it is going to be deployed into a separate server as well.

With all these reasons we can achieve parallel development, better maintainability and reusability of services and higher reliability.

Disadvantages of SOA Architecture

1. Communication is going to happen with complex protocols like SOAP. Using SOAP and the XML format, the communication between the UI and backend server is going to happen.

Compared to other protocols like REST, SOAP is very complex in nature and heavy in nature.

2. We have a middleware component which is ESB, and to set up that ESB, we need to put a lot of investment because these are not open source.

These products are like commercial products, like Oracle has an ESB product which is costly in nature and it is an extra overload in between your UI and backend services.

Why should we maintain a separate component just for communicating between UI and backend services? So in the initial days projects, they used this SOA architecture and to some extent they got the benefits like parallel development, reusability of services and better maintainability.

But slowly the industry felt that this architecture pattern was also very complex to maintain and it involved a higher investment cost.

Different perspective of SOA w.r.t Development

So initially, like you can see we are going to have UI, UX dev team accounts, team loans, team and cards development team.

Inside SOA architectural style, you can see the UI team, they are going to have separate code repo and all the backend team they are going to have separate backend repo and using these two separate code repos, we are going to have separate deployments into separate web servers.

As you can see, the catch is that the communication between the UI server and the backend server is going to happen only with the help of a middleware component, which is an enterprise service bus.

So to some extent it has the advantages of parallel development and independent deployments between UI team and backend team. But like we discussed, it has its own disadvantages.

Microservices Architecture style

So with all these reasons, everyone started looking for a better architecture style which will overcome the challenges of SOA and Monolithic.

That’s where we landed onto a new architecture style, which is microservices.

Whenever we are developing our web application, for example, the same easy bank web application, we are going to develop many services that are modeled around a business domain.

I can have many separate small microservices focusing entirely on accounts, logic and similarly for cards and loans.

This way based upon separate, separate business domain logic, I can segregate them into separate services and all these microservices, they are going to have their own database, they are going to be deployed into their own servers or own containers.

We are going to have all our UI logic inside a server 1, and coming to the backend services, we can create any number of micro services that can be deployed into separate servers and containers and all these services they are going to have their own supporting database.

Advantages of Microservices style

It is easy to develop, test and deploy because you loosely coupled all your business logic, all your accounts related logic is going to be stayed inside a small component.

If you want to enhance accounts microservice with a new language or new framework, you can happily do that because it’s an entirely separate component which will have its own development life cycle, deployment lifecycle. And with that reason it is going to increase the agility inside your organization.

Since there is no tight coupling between your microservices or services, all the development teams, they can have their own enhancement life cycle, they can have their own discussions, they can have their own deployment lifecycle. With that, we are going to achieve parallel development.

→ The beauty of microservices is it is modeled around your business domain. For example, inside the bank we have accounts, loans and cards. So I can have 3 microservices focusing on these 3 different business domains.

Since we are going to deploy all these services into Docker containers, it is also going to provide you a flexibility where you can scale horizontally and independently.

For example, if your accounts microservice is going to receive higher traffic compared to loans and cards, you can scale only accounts microservice independently.

→ Organizations, they want agility and they want the freedom to enhance their web applications and microservices whenever they want, and they want to go to the market as soon as possible.

“If there is one crucial takeaway that you want to take from the concept of microservices is, microservices, they’re going to prioritize the independent deployability of your services. And whenever you’re deploying your own microservice, you are not going to have any dependency on other microservices. With this primary advantage, all other numerous benefits will naturally emerge inside your microservices web application.”

Disadvantages of Microservices architecture

The very first disadvantage is it has complexity because when you have so many independent containers deployed separately in different, different servers and clusters, definitely connecting them and making sure they are able to communicate properly is always going to be a complex task. 

It is also going to be infrastructure overhead. Inside monolithic and SOA, you only have 1 or 2 servers to monitor, but inside microservices you are going to deploy your microservices into a number of servers and containers. With that, you need to monitor all of them. That’s why there is going to be infrastructure overhead. 

There are also going to be security concerns. Earlier architectures, any communication between your code used to happen with the help of method calls and a web service call from UI to backend.

But now with microservices, even your backend services, they need to communicate with web services like REST based services. And this increases security concerns inside your web application.

Different perspective of Microservices w.r.t Development

You can see there are 4 different development teams. Inside microservices architecture pattern, all of them, they are going to have a separate code base.

And from these separate code bases, they are going to have a separate deployment lifecycle with the help of Jenkins or any other CI/CD tool and post the deployment, all of them, they are deployed into multiple servers or containers and each of the service is going to have their own supporting database.

The other advantage that we have with microservices is, accounts microservice team, they can have an SQL database and for loans microservice they can have a NoSQL database. So they can choose their own database based upon their requirements.

And even we can have accounts microservice built with the help of Python, loans microservice built with the help of Java and cards microservice built with the help of Go language.

At the end of the day, it is going to give super super freedom to your company and to the developers. They are free to explore because they are not bound to a single codebase or to a single server.

Monolithic v/s SOA v/s Microservices

The primary characteristic of a monolithic application is, we’re going to deploy all our code base inside a single server and it is going to be supported by a single database.

With this, we have tightly coupled all our components of a web application and business logic into a single server.

With SOA, we separate the UI and backend logic, but we are going to add a middleware extra component which is complex to maintain and requires a lot of investment. And SOA also is going to have a single supporting database.

In SOA, we are separating our backend services, but it is not going to give a lot of flexibility in terms of multiple database, multiple codebase. With that reason, we cannot really separate our services or code based around the business domains.

In the case of microservices, where we can separate all our backend logic based upon the business domain and each of the microservice we can deploy into separate servers or containers.

And one more important characteristic of microservice is, each of your microservice is going to have a supporting database and all these databases don’t have to be a single technology. You can have various types of databases like RDBMS NoSQL database, Redis cache. It’s up to you, based upon your business requirement, you can have a supporting database for your microservice.

Compare these monolithic, SOA and microservice by taking different, different features.

Parallel development –

Inside the monolithic style, there is no parallel development, the developers are going to cry. 

In SOA it’s not a happy scenario or a sad scenario. It is somewhere in the middle because at least you are providing some flexibility between UI and backend teams. 

In microservices, it is going to be the winner. You are providing complete freedom to those different, different teams in terms of parallel development, deployment and enhancements.

Agility – 

Inside the monolithic style, there is no agility. You can’t enhance your web application with the new frameworks and new languages because it requires a lot of effort.

In SOA you can do to some extent.

In microservices, you’re going to have a lot of agility because all the teams are working independently.

Scalability – 

Inside the monolithic style, it is going to be very, very tough to scale your web application because you’re going to deploy all your code inside a single jumbo server. If you want to scale your web application, you need to bring one more jumbo server. You need to take care of load balancing between them, which is like a very manual setup and it is going to be very challenging.

In SOA also, the scalability is going to be challenged because all your backend logic is staying inside a single jumbo server. And there is also an extra complexity with ESB, so you should also scale your ESB component.

With microservices, the scalability is going to be super, super easy and it is also going to be automated with the help of products like Docker and Kubernetes.

Complexity and operational overhead – 

Inside the monolithic style, you just have one server. You just need to take care of that one server. You just need to make sure that one server is running properly without any issues. 

In SOA, there are going to be three components. UI server, backend server and ESB component.

Whereas in microservice it is going to be super, super complex because there are some organizations where they are deploying thousands of microservices in hundreds of different, different servers. You can think of operational overhead and complexity that microservice needs on a day to day basis.

Security concerns and performance – 

Inside microservices, the security concerns are going to be more and there will be some performance issues because every communication between your backend logic like accounts, loans and cards, microservice, they have to communicate over the network with the help of REST APIs.

Previously it used to be method calls inside the same server. Now they are all deployed on different servers.

With that there will be some network latency and since you are making so many API calls, of course we need to take care of security concerns as well.

If your web application is small and your organization is very small and you don’t need frequent deployments, then you can always go with monolithic.

Whereas if your application is large and your organization requires frequent deployments, frequent enhancements, then you can always go with the microservices architecture.

Definition of Microservices

Microservices is an approach to develop a single application as a suite of small services, like inside Easy Bank web application, we can develop a web application as a suite of small services with the name accounts, loans and cards.

And each of these services, they can run in their own process and they can communicate with lightweight mechanisms like REST and all these microservices built around business capabilities or business domains.

And most importantly, they can be independently deployable by fully automated deployment machinery. We can automate everything as soon as a developer checks-in into the code base of a microservice, the build will happen and the same build will be deployed automatically into the DEV and UAT environment.

And if needed, we can also automate the deployment into production using CI/CD concept.