Microservice Architecture – Useful Resources The following resources contain additional information on Microservice Architecture. Please use them to get more in-depth knowledge on this topic. Useful Video Courses 32 Lectures 3 hours 110 Lectures 10 hours 69 Lectures 6.5 hours Most Popular 94 Lectures 8.5 hours 146 Lectures 13.5 hours 54 Lectures 6.5 hours Learning working make money
Composition Patterns Software composition means the way to build your software product. Basically it deals with high level software architecture diagram where different modules of your software will communicate for specific business goals. In this chapter, we will learn about different software composition patterns widely used in organizations. In microservice, we split each function into one process. Each of these services will be independent and full stack in nature. Functional decomposition plays an important role in building your microservices. It provides agility, flexibility, and scalability to your application. Aggregator Pattern Aggregator pattern is the simplest web pattern that can be implemented while developing a microservice. In this composition pattern, a simple web module will act as a load balancer, which means it will call different services as per requirements. Following is a diagram depicting a simple microservice web app with aggregator design. As seen in the following image, the “Aggregator” is responsible for calling different services one by one. If we need to apply any business logic over the results of the service A, B and C, then we can implement the business logic in the aggregator itself. An aggregator can be again exposed as another service to the outer world, which can be consumed by others whenever required. While developing aggregator pattern web service, we need to keep in mind that each of our services A, B and C should have its own caching layers and it should be full stack in nature. Proxy Pattern Proxy microservice pattern is a variation of the aggregator model. In this model we will use proxy module instead of the aggregation module. Proxy service may call different services individually. In Proxy pattern, we can build one level of extra security by providing a dump proxy layer. This layer acts similar to the interface. Chained Pattern As the name suggests, this type of composition pattern will follow the chain structure. Here, we will not be using anything in between the client and service layer. Instead, we will allow the client to communicate directly with the services and all the services will be chained up in a such a manner that the output of one service will be the input of the next service. Following image shows a typical chained pattern microservice. One major drawback of this architecture is, the client will be blocked until the entire process is complete. Thus, it is highly recommendable to keep the length of the chain as short as possible. Branch Microservice Pattern Branch microservice is the extended version of aggregator pattern and chain pattern. In this design pattern, the client can directly communicate with the service. Also, one service can communicate with more than one services at a time. Following is the diagrammatic representation of Branch Microservice. Branch microservice pattern allows the developer to configure service calls dynamically. All service calls will happen in a concurrent manner, which means service A can call Service B and C simultaneously. Shared Resource Pattern Shared resource pattern is actually a conglomerate of all types of patterns mentioned earlier. In this pattern, the client or the load balancer will directly communicate with each service whenever necessary. This is the most effective designing pattern followed widely in most organizations. Following is a diagrammatic representation of the Shared Resource design pattern. Learning working make money
Microservice Architecture – Hands-On MSA In this chapter, we will build one microservice application that will consume different available services. We all know that microservice is not a cost-effective way to build an application as each and every service we build will be full stack in nature. Building a microservice in the local environment would need high-end system configuration, as you need to have four instances of a server to keep running such that it can be consumed at a point of time. To build our first ever microservice, we will use some of the available SOA endpoints and we will consume the same in our application. System Configuration and Setup Before going further to the build phase, prepare your system accordingly. You would need some public web services. You can easily google for this. If you want to consume SOAP web service, then you will get one WSDL file and from there you need to consume the specific web service. For REST service, you will need only one link to consume the same. In this example, you will jam three different web services “SOAP”, “REST”, and “custom” in one application. Application Architecture You will create a Java application using microservice implementation plan. You will create a custom service and the output of this service will work as an input for other services. Following are the steps to follow to develop a microservice application. Step 1: Client creation for SOAP service − There are many free web APIs available to learn a web service. For the purpose of this tutorial, use the GeoIP service of “ The WSDL file is provided in the following link on their website “ To generate the client out of this WSDL file, all you need to do is run the following command in your terminal. wsimport http://www.webservicex.net/geoipservice.asmx?WSDL This command will generate all the required client files under one folder named “SEI”, which is named after service end point interface. Step 2: Create your custom web service − Follow the same process mentioned at an earlier stage in this tutorial and build a Maven-based REST api named “CustomRest”. Once complete, you will find a class named “MyResource.java”. Go ahead and update this class using the following code. package com.tutorialspoint.customrest; import javax.ws.rs.GET; import javax.ws.rs.Path; import javax.ws.rs.Produces; import javax.ws.rs.core.MediaType; @Path(“myresource”) public class MyResource { @GET @Produces(MediaType.TEXT_PLAIN) public String getIt() { return “IND|INDIA|27.7.65.215”; } } Once everything is complete, go ahead and run this application on the server. You should get the following output in the browser. This is the web server, which returns one string object once it is called. This is the input service that provides inputs that can be consumed by other application to generate records. Step 3: Configure another Rest API − In this step, consume another web service available at This will return a JSON object when invoked. Step 4: Create JAVA application − Create one normal Java application by selecting “New Project” -> “JAVA project” and hit Finish as shown in the following screenshot. Step 5: Add the SOAP client − In step 1, you have created the client file for the SOAP web service. Go ahead and add these client files to your current project. After successful addition of the client files, your application directory will be look the following. Step 6: Create your main app − Create your main class where you will consume all of these three web services. Right-click on the source project and create a new class named “MicroServiceInAction.java”. Next task is to call different web services from this. Step 7: Call your custom web service − For this, go ahead and add the following set of codes to implement calling your own service. try { url = new URL(“http://localhost:8080/CustomRest/webapi/myresource”); conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod(“GET”); conn.setRequestProperty(“Accept”, “application/json”); if (conn.getResponseCode() != 200) { throw new RuntimeException(“Failed : HTTP error code : ” + conn.getResponseCode()); } BufferedReader br = new BufferedReader(new InputStreamReader( (conn.getInputStream()))); while ((output = br.readLine()) != null) { inputToOtherService = output; } conn.disconnect(); } catch (MalformedURLException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } Step 8: Consume SOAP Services − You have generated your client file but you don”t know which method should be called in that entire package? For this, you need to refer to the WSDL again, which you used to generate your client files. Every WSDL file should have one “wsdl:service” tag search for this tag. It should be your entry point of that web service. Following is the service endpoint of this application. Now you need to implement this service in your application. Following is the set of Java code you need to implement your SOAP web service. GeoIPService newGeoIPService = new GeoIPService(); GeoIPServiceSoap newGeoIPServiceSoap = newGeoIPService.getGeoIPServiceSoap(); GeoIP newGeoIP = newGeoIPServiceSoap.getGeoIP(Ipaddress); // Ipaddress is output of our own web service. System.out.println(“Country Name from SOAP Webserivce —“+newGeoIP.getCountryName()); Step 9: Consume REST web service − Two of the services have been consumed till now. In this step, another REST web service with customized URL will be consumed with the help of your custom web service. Use the following set of code to do so. String url1=”http://services.groupkt.com/country/get/iso3code/”;//customizing the Url url1 = url1.concat(countryCode); try { URL url = new URL(url1); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod(“GET”); conn.setRequestProperty(“Accept”, “application/json”); if (conn.getResponseCode() != 200) { throw new RuntimeException(“Failed : HTTP error code : ” + conn.getResponseCode()); } BufferedReader br = new BufferedReader(new InputStreamReader( (conn.getInputStream()))); while ((output = br.readLine()) != null) { System.out.println(output); } conn.disconnect(); } catch (MalformedURLException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } Step 10: Consume all services − Considering your “CustomRest” web service is running and you are connected to Internet, if everything is completed successfully then following should be your consolidated main class. package microserviceinaction; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.net.HttpURLConnection; import java.net.MalformedURLException; import java.net.URL; import java.util.StringTokenizer; import net.webservicex.GeoIP; import net.webservicex.GeoIPService; import net.webservicex.GeoIPServiceSoap; public class MicroServiceInAction { static URL url; static HttpURLConnection conn; static String output; static String inputToOtherService; static String countryCode; static String ipAddress; static String CountryName;
Microservice Architecture – Introduction Microservice is a service-based application development methodology. In this methodology, big applications will be divided into smallest independent service units. Microservice is the process of implementing Service-oriented Architecture (SOA) by dividing the entire application as a collection of interconnected services, where each service will serve only one business need. The Concept of Going Micro In a service-oriented architecture, entire software packages will be sub-divided into small, interconnected business units. Each of these small business units will communicate to each other using different protocols to deliver successful business to the client. Now the question is, how Microservice Architecture (MSA) differs from SOA? In one word, SOA is a designing pattern and Microservice is an implementation methodology to implement SOA or we can say Microservice is a type of SOA. Following are some rules that we need to keep in mind while developing a Microservice-oriented application. Independent − Each microservice should be independently deployable. Coupling − All microservices should be loosely coupled with one another such that changes in one will not affect the other. Business Goal − Each service unit of the entire application should be the smallest and capable of delivering one specific business goal. Let us consider an example of online shopping portal to understand microservice in depth. Now, let us break this entire E-commerce portal into small business units such as user management, order management, check-in, payment management, delivery management, etc. One successful order needs to proceed through all of these modules within a specific time frame. Following is the consolidated image of different business units associated with one electronic commerce system. Each of these business modules should have its own business logic and stakeholders. They communicate with other third party vendor softwares for some specific needs, and also with each other. For example, order management may communicate with user management to get user information. Now, considering you are running an online shopping portal with all of these business units mentioned earlier, you do need some enterprise level application consisting of different layers such as front-end, back-end, database, etc. If your application is not scaled and completely developed in one single war file, then it will be called as a typical monolithic application. According to IBM, a typical monolithic application should possess the following module structure internally where only one endpoint or application will be responsible to handle all user requests. In the above image, you can see different modules such as Database for storing different users and business data. At the front-end, we have different device where we usually render user or business data to use. In the middle, we have one package that can be a deployable EAR or WAR file that accepts request form the users end, processes it with the help of the resources, and renders it back to the users. Everything will be fine until business wants any changes in the above example. Consider the following scenarios where you have to change your application according to the business needs. Business unit needs some changes in the “Search” module. Then, you need to change the entire search process and redeploy your application. In that case, you are redeploying your other units without any changes at all. Now again your business unit needs some changes in “Check out” module to include “wallet” option. You now have to change your “Check out” module and redeploy the same into the server. Note, you are redeploying the different modules of your software packages, whereas we have not made any changes to it. Here comes the concept of service-oriented architecture more specific to Microservice architecture. We can develop our monolithic application in such a manner that each and every module of the software will behave as an independent unit, capable of handling a single business task independently. Consider the following example. In the above architecture, we are not creating any ear file with compact end-to-end service. Instead, we are dividing different parts of the software by exposing them as a service. Any part of the software can easily communicate with each other by consuming respective services. That”s how microservice plays a great role in modern web application. Let us compare our shopping cart example in the line of microservice. We can break down our shopping cart in the different modules such as “Search”, ”Filter”, “Checkout”, “Cart”, “Recommendation”, etc. If we want to build a shopping cart portal then we have to build the above-mentioned modules in such a manner that they can connect to each other to give you a 24×7 good shopping experience. Advantages & Disadvantages Following are some points on the advantages of using microservice instead of using a monolithic application. Advantages Small in size − Microservices is an implementation of SOA design pattern. It is recommended to keep your service as much as you can. Basically, a service should not perform more than one business task, hence it will be obviously small in size and easy to maintain than any other monolithic application. Focused − As mentioned earlier, each microservice is designed to deliver only one business task. While designing a microservice, the architect should be concerned about the focal point of the service, which is its deliverable. By definition, one microservice should be full stack in nature and should be committed to delivering only one business property. Autonomous − Each microservice should be an autonomous business unit of the entire application. Hence, the application becomes more loosely coupled, which helps to reduce the maintenance cost. Technology heterogeneity − Microservice supports different technologies to communicate with each other in one business unit, which helps the developers to use the correct technology at the correct place. By implementing a heterogeneous system, one can obtain maximum security, speed and a scalable system. Resilience − Resilience is a property of isolating a software unit. Microservice follows high level of resilience in building methodology, hence whenever one unit fails it does not impact the entire business. Resilience is another property which implements highly scalable and
Different Elements Till now we have learned what is Microservice and what are the basic needs of it above the modern MVC architecture. In this chapter, we will learn the different elements of this architecture that are equally important for a service. Categories of Services By the name Microservice, we assume that it will be a service that can be consumed over HTTP protocols, however we need to know what kind of services can be build using this architecture. Following is the list of services that can be implemented using Microservice architecture. Platform as a Service [PaaS] − In this service-oriented architecture, the platform is given as a tool which can be customized according to the business needs. PaaS plays an important role in mobile application development. The greatest example of PaaS is Google App engine, where Google provides different useful platform to build your application. PaaS originally develops to provide a built-in architecture or infrastructure to developers. It reduces the higher level programming complexity in dramatically reduced time. Following is a snapshot of Google provided PaaS. Software as a Service [SaaS] − Software as a Service is a software licensing business, where the software is centrally hosted and licensed on a subscription basis. SaaS can be accessed mainly through the browser and it is a very common architecture pattern in many business verticals such as Human Resource Management (HRM), Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), etc. Following screenshot shows examples of different SaaS provided by Oracle. Infrastructure as a Service [IaaS] − Infrastructure plays a good role in IT industries. Using cloud computing, some of the organizations provide virtual infrastructure as their services. IaaS is very helpful for bringing agility, cost-effectiveness, security, performance, productivity, etc. in software development. Amazon EC2 and Microsoft Azure are the biggest examples of IaaS. The following image depicts an example of AWS, where the data center is provided as IaaS. Data as a Service [DaaS] − Information technology deals with data and some of the top industry leaders believe that data will be the new sustenance of the society. DaaS is a type of service where data is shared with business conglomerates for research and analysis. DaaS brings simplicity, agility, and security in the data access layer. Following is an example of Oracle Data cloud, which can be accessed or licensed for your own business needs. Back End as a Service [BaaS] − BaaS is also known as MBaaS, which means mobile back-end as a service. In this type of service, backend of the application will be provided to business units for their own business ventures. All push notifications, social networking services fall under this type of services. Facebook and Twitter are examples of well-known BaaS service provider. Security When it comes to dealing with tons of customer data, security plays an important role. Security issue is associated with all kinds of services available in the market. Whatever the cloud you are using – private, public, hybrid, etc., security should be maintained at all levels. Entire security issue can be broadly sub-divided into the following parts − Security issue faced by service providers − This type of security issue is faced by the service providers such as Google, Amazon, etc. To ensure security protection, background check of the client is necessary especially of those who have direct access to the core part of the cloud. Security issue faced by consumers − Cloud is cost friendly, hence it is widely used across industries. Some organizations store the user details in third party data centers, and pull the data whenever required. Hence, it is mandatory to maintain security levels such that any private data of one customer should not be visible to any other users. To prevent the above-mentioned security problems, following are some of the defensive mechanisms used by organizations. Deterrent Control − Know you potential threat to reduce cyber-attack. Preventive Control − Maintain high level authentication policy to access your cloud. Detective Control − Monitor your users and detect any potential risk. Corrective Control − Work closely with different teams and fix the issues that arise during the detective control phase. Learning working make money
Microservice Architecture Tutorial Job Search Microservice Architecture is a special design pattern of Service-oriented Architecture. It is an open source methodology. In this type of service architecture, all the processes will communicate with each other with the smallest granularity to implement a big system or service. This tutorial discusses the basic functionalities of Microservice Architecture along with relevant examples for easy understanding. Audience This tutorial has been prepared for beginners to help them understand the basic concepts of Microservice Architecture. Prerequisites This is a very basic tutorial and to make the most out of it, a reasonable knowledge of basic computer programming and Service-oriented architecture is required. Learning working make money
Microservice Architecture – Quick Guide Microservice Architecture – Introduction Microservice is a service-based application development methodology. In this methodology, big applications will be divided into smallest independent service units. Microservice is the process of implementing Service-oriented Architecture (SOA) by dividing the entire application as a collection of interconnected services, where each service will serve only one business need. The Concept of Going Micro In a service-oriented architecture, entire software packages will be sub-divided into small, interconnected business units. Each of these small business units will communicate to each other using different protocols to deliver successful business to the client. Now the question is, how Microservice Architecture (MSA) differs from SOA? In one word, SOA is a designing pattern and Microservice is an implementation methodology to implement SOA or we can say Microservice is a type of SOA. Following are some rules that we need to keep in mind while developing a Microservice-oriented application. Independent − Each microservice should be independently deployable. Coupling − All microservices should be loosely coupled with one another such that changes in one will not affect the other. Business Goal − Each service unit of the entire application should be the smallest and capable of delivering one specific business goal. Let us consider an example of online shopping portal to understand microservice in depth. Now, let us break this entire E-commerce portal into small business units such as user management, order management, check-in, payment management, delivery management, etc. One successful order needs to proceed through all of these modules within a specific time frame. Following is the consolidated image of different business units associated with one electronic commerce system. Each of these business modules should have its own business logic and stakeholders. They communicate with other third party vendor softwares for some specific needs, and also with each other. For example, order management may communicate with user management to get user information. Now, considering you are running an online shopping portal with all of these business units mentioned earlier, you do need some enterprise level application consisting of different layers such as front-end, back-end, database, etc. If your application is not scaled and completely developed in one single war file, then it will be called as a typical monolithic application. According to IBM, a typical monolithic application should possess the following module structure internally where only one endpoint or application will be responsible to handle all user requests. In the above image, you can see different modules such as Database for storing different users and business data. At the front-end, we have different device where we usually render user or business data to use. In the middle, we have one package that can be a deployable EAR or WAR file that accepts request form the users end, processes it with the help of the resources, and renders it back to the users. Everything will be fine until business wants any changes in the above example. Consider the following scenarios where you have to change your application according to the business needs. Business unit needs some changes in the “Search” module. Then, you need to change the entire search process and redeploy your application. In that case, you are redeploying your other units without any changes at all. Now again your business unit needs some changes in “Check out” module to include “wallet” option. You now have to change your “Check out” module and redeploy the same into the server. Note, you are redeploying the different modules of your software packages, whereas we have not made any changes to it. Here comes the concept of service-oriented architecture more specific to Microservice architecture. We can develop our monolithic application in such a manner that each and every module of the software will behave as an independent unit, capable of handling a single business task independently. Consider the following example. In the above architecture, we are not creating any ear file with compact end-to-end service. Instead, we are dividing different parts of the software by exposing them as a service. Any part of the software can easily communicate with each other by consuming respective services. That”s how microservice plays a great role in modern web application. Let us compare our shopping cart example in the line of microservice. We can break down our shopping cart in the different modules such as “Search”, ”Filter”, “Checkout”, “Cart”, “Recommendation”, etc. If we want to build a shopping cart portal then we have to build the above-mentioned modules in such a manner that they can connect to each other to give you a 24×7 good shopping experience. Advantages & Disadvantages Following are some points on the advantages of using microservice instead of using a monolithic application. Advantages Small in size − Microservices is an implementation of SOA design pattern. It is recommended to keep your service as much as you can. Basically, a service should not perform more than one business task, hence it will be obviously small in size and easy to maintain than any other monolithic application. Focused − As mentioned earlier, each microservice is designed to deliver only one business task. While designing a microservice, the architect should be concerned about the focal point of the service, which is its deliverable. By definition, one microservice should be full stack in nature and should be committed to delivering only one business property. Autonomous − Each microservice should be an autonomous business unit of the entire application. Hence, the application becomes more loosely coupled, which helps to reduce the maintenance cost. Technology heterogeneity − Microservice supports different technologies to communicate with each other in one business unit, which helps the developers to use the correct technology at the correct place. By implementing a heterogeneous system, one can obtain maximum security, speed and a scalable system. Resilience − Resilience is a property of isolating a software unit. Microservice follows high level of resilience in building methodology, hence whenever one unit fails it does not impact the entire business. Resilience is another property
Discuss Microservice Architecture Microservice Architecture is a special design pattern of Service-oriented Architecture. It is an open source methodology. In this type of service architecture, all the processes will communicate with each other with the smallest granularity to implement a big system or service. This tutorial discusses the basic functionalities of Microservice Architecture along with relevant examples for easy understanding. Learning working make money
Microservice Architecture – Scaling Scaling is a process of breaking down a software in different units. Scaling also defines in terms of scalability. Scalability is the potential to implement more advance features of the application. It helps to improve security, durability, and maintainability of the application. We have three types of scaling procedures that is followed in the industries. Following are the different scaling methodologies along with the corresponding real-life examples. X-Axis Scaling X-axis scaling is also called as horizontal scaling. In this procedure, the entire application is sub-divided into different horizontal parts. Normally, any web server application can have this type of scaling. Consider a normal MVC architecture that follows horizontal scaling as shown in the following figure. As an example, we can consider any JSP servlet application. In this application, the controller controls every request and it will generate view by communicating with the model whenever necessary. Normally, monolithic applications follow this scaling method. X-Axis scaling is very basic in nature and it is very less time consuming. In this methodology, one software will be scaled depending on its different task that the unit is responsible for. For example, the controller is responsible for controlling the incoming and outgoing request, the view is responsible for representing the business functionality to the users in the browser, while the model is responsible to store our data and it works as the database. Y-Axis Scaling Y-axis scaling is also called as a vertical scaling that includes any resource level scaling. Any DBaaS or Hadoop system can be considered to be Y-axis scaled. In this type of scaling, the users request is redirected and restricted by implementing some logic. Let us consider Facebook as an example. Facebook needs to handle 1.79 million users in every second; hence, controlling the traffic is a huge responsibility of Facebook network engineers. To overcome from any hazard, they follow Y-axis scaling which includes running multiple servers with the same application at the same time. Now in order to control this huge level of traffic, Facebook redirects all the traffic from one region to a specific server, as depicted in the image. This transferring of traffic based on the region is called load balancing in architectural language. This method of breaking down resources into small independent business units is known as Y-Axis scaling. Z-Axis Scaling X- and Y-axis scaling is pretty much easier to understand. However, one application can also be scaled at the business level, which is called as Z-axis scaling. Following is an example of scaling a cab service application in the different verticals of business units. Advantages of Scaling Cost − Proper scaling of a software will reduce the cost for maintenance. Performance − Due to loose coupling, the performance of a properly scaled software is always better than a non-scaled software. Load distribution − Using different technologies, we can easily maintain our server load. Reuse − Scalability of a software also increases the usability of the software. Learning working make money
Microservice Architecture – Blueprint Microservice implements SOA internally. In a broader sense, we can consider it as a subset of one SOA application. Rule & Workflow Following are the principles that need to be taken care of while developing a microservice. High Cohesion − All the business models need to be sub-divided into the smallest business part as much as possible. Each service should be focused to perform only one business task. Independent − All the services should be full stack in nature and independent of each other. Business Domain Centric − Software will modularize according to the business unit and is not tier based. Automation − Testing deployment will be automated. Try to introduce minimal human interaction. Observable − Each service will be full stack in nature and they should be independently deployable and observable like an enterprise application. Team Management “Two Pizza Rule” is a kind of rule that restricts the number of attendees in a microservice development team. According to this rule, number of the team members of one application should be so small such that they can be fed by two pizza. Generally, the number should not be more than 8. As microservice is full stack in nature, the team is also full stack in nature. To increase the productivity, we need to build one team of maximum 8 members with all kinds of expertise required for that service. Task Management Task is an important role in software development life cycle. Developing a large scale application can be broken down into several small units of task. Let us consider we need to develop one application such as Facebook. Then, “Log in” functionality can be considered as a task of the entire build process. Progress for each of these tasks need to be monitored properly under highly skilled professionals. Agile is the well-known process structure followed in the industries to keep up with good task management. Learning working make money