Microservices Full Course [2024] | Microservices Explained | Microservices Tutorial | Edureka

Summary

The Edureka course on microservices offers a comprehensive overview of building software applications with a microservices architectural style, opposed to traditional monolithic systems. It delves into the benefits of using microservices, such as independent development, fault isolation, and scalability, while also addressing challenges like debugging and configuration. The course explains the contrast between microservices and APIs, emphasizing the role of APIs in communication between services. Additionally, it discusses the need for effective security measures in microservices and the importance of design patterns. The session ends with a series of frequently asked interview questions and practical insights on implementing microservices using Java, Spring Boot, and Kubernetes.

Highlights

• Microservices help build scalable and resilient systems by using small, autonomous services. 🚀
• Monolithic architectures are tightly coupled, whereas microservices are loosely coupled, allowing independent scaling. 🔄
• APIs serve as bridges for communication among microservices, streamlining data flow. 🔗
• Security in microservices involves user authentication and protection of data across services. 🛡️
• The tutorial provides examples with practical applications such as e-commerce sites using microservices. 🛍️

Key Takeaways

• Microservices allow independent and scalable development, contrasting with monolithic architecture. 🏗️
• APIs facilitate communication between microservices, making interactions smooth and efficient. 🌐
• Effective security measures are crucial in microservices to protect user data and services. 🔒
• Implementing microservices requires a switch from monolithic to distributed systems for better flexibility. 🔄
• The course provides practical insights into setting up microservices using tools like Java, Spring Boot, and Kubernetes. 💻

Overview

Microservices are transforming how software applications are developed by splitting large systems into small, autonomous services that can be developed, deployed, and scaled independent of one another. This approach contrasts sharply with monolithic architecture, where applications are a single, tightly coupled unit that is often difficult to manage and scale.

Key components of microservices include communication through APIs, which facilitate seamless interaction between services. Security is a pivotal part in this architecture to ensure that user data and access permissions are handled properly. Design patterns also play a crucial role in ensuring the microservices architecture is efficient and reliable.

Through practical demonstrations using Java, Spring Boot, and Kubernetes, the course explains the transition from monolithic systems to microservices. It highlights the benefits of microservices such as independent development and the challenges like configuration management, offering solutions and best practices to tackle these issues effectively.

Chapters

• 00:00 - 00:30: Music Intro The chapter introduces the concept of microservices, emphasizing it as a modern methodology for constructing software applications. It details how an application under this architecture consists of a set of small, independent services that are loosely coupled. This design allows each service to be developed, deployed, and scaled separately from the others.
• 00:30 - 01:30: Introduction to Microservices In this introductory chapter on microservices, the course begins by encouraging viewers to subscribe to the Edureka YouTube channel for updates on trending technologies. It also promotes their microservices certification training. The agenda for the session includes discussing the fundamentals of microservices, starting with an explanation of what microservices are.
• 01:31 - 02:59: Agenda and Overview In this chapter, the agenda includes an overview of microservices compared to traditional monolithic architectures. It covers the tools, design patterns, and security aspects of microservices. Additionally, it explores the differences between microservices and Service-Oriented Architecture (SOA), as well as the distinctions between microservices and APIs. The session concludes with a summary discussion on these topics.
• 03:00 - 05:00: What are Microservices? The chapter introduces microservices and aims to answer key microservices interview questions. It promises to provide a comprehensive understanding of what microservices are and their application in building scalable and resilient systems.
• 05:01 - 08:00: Monolithic Architecture The chapter titled "Monolithic Architecture" begins with a discussion on the need for microservices as an evolution from previous architectural patterns. The text explains what monolithic architecture entails. Specifically, it describes monolithic architecture as an architectural pattern where the entire software system is designed as a single, self-contained piece. This means all the components within a monolithic system are interconnected and interdependent. The chapter suggests that there are certain disadvantages to the monolithic architectural pattern, which might be a driving factor for the adoption of microservices. However, the details of these disadvantages are not provided in the excerpt.
• 08:01 - 15:00: Disadvantages of Monolithic Architecture Monolithic architecture results in tightly coupled software where all components and their dependencies must be present to execute or compile code. This leads to a situation where every component is dependent on others, forming a tightly packaged system. It is likened to a 'big container' where all software components are assembled together, which can pose significant challenges if changes or issues arise in individual components.
• 15:01 - 18:00: Introduction to Microservice Architecture This chapter introduces the concept of microservice architecture by contrasting it with traditional monolithic architecture. The transcript describes a typical monolithic setup, where server-side applications execute domain-specific logic, handling everything from database interactions to rendering HTML views. It highlights the drawbacks of tightly coupled components within a monolithic architecture, setting the stage for understanding the benefits of a microservice approach.
• 18:01 - 25:00: Features and Advantages of Microservices The chapter discusses the features and advantages of microservices, using the example of an e-commerce website like Amazon or Flipkart. It explains the concept of monolithic architecture, where an application is deployed as a single unit, encompassing services such as customer service, product service, and cart service, all accessible to the customer through their browser.
• 25:01 - 29:00: Companies Migrating to Microservices The chapter discusses the transition of companies towards microservices architecture. Initially, companies have monolithic applications where services like customer service, product service, and cart service are deployed as a single application. These applications can be scaled by running multiple instances behind a load balancer. The chapter outlines the advantages of monolithic applications, highlighting their simplicity in development and deployment, facilitated by development tools and IDEs specifically designed for monolithic architecture.
• 29:01 - 33:00: Comparison: Monolithic vs Microservices The chapter discusses the differences between Monolithic and Microservices architectures. It begins by explaining the deployment process of a monolithic architecture, where an executable file (such as a war file) is deployed at runtime to launch the application. The chapter notes that scaling in a monolithic system is relatively straightforward; you can run multiple copies of the application behind a load balancer. However, the chapter points out that monolithic architectures come with drawbacks, particularly for large and complex applications.
• 33:01 - 70:00: Microservices Tools Overview The chapter discusses the challenges and disadvantages of developing large applications, particularly how they become complex to understand and modify. This complexity leads to slower development processes and the breakdown of modularity over time. As a result, implementing changes becomes difficult, which affects the quality of the code negatively. Furthermore, as the application size and the number of teams working on it increase, the difficulty in understanding and modifying the application intensifies, further slowing down development.
• 70:01 - 100:00: Security in Microservices The chapter discusses the challenges of security in microservices, particularly in comparison to monolithic applications. It highlights that large codebases are difficult to understand and modify, slowing down the Integrated Development Environment (IDE) and reducing developer productivity. The narrative explains how a monolithic application, due to lacking modularity, becomes a barrier to continuous development and frequent deployments. It emphasizes that updating a single component often necessitates redeploying the entire application, thereby interrupting background tasks and complicating the development process. This leads to a discussion on how microservices can offer a solution by allowing more modular and independent service management.
• 100:01 - 132:00: Design Patterns in Microservices The chapter focuses on the challenges and design patterns in microservices, particularly in an e-commerce context. It highlights issues such as the need to redeploy the entire application even for updates to a single service like the card service. This can lead to potential failure of components due to dependencies, increasing the risk of redeployment and discouraging frequent updates. The discussion touches on scalability, emphasizing that while scaling is often mentioned as an advantage of microservices, there are complexities involved that can hinder this benefit.
• 132:01 - 162:00: Spring Boot Setup and Installation The chapter discusses the challenges associated with scalability in Monolithic architecture. It highlights how each instance of an application in Monolithic architecture accesses all data, which makes caching ineffective and increases memory consumption and input/output traffic. The chapter also points out that different application components have varied resource requirements, some being CPU intensive while others may be memory intensive, and in Monolithic architecture, it's impossible to scale each component independently.
• 162:01 - 200:00: Hands-On: Microservices with Spring Boot The chapter discusses the architecture and challenges of a microservices system using Spring Boot. It features different services such as customer service, product service, and card service, which can be scaled independently. However, the tightly coupled nature of these services means that if one fails, like the product service, it can cause the whole system to go down.
• 200:01 - 205:30: Conclusion and Certifications In the conclusion and certifications chapter, the transcript discusses the instability and unreliability of the monolithic architecture. It explains that in a monolithic system, a bug in any module can affect the entire application because all modules run within the same process. If a bug occurs, it compromises the availability of the entire application since all instances are identical. Furthermore, the monolithic architecture is criticized for being inflexible, as adopting new frameworks or languages becomes challenging when the system comprises millions of lines of code written in a specific framework. Transitioning to a new framework would be costly.

Microservices Full Course [2024] | Microservices Explained | Microservices Tutorial | Edureka Transcription

• 00:00 - 00:30 [Music] microservices is a modern approach to build software applications where an application is composed of collection of small and autonomous services microservices are Loosely coupled meaning that they can be developed diploid and scaled independently of one another hi everyone welcome to this
• 00:30 - 01:00 microservices full course but before we get started if you like our videos then please do not forget to subscribe to edureka YouTube channel and hit the Bell icon to stay updated with all the latest trending Technologies also if you are interested in our microservices certification training then please click on the link given in the description box below now let us get started with our agenda for today in this session we will be discussing the microservices fundamentals including what
• 01:00 - 01:30 microservices are and how they differ from traditional monolithic we will also cover the microservices tools as well as the design patterns of microservices after that we will cover the microservices spring boot followed by the microservices security we will also look into the difference between microservices and SOA and the next difference is microservices versus API we will wind up this session with some
• 01:30 - 02:00 of the most important microservices interview questions by the end of the session you will have a solid understanding of what microservices are and how they can be used to build scalable and resilient systems so let us dive in and learn more about the exciting and rapidly growing field now without any delay let us get started with our first topic that is what are microservices [Music]
• 02:00 - 02:30 why we need microservices so before microservices we all know that there was an architectural pattern called monologic architecture that was used all right so there are certain disadvantages of that architecture but let me first explain you that architecture what exactly monolithic architecture means so basically in this the entire software is composed in a single piece that is designed to be self-contained so what I mean by that basically all the components of a monolithic program are interconnected and interdependent or in
• 02:30 - 03:00 other words if I have to put it I'll say that it will give you a tightly coupled software where each component along with its Associated components must be present in order to execute or compile the code so all of these components are actually dependent on each other so if you notice a definition that is there in front of your screen it says that monolithic architecture is like a big container right think of it as a big container wherein all the software components of an application are assembled together and tightly packaged right so if you notice that there is an
• 03:00 - 03:30 example in front of your screen so there's a server side application right which executes a domain specific logic it will retrieve and update data from the database and at the same time populate the HTML views to be sent to the browser so it is basically a big container or I can say that it is not divided into small small services or not divided into small small component so even these components that are there are pretty tightly coupled right so I'll give you a better example of what exactly monolithic architecture is let me just move forward so let us discuss a
• 03:30 - 04:00 classic example of an e-commerce website like Amazon or Flipkart all right so everyone actually visits these websites quite often so that's a perfect example to you know explain you so let's understand what monolithic architecture exactly means with this example so as you see that in basic e-commerce application we have a common option of customer service right product service and card service which a customer can access through their browser right and when you launch the application it is deployed as a single monolithic application there's only one single
• 04:00 - 04:30 instance if you can notice so we have customer service product service and card service and when you deploy all these Services it will be basically a single monolithic application now what you can do is in order to scale it you can run multiple instances of this application behind a load balancer right now let me discuss few advantage of this application so first of all it is very very simple to develop right as a goal of the development tools and IDs is to support the development of monetary application it makes the development really easy and one directional all right now it's pretty simple to deploy
• 04:30 - 05:00 because you have to deploy the executable file at the runtime to launch the application that executable file can be a war file as well now it is pretty simple to scale as well because you know in order to scale your application all you have to do is run multiple copies of the application behind a load balancer now since everything comes with its pros and cons monolithic architecture also has few major drawbacks let's discuss about them one by one the first disadvantage is large and complex applications now if you have a large application or you can say with the
• 05:00 - 05:30 increase in size of the application it becomes really complex to understand and modify such applications right and as a result development slows down and modularity breaks down over time moreover because it can be difficult to understand how to correctly Implement a change and due to that the quality of code declines over time let's see what is the next disadvantage so the next disadvantage is slow development so what I mean by that as the application and the respective teams grow the application becomes difficult to understand and modify right because it's pretty huge in size and there are multiple teams working on it so it
• 05:30 - 06:00 becomes really difficult to understand and modify also the larger the code base leads to slower ID which makes the developers less productive so the code base is pretty large because the entire application is one monolithic application right there are not different different Services present now it blocks continuous development so what I mean by that a large monolithic application is an obstacle to frequent deployments let me tell you how in order to update one comp opponent you have to redeploy the entire application which interrupts the background task so if I have to take the example of the
• 06:00 - 06:30 e-commerce website if I have to update the card service I have to redeploy the entire application the entire application which includes the customer service the product service all the services right so there's also a chance at components that haven't been updated will fail to start correctly all right because of many dependency issues or anything right and as a result the risk associated with redeployment increases which discourages frequent updates I hope you're getting my point let's see what we have next so the next point is unscalable I know I've told you that it's pretty easy to scale but let me
• 06:30 - 07:00 tell you what are the disadvantages when it comes to scalability and in terms of Monolithic architecture so each copy of application instance will get access to all of the data right which makes caching less effective and increase memory consumption along with input output traffic also different application components have different resource requirements one might be CPU intensive right while other might be Memory intensive architecture we cannot scale each component independently right so if you can see the example that is there in
• 07:00 - 07:30 front of your screen so here we have customer service product service and Card Services is one instance and this is how we are scaling it right if I have to increase only the customer service I have to scale up the customer service I have to do that for product and card service as well right now it is pretty unreliable as well let me tell you how so because of the tightly coupled components if one of them goes down the entire system will fail to run what I mean by that if one of my say product service fails that will in turn lead to the downfall of my entire application
• 07:30 - 08:00 right and because all the modules are running within the same process a bug in any module can potentially bring down the entire process moreover since all the instances of the application are identical the bug will impact the availability of the entire application this makes the monolithic architecture highly unstable and unreliable the last and the final point is inflexible so how is it inflexible guys with the monastic architecture it becomes really difficult to adopt the new Frameworks and languages suppose you have million lines of codes written with XYZ framework now it would be extremely expensive in terms
• 08:00 - 08:30 of time as well as cost to rewrite the entire application to use the newer ABC framework right even if that framework was considerably better and as a result there is a huge barrier to adopting new technologies I hope you're getting my point so why is it very expensive because you know you have written million lines of code in some language now if you want to use some other language right so it becomes really expensive and a time consuming task and even if the new language of the framework is considerably better but you know there's a huge barrier interrupting
• 08:30 - 09:00 such new technology so I hope you have understood the various disadvantages of Monolithic architecture now is the time to understand what exactly is microservice architecture microservices also known as microservice architecture is an architectural style that structures an application as a collection of small autonomous Services modeled around a business domain now if I have to put it in simpler terms basically it is a self-contained process which avails different and unique business capabilities now if you have
• 09:00 - 09:30 large applications built using this architectural pattern it can be broken down to small multiple Services which together acts as one large system but behind the scene it's a microservice so what I'm trying to say here is we have multiple services on all of these Services they don't share the data structure but they'll be communicating through apis right the major advantage of breaking down the system is now each microservice can focus on only one single business capability which definitely leads to a better quality anthrope and it's obviously becomes easy
• 09:30 - 10:00 for you to understand when I explain you with a example again I'm going to take the e-commerce side example now if you remember in monolithic architecture all the components were in a single module but if you see here with microservice architecture all the components are divided into separate modules which communicate with each other using a well-defined interface usually rest for messaging now the communication between the microservices is a stateless communication where each pair of requests and response is an independent transaction and because of this
• 10:00 - 10:30 microservices can communicate effortlessly moreover in microservice architecture the data is Federated all right so let me just break it down for you each microservice is responsible for its own data model and data because of which interaction with each microservice is handled by different instance unlike in monolithic architecture where we had only one instance here we have multiple instances for different different microservices so we have three microservices here customer microservice product microservice and cart microservice right each of them have
• 10:30 - 11:00 their own instances they have their own data model and they have their own data so this is what exactly microservice architecture is now let's dig a bit deep into its architecture and understand what it is now as you can see in a microservice architecture service is a small independent and Loosely coupled so let me just tell you where it is so with these are multiple Services right so these are pretty small in size and they're independent and Loosely covered now each of these Services have a separate code base which can be managed by a small development team and it is deployed independently right so this
• 11:00 - 11:30 service will have a code basis service will have a code base this service will have a code bit similarly all of them will have a code base which will be not huge in size when you compare it with the monolithic architecture where all of the services are running in one instance I hope you're getting my point now basically a team can update an existing service without rebuilding and deploying the entire application for example if I have to update this particular service I don't have to do it for the other services as well I can just redeploy the service independently now services are responsible for persisting their own data or external State internal implementation details of each services
• 11:30 - 12:00 are hidden from other services moreover they don't need to share the same technology stack libraries or Frameworks as well right you're getting my points so they might not have the same technology or same libraries or the same framework and they have their own database and things like that so they are pretty independent from each other besides for the microservices themselves some other components appear in typical microservice architecture so let me just discuss that so the first part is management so the management component is responsible for placing services on nodes identifying failures rebalancing
• 12:00 - 12:30 Services across nodes and so forth right then let's talk about service discoveries now service Discovery the task of this uh component is to basically maintain a list of services and which nodes they are located on it enables service lookup to find the end point for a service let's talk about API Gateway now right so API Gateway is basically the entry point for clients so this client won't call all these Services directly right it will first go to this API Gateway which will forward the call to the appropriate services on the back end
• 12:30 - 13:00 right if I'm a client I'll request for this particular service then I have to call the API Gateway and which will in turn call the service on the back end now the API Gateway might aggregate the responses from several services and return the aggregated response now it might be possible Right a client request for multiple services so at that time it will aggregate the results from various services and return the aggregated response right so I hope I am clear with the architecture let us focus on what are the features of microservices architecture the first feature is small focused so what it means it means that
• 13:00 - 13:30 the aim of microservice Architecture is Simplicity you know so that it can be Rewritten and maintained without any extra efforts by the development team right that's what I mean by small focused then the next point is Loosely coupled so as I've already mentioned multiple times that each microservice is independent of each other and do not need to coordinate as well this makes the development as well as a deployment at real quick guys right so if I have to update a particular service I'll only update that service I won't you know
• 13:30 - 14:00 update the other services right so that way deployment becomes really quick so that's the big Advantage now let's talk about language neutral so to be a good microservice it must be language neutral so what I mean by that for example in an application few Services can be written in Python for fast deployment whereas few might be written in Java because it's speed and extensive libraries right so depends on the microservice what kind of programming language we are using so it doesn't really affect the other services right now bounded context so it means that each microservice doesn't
• 14:00 - 14:30 need to understand the implementation of other microservice so these are a few features of microservice architecture now let's talk about various advantages of microservice architecture now the firstly independent development so each microservices can be developed independently where a single development team can build test and deploy a service I think I don't need to explain this much independent development means if I have a product service and I can independently focus on product service where a team of developers are writing code for that particular service testing it and deploying it now independent
• 14:30 - 15:00 deployment means that you can update a service without having to redeploy the entire application bug fixes and feature releases are more manageable and less risky as well because you have to focus on one particular service you have to deploy update one particular service you don't have to care about the other services or the entire application as such right so next is Vault isolation so it is a very big Advantage guys if basically if a service goes down it won't take the entire application down with it for example if my card service goes down my entire application is largely unaffected unlike the monastic
• 15:00 - 15:30 architecture where if one of my component goes down the entire application fails to work next is mixed technology stack because of this feature your teams can pick any technology which fits best for their service right and last but not least granular scaling which means that Services can be scaled independently unlike my monolithic architecture where you know I have to deploy multiple instances so in order to scale here I can only scale a particular service if I have to you know increase the card service then I can just scale up the card services instead of scaling up the entire application all right so
• 15:30 - 16:00 let's move forward so there are a lot of companies which are using microservices we have Amazon Netflix SoundCloud Twitter Uber PayPal a lot of companies right and why this happens because large applications become easier to manage when they're broken down into smaller comparable pieces so without any further delay let's begin with our Hands-On we'll be using spring boot because it provides a way to provide Java applications quickly and simply through an embedded server and by default it is version of Tomcat it will basically eliminate the need of java double e containers and with spring
• 16:00 - 16:30 boot we can expose components such as rest Services independently exactly as proposed in the microservice architecture that we have just discussed in any maintenance of the components we no longer make the redeploy of its consumers I'll tell you what exactly I mean what is a consumer for this lab we'll use Eclipse oxygen and Maven 3 now to illustrate the concept of microservice what we'll do we'll create three Maven projects in this Hands-On and each of them will symbolize backend functionality or you can say reusable
• 16:30 - 17:00 apis and one of them held composition if I have to put it in simpler way I will say it will be a consumer of the other two so one application or one service will be a consumer of the other two Services right so we'll be creating three simple Maven projects that I've already done I'll just open my clips and show you that so my first Maven project is basically diagnosis microservice then we have doctor microservice and we have patient microservice so this doctor microservice is the consumer right and uh consumer of the other two microservices that is patient and a
• 17:00 - 17:30 diagnosis all right so that is how it is done now if I have to explain one of these Services let me explain you the patient microservice first so over here as you can notice that we have a form.xml file so basically the sperm.xml file will establish all the dependencies right before we start coding the first class that we create that we call application will be identical in all three projects and it only works as an initiator to Spring boot that we call as spring boot application annotation so that's how it is if you notice here we
• 17:30 - 18:00 have application dot Java so it will be common application.java and application configuration.java are the two packages that we have created will be common for all the other microservices as well so if I show you for doctors as well so here also we have application.java and application config.java similarly for diagnosis as well if you notice we have both application.java and the other things as well now we have patient.java and we have patient arrests.java right so the patient.java here we have defined
• 18:00 - 18:30 all the variables like you know the email ID of the patient name and things like that and this patient rest.java will be used to provide the input to the variables I hope you're getting my point patientress.java is basically to provide the input I won't be explaining the code here in the upcoming tutorials I'll be explaining the entire microservice you know how the code works and and everything all the technical details you can find in the next tutorial and just I'm just giving you an overview of how things work in microservices and we have this application config class as well right the package so let me tell you why
• 18:30 - 19:00 we actually use it is basically it is a resource configuration class which is basically a resource manager responsible for exposing rest services for application consumers right so basically for messaging right so the rest services for messaging and it is a stateless service for application consumers and we can notice that patients of java and patient rest or Java are in the same package right now let me tell you how I've defined the ports here so all I have to do is right click go to properties click on run
• 19:00 - 19:30 debug settings and when I go to arguments right so I just have to write minusdserver.port 8081 so you can see that my patient microservice will be running at a port 8081 when I start it let me just start all of these Services one by one so I'll start this first just click on uh run a spring boot app similarly click on right click on this and I'll just run it as spring boot app again
• 19:30 - 20:00 and I'll run this also as a spring boot app so that's done now let me just open my browser all right so this is for Port 8081 right so my port 8081 is for patient so let me just click over there let me reload this page again so here I have my patient microservice similarly my port 8082 is for diagnosis right so here I have the diagnosis microservice and finally my port 8083 basically is a consumer all right it's a
• 20:00 - 20:30 doctor microservice and in the URL if you notice I have written patient ID right a diagnosis and consultation right so basically we'll get you know this particular patient has been diagnosed with this disease and this is the consultation all right so let me just reload this again for you so I can just go ahead and change the diagnosis as well I can make this as 2 right so Rachel has been diagnosed with a different disease now similarly if I
• 20:30 - 21:00 make it as one she has been diagnosed with viral fever here right so that is what the difference is basically this particular microservice is a consumer of the other two Services right so you can even think of it as an e-commerce application I know it's it's not of that level but consider it something like you know customers production orders so this patient microservice will become the order microservice right and the other two will become customer and products so this order microservice will be a consumer of the product and customers so similarly in this example we have
• 21:00 - 21:30 patient and doctors we have patient microservice and we have diagnosis microservice and we also have a doctor microservice which is actually a consumer of the other two service foreign why do companies migrate from monolithic to microservices in this case we shall take an example to help you understand better Netflix is one of the earlier most well-known adopters some other well-known examples are eBay Amazon Twitter alician Etc
• 21:30 - 22:00 in 2009 Netflix face Growing Pains its infrastructure can keep up with the demand for its rapidly growing video streaming services the company decided to migrate its IIT infrastructure from its private data center to our public cloud and replace its monolithic architecture with a microservices architecture the only problem was the term my microservices didn't exist and the structure wasn't well known Netflix became one of the first high profile companies to
• 22:00 - 22:30 successfully migrate from a monolith to a cloud-based microservices architecture it won the 2015 Jack special Duty award due to this infrastructure that internalized devops today Netflix has more than 10 000 microservices that manage and support separate parts of the platform while its Engineers deploy code frequently sometime thousands of times each day and another example we have is atlassian Corporation PLC or public Company Limited it's an Australian software company founded in 2002 and its
• 22:30 - 23:00 headquarter is in Sydney Australia they develop products for software developers project managers and other software development teams atlassian follow the path to microservices in 2018 of the day phase growing and scaling challenges with jira and confluence they found that the single tenant monolithic architecture running on premises will not be able to scale for future needs now they decided to re-architect jira and Confluence and move them from a stateful single tenant monolithic system to Mother tenant stateless Cloud
• 23:00 - 23:30 application hosted by Amazon web services they will decompose them over time into microservices the project was named vertigo it was their largest infrastructure project till date taking two years to complete the transition to AWS migrating more than 100K customers in just over 10 months with no service Interruption they also committed to decomposing the services to microservices now let's come to our topic for today that is monolithic versus microservices so as the first
• 23:30 - 24:00 point of comparison we have the definition a monolithic architecture is a traditional model of software programs which is built as a unified unit that is self-contained and independent from other application whereas a microservices architecture also simply known as microservices is an architectural method that relies on a series of independent Deployable services secondly we have deployment in monolith architecture one executable file or directory makes deployment
• 24:00 - 24:30 easier whereas in microservices architecture they have independent Deployable since microservices are individual unit they allow for fast and easy independent deployment of individual features thirdly we have scalability in monolithic architecture you can scale individual components whereas in microservices due to flexible scaling if a microservices reaches load capacity new instances of that Services can rapidly be deployed to that accompanying
• 24:30 - 25:00 cluster to help relieve pressure fourth we have reliability in monolithic architecture if there's an error in any module it could affect the entire applications availability whereas on the other hand with microservices architecture you can deploy changes from a specific service without the threat of Bringing Down the entire application the fifth comparison we have is development in monolithic architecture when an application is built with one code base
• 25:00 - 25:30 it is easier to develop whereas microservices add more complexity compared to our monolith architecture since there are more services in more places created by multiple teams the sixth comparison we have is flexibility in monolithic architecture due to lack of flexibility a monolith constrained by the Technologies already used in the monolith whereas microservices architecture on the other hand is flexible so microservices architecture allow teams the freedom to select the
• 25:30 - 26:00 tools they desire and the last comparison we have is debugging in monolithic architecture debugging is easier with all codes located in one place it's easier to follow a request and find an issue on the other hand each microservices has its own set of logs which make debugging more complicated now if you ask me what are microservices my answer would be really simple
• 26:00 - 26:30 microservices tools are basically a collection of various tools and Technologies having different functionalities these tools are used in various stages of building an application and help the developer to work with ease all right so they come with basically predefined functions algorithms and a very user-friendly GUI to make sure that you know developers can build their applications in an easy manner not only this but startups to multinational companies have been using microservices in their day-to-day business activities today and to make sure that you know they can build the
• 26:30 - 27:00 application in an easy way many other companies are building up new tools and Technologies right so while building an application using microservices I would not say that you know only a single tool is enough maybe I would say a couple of tools together will help you build the application in a more easy way so on that note let's look into the different tools that we can use for different purposes so starting with the first one that is operating system now one of the most important factors of building an application is setting a proper Foundation of your application so this
• 27:00 - 27:30 is basically done by the operating system now Linux is one such operating system which is most commonly used in today's market to build applications with the help of Linux containers it provides a self-contained execution environment and lets you orchestrate small to big services like security networking and Storage so if you ask me what are the better choices of Linux family then I would say red hat and Ubuntu are the go-to solutions for anybody in today's market but they come with a lot of unnecessary
• 27:30 - 28:00 functionalities which are not needed for microservices apart from these Linux providers have also come up with tools such as atomic red hat and Ubuntu including lxt which is basically a container oriented hypervisor so I would say that you know you can go for any operating system that your company chooses to build an application or maybe you're comfortable with but Linux is one such operating system which is growing in today's market and helps the developers to build the applications easily now let's move forward with the next one
• 28:00 - 28:30 that is programming languages now the main advantage of microservices that different languages and Technologies can be used to build different Services of the same application so what I mean by that is you know let's say you have five services in the same application now the first service can be built using python the second one can be built using Java the third one can be built using co-programming language and so on so it basically gives the developers the freedom to choose the technology stack and build the application but the most popular programming languages used in
• 28:30 - 29:00 microservices are spring Boot and elixir so talking about spring boot first spring boot basically simplifies the creation of rest based microservices with the help of springboard Frameworks in just a few lines of code right so if you ask me the features of springboard then it provides Auto configuration to load a set of default configurations for quick start of the applications it comes with embedded Tomcat servlet containers and Jetty to avoid the usage of War files spring boot also has an opinion to reduce the developer effort and
• 29:00 - 29:30 simplifies the maven configuration and finally it consists of a wide range of apis for monitoring and managing applications in the development side and also on the production side so springboard is one such programming language guys which is very famous in the field of microservices and you would always see that you know developers are trying to build microservices using this particular framework alright so that was about springboard next let's move forward with the next programming language that is Alexia now Alexia is a general purpose programming language which runs on the
• 29:30 - 30:00 airline virtual machine now Alexia shares the same abstractions for building fall tolerant and distributed applications so if you want me to mention few features of Alexia that I would say developers can easily write the code in short fast and maintainable banner this code basically runs an isolated lightweight processes which can be scaled individually for example let's say you know you have five processes right and you don't want to scale a particular process but you want to scale up the other processes well you can definitely do that apart from this
• 30:00 - 30:30 Alexia also makes sure that you know the application never goes down by providing the supervisors so basically these supervisors describe how different parts of the system can be restarted if something goes wrong and that is the main objective of microservices right so our main objective is basically that you know even if a particular service has gone down that doesn't mean that you know the application will go down instead the bug in that particular service has to be resolved and then the service has to be restarted and finally coming to the last feature that you know this programming language comes with its own build tools to create
• 30:30 - 31:00 projects manage tasks and run the required tests so Guys these were the two programming languages which are very popular in the field of microservices next in this session let's look into the different tools used for API management and testing now while you start building applications using microservices you also have to make sure that you know all the Individual Services communicate with each other using apis so each microservice can have its own API to communicate with the other servers so this is where basically the API
• 31:00 - 31:30 management and testing comes into the picture where all the apis are present in the system and must be properly managed and tested to get the desired results so if you want to know more about microservices and apis and how apis and microservices collaborate with each other you can refer to my session on microservices versus API now the top tools used in API management and testing are basically the postman and the API Fortress so starting with Postman so Postman is basically an API development suit which allows you to easily run UI
• 31:30 - 32:00 driven API tests with the help of Postman the exploration of restful API resources becomes very easy so what I mean by that is that you know with the help of Postman you can basically pass HTTP requests to test develop and get the required results now few features of Postman are as you can see on my screen Postman basically integrates with your software development lifecycle in ease it provides features to design apis and maintain multiple versions of API with support this tool can work for small
• 32:00 - 32:30 applications to pick application and it also supports collaboration of work by allowing you to save related API endpoints into a collection now once that is done what you can do is you can go forward and share the entire collection to the other Developers so Guys these are the few features of Postman next let's move forward with the next tool that is API Fortress Now API Fortress Is both an API test and health tool which automates the process of load testing Health monitoring and functional testing this tool is basically a code
• 32:30 - 33:00 free and is built around modern API architectural patterns and practices so if I have to mention few features of API Fortress for you then this tool is highly interoperable with any platform that you choose in your tool chain and validates apis built-in API management platforms it also simplifies API test creation and execution by providing a drag and drop GUI this tool also aims to simplify the end-to-end testing by providing easy generation of functional tests and also focuses to simplify the collaboration by storing the tests and
• 33:00 - 33:30 reports in a collaborative environment to make sure that you know teams can validate their own apis if it satisfies the business case so Guys these were the few features of API Fortress now once you know the tools for API management and testing the next thing that comes into a microservice system is basically how these Services communicate with each other well these Services communicate with each other using the messaging system so the different tools available for messaging are Apache Kafka and rabbitmq so talk about Apache Kafka
• 33:30 - 34:00 first this tool is a distributed published subscribe messaging system them originally developed at LinkedIn and later on became a part of the Apache project Kafka is scalable and agile and is distributed by Design so Apache Kafka is a distributed stream processing platform which can be used for data processing or API calls so few features of Apache Kafka are as you can see on my screen Kafka has high throughput for publishing and subscribing messages to maintain stable performance this tool guarantees zero downtime and zero data
• 34:00 - 34:30 loss in Apache Kafka messages purchased on the test as fast as possible and many applications can plug in and make use of this tool as it offers new ride connectors so Guys these are the various features of Kafka let's move forward with the next tool that is rabbitmq now this tool utilizes patterns to communicate between microservices and also scale applications simultaneously with the help of these tools you can basically connect microservices with each other to solve problems of various distributed systems not only this but
• 34:30 - 35:00 you can also use this tool to exchange events between individual microservices now the features of rabbit mqr as you can see on my screen this tool basically offers a variety of features such as reliability delivery acknowledgments including persistence publisher confirms and higher availability by using this tool messages are routed through exchanges before arriving at the queues rabbit mq comes with the Federation model and allows the servers that need to be more Loosely and unreliably connected and also supports messaging
• 35:00 - 35:30 over multiple messaging protocols so Guys these were few features of rabbit mq now once you know you're done with your API management and messaging the next thing is basically that comes on to everybody's mind is toolkits what do you understand by toolkits well toolkits in layman terms is a set of tools used for a specific purpose so in microservice architecture also you can build various kinds of application using different toolkits that are available in the market so the most popular toolkits
• 35:30 - 36:00 available in the market are fabric 8 and Seneca so talking about fabricate first so fabric 8 is a platform as Service Tool which helps the developers provide configuration management system through kit it is an open source tool which handles Port mapping and IB addresses complexity so the store basically holds the responsibility to load balanced services with high availability and scalability now the phases of this tool are as you can see on my screen it provides a set of wizards to create application faster and set up continuous
• 36:00 - 36:30 delivery pipelines fabric 8 also comes with on-premise kit repository hosting this tool provides Maven reposit the manager promoted releases along with the mirror of central Maven repositories and provides the developer console to create build managed microservices with deep visualization in into the projects applications and environments now talking about Seneca first Seneca is used for building message based microservices processes and is the toolkit for node.js so this toolkit helps you to write clean and organize
• 36:30 - 37:00 code with systematic business logic of the application so few features of synagar as you can see on my screen Seneca provides plugins which look after the foundation of the application you do not have to worry about which database has to be used and how to structure your components with Seneca in Seneca everything is written as a command and these commands get called whenever they match a set of properties and the code that you call does not know which command is calling it so guys this was all about Seneca now since you have understood about toolkits also the next
• 37:00 - 37:30 thing that I would like to talk about is the different architectural Frameworks so architectural framework is an important factor while building applications using microservices and the top two architectural Frameworks used are Goa and conch talk about Goa first so basically Goa is an architectural framework which provides a way to build rest apis and microservices using goal line with the help of this architectural framework you can design apis along with this required dependencies and this framework runs on top of the Google
• 37:30 - 38:00 Cloud platform few features of Goa as you can see on my screen this tool also lets you generate data structures validation of code and handlers once the design of API is set it has a decoupled engine and provides plugins which can Implement custom dsls and also generate arbitrary outputs so that was about Goa guys moving on to Kong Kong is used for ready to deploy plugins for enhancing the development and deployment of microservices with the help of this tool you can leverage the container and microservices design patterns to quickly
• 38:00 - 38:30 build api-centric applications now I've used this term microservices design patterns right so if you have to understand this term it's basically a pattern or you can say a software pattern through which a company follows based on which the application is built so if you want to know more about microservices design pattern you can refer to my session on microservices design pattern but until then moving back to this particular session if you ask me the features of Kong then Kong provides plugins to extend and connect Services across hybrid and multi-cloud
• 38:30 - 39:00 environments it analyzes real-time data and leverages ecosystems to deploy Kong with kubernetes Kong connects with automation tools to improve efficiency and reduce errors and provides role-based access control and encrypts end-to-end to comply with the industry regulations so guys that was about the different architectural Frameworks present in the world of microservices now once you build an application using microservices the next thing that comes into our mind is to how to scale the application well to scale this
• 39:00 - 39:30 application you have to use an orchestration system as microservices work with respect to containers and so container orchestration becomes an important aspect that has to be considered so in today's market there are various tools regarding the container orchestration for microservices but the top tools available in today's market are kubernetes and istio so talking about kubernetes first kubernetes is an open source container management or you can understand as an orchestration tool this tool basically owns the responsibilities of container deployment scaling and
• 39:30 - 40:00 descaling of containers and container load balancing so if you ask me a few features of kubernetes and I would say kubernetes can help you to deploy and update secrets and application configuration without rebuilding your image and without exposing secrets in your stack configuration in addition to managing Services kubernetes can also manage your batch and CI workloads thus replacing containers that fail if desired not only this but kubernetes only needs one command to scale up the containers or to scale them down whenever you're using CLI else scaling
• 40:00 - 40:30 can also be done by using the kubernetes dashboard right so if you want to know about dashboard also you can refer to my session on kubernetes dashboard and and finally coming to the last feature that is with kubernetes you can mount the storage system of your choice what I mean by that is that you know you can either opt for a local storage or choose a public cloud provider like gcp or AWS or perhaps use a shared network storage system like NFS or iSCSI so that was about kubernetes guys let's move forward
• 40:30 - 41:00 with the next tool that is istio now this tool supports service deployment on kubernetes so it basically provides features for manageability security and reliability to microservices communication now if you ask me how is it done well the answer is quite simple it is basically done by the service mesh technology which allows you to improve the relationships and interactions between applications and microservices so few features of SDR as you can see on my screen it performs automatic tracing monitoring and logging of the services
• 41:00 - 41:30 this tool automatically secures services to manage authorization authentication and encryption of communication between Services it also controls the flow of traffic and API calls between Services conducts a range of tests and upgrades with red or black deployments and finally also applies policies and ensures that their infos and resources are fairly distributed among the consumers so that was about istio guys now once API management is done you know messaging system is done and then you have your tools for orchestration also
• 41:30 - 42:00 the next thing is to monitor your application so to monitor your application the top tools that can be used is Prometheus and log stash so talk about Prometheus first Prometheus is a monitoring tool which basically allows visualizing monitoring information and supports time-based tracking for anomalous patterns which have to be detected also this is an open source tool which basically gathers monitoring information so the features for Prometheus are as you can see on my screen it provides a flexible query
• 42:00 - 42:30 language it comes with distributed storage and single server nodes which are autonomous it discovers targets via service Discovery or static configuration and provides dashboarding and graphing support now talking about the next monitoring tool that is log stash lockstash is also an open source tool through which you can check the logs this tool basically lets you stash centralize and transform data so the features of clock stash are as you can see on my screen it supports a variety of inputs Which pull in events
• 42:30 - 43:00 from multitude of common sources all at the same time this tool aims to transform and prepare data regardless of its complexity it also allows you to choose your own stash and transport data and finally it is a plugable framework consisting over 200 plugins to create and configure pipeline as you want so that was about log stash guys now finally moving on to the last part of today's session that is serverless tools now these tools are part of microservices which optimize the methodology of breaking stuff into small
• 43:00 - 43:30 functions so few serverless tools that are very popular are claudia.js and AWS Lambda talking about Claudia first Claudia is a serverless tool used for deployments for AWS Lambda and AP API Gateway this tool automates error-prone deployments and configuration tasks and also contains tools such as Claudia bot Builder and Claudia API Builder so features of Claudia are as you can see on my screen it lets you deploy an update using a single command it reduces the boilerplate code with the help of
• 43:30 - 44:00 this tool you can also manage multiple versions and you can use standard npm packages and do not have to learn Swagger so that was about Claudia now moving forward to the last tool that is AWS Lambda AWS Lambda is basically a tool which provides infrastructure less servers for your microservices builds and the user is charged based on the paper usage rate this tool can be used in combination with the AWS API Gateway to host a rest API service and with the help of this you can serve any request made by the
• 44:00 - 44:30 users so if you ask me a few features of AWS Lambda then I would say this tool enables you to run your code in response to the events and automatically manage to dependent compute resources it lets you run the code without managing the servers so it pays as you use the service and you only pay for the compute time consumed this tools case and application automatically by running a code for each trigger and finally I would say this tool can be used to build a serverless backend for processing mobile API and web requests
• 44:30 - 45:00 [Music] at number 10 we have microservices making it easy to build and maintain applications when the products that developers are working on become somehow stable and is actively used by the customers the daily work of the team splits in three different activities new future implementations bug fixings and changes of existing features so if the code is organized in a monolithic
• 45:00 - 45:30 structure chances are very high that the continuous integration delivery deployment pipeline will reflect the same structure which means that each and every change to the core base will need to pass to the test or build steps that are totally unrelated to the change itself so microservices resolve such organizational based issues and make it easy to debug and test applications with smaller modules going through a continuous delivery and testing process your ability to deliver error-free
• 45:30 - 46:00 applications is vastly improved on number nine we have microservices providing continuous delivery unlike monolithic applications in which dedicated teams one on discrete functions such as UI database server-side logic and technological layers microservices use continuous delivery model to handle the entire life cycle of an application so when developers operations and testing teams work simultaneously on a single service
• 46:00 - 46:30 testing and debugging becomes easy an instance with this approach of incremental development code is continuously developed tested and deployed and the code is used from existing libraries instead of Reinventing the wheel it's simple right just to make the changes than reinverting the wheel at number eight we have flexibility to use various tools for the required task a microservice environment Fosters an attitude of using
• 46:30 - 47:00 the most appropriate technology for the specific needs of a service each service uses its own language framework or ancillary Services while still being able to communicate easily with the other services in the application so what does it mean so suppose you have an application of n services so in that service 1 can be built on python service 2 can be built on Java service service tree can be built using c-sharp and so on each servers have their own
• 47:00 - 47:30 technology framework and are still being able to communicate to the complete application so now next in the list at number seven we have Packer Services offering cross-team coordination unlike traditional service oriented architectures which typically involves heavyweight inter-process Communications protocols microservices make entire application decentralized and decoupled into services that act as separate entities so microservices have various
• 47:30 - 48:00 teams handling various entities and then they communicate with each other to handle different functionalities for the application coming to number six we have microservices providing higher quality code well modularizing an overall solution into discrete components help application development teams focus on one small part at a time so this simplifies the overall coding and testing process at number five we have microservices providing granular scaling
• 48:00 - 48:30 when talking about scalability microservices seem to outperform many of the architectural choices out there since each service is a separate component you can scale up a single function on a service without having to scale up the entire application business critical Services can be deployed on multiple servers for increased availability and performance without impacting the performance of other services so microservices make it easy to identify scaling bottlenecks and then
• 48:30 - 49:00 resolve those bottlenecks at a per micro service level so whenever you feel the urge to scale some part of the system you can decide to split new small machines that will host only the service that provides the needed feature and nothing more at number four we have microservices reducing risk in the microservice framework each service is a separate entity so this framework allows localized changes and higher confidence in quality and end-to-end regression
• 49:00 - 49:30 scenarios basically even if one service or the component of the application is down then the complete application doesn't go down instead only that particular services or components needs to be rebuilt by the developers so this reduces the risk of complete fall of the business of your application at number three we have microservices promoting the best Big Data practices well microservices Naturally Fit within a
• 49:30 - 50:00 data pipeline oriented architecture which aligns the way in which Big Data should be collected ingested processed and delivered each step in a data pipeline handles one small task in the form of a microservice so if you have an application filled with the microservice architecture each microservice owns a private database to capture the data and implement the business functionality also let me tell you that the databases of microservices are updated only to the
• 50:00 - 50:30 service API next comes the most important point on number two we have microservices using minimal resources well microservices allows you to optimize the sources with microservices multiple teams work on Independent Services enabling you to deploy more quickly development time is reduced and your team's code will be more reusable so by this decoupling Services you won't have to operate on expensive machines basic machines will do the increased
• 50:30 - 51:00 efficiency of microservices not only reduces infrastructure costs but it also minimizes the downtime finally on number one I have microservices popularity and offering High salaries according to the indeed.com the average salary for a microservices ranges from approximately ninety seven thousand dollars per year for a software engineer and hundred and sixteen thousand dollars per year for a senior software engineer also many hyper
• 51:00 - 51:30 growth companies such as Netflix eBay Amazon PayPal Twitter use microservices in their architecture to scale their businesses so Guys these were the key reasons that why you should learn microservices [Music] why do we need design patterns so to understand this topic just consider the scenario where you have a team of developers let's say 30 developers right now you're given a project to basically
• 51:30 - 52:00 build similar kind of applications as a team lead what will you do you'll just divide these three applications to a group of 10 10 developers right so the group one will have project one group two will have project two group three will have project three and all these three groups will have each of 10 developers right so now when this team of developers start developing the application they can follow different set of processes right so when I say process what I mean that is the way they're developing the application right so they can follow a particular path to
• 52:00 - 52:30 develop an application right so let's say the group one is following process one group two is following process two and group 3 is following process three right now what can happen is that maybe process one works completely fine what I mean by that is that you know there's no errors and then whatever errors are coming also there's no latency time there's no disadvantage in using that kind of process right but if you consider any other two processes let's say process two and process three it may happen that you know there could be few errors and maybe that's not the right way to build the application right so
• 52:30 - 53:00 what could happen is that you know I'm not saying that you know process one is the only way to build an application maybe they have a better way when compared to process 2 and process three right so as a team lead what you clearly understand is that you know your development team cannot build the application using process 2 and process three right so to ensure that all the teams follow the same process or maybe a same pattern you can use this concept of design patterns when the teams working on various projects use the same pattern
• 53:00 - 53:30 to build similar applications right so basically they'll select a particular pattern and they'll build all the applications based on that particular pattern itself on that particular pattern you'll make sure that you know you have the maximum advantages that you can get for your application right so that is the need of design patterns guys basically if you have to understand stand the need in a single line then you can just understand the fact that you know design patterns are used to make sure that you know your complete theme is on the same plate and everybody is following the same process or maybe the
• 53:30 - 54:00 same pattern to build the application right so I hope you've understood what is the need of design pattern right so now let's understand what exactly design patterns are with my previous explanation you might have clearly understood that you know design patterns are basically a simple pattern based on which you build an application but yet if I have to Define design patterns for you then design patterns or software design patterns can be defined as a software template or a description to solve a problem that occurs in multiple instances while designing a software
• 54:00 - 54:30 application or a software framework right so I hope you've understood what exactly design patterns are they're basically just a software template or a pattern or maybe a description to solve a particular problem and that particular problem is seen in multiple instances right so when you want to solve a problem which is in multiple instances you can go forward and choose the design patterns right so now that you know what are design patterns let's move forward with principles behind microservices so the principles behind microservices are as you can see in my screen it
• 54:30 - 55:00 starts with independent and autonomous Services basically because you know each service has been independent of the other servers right that is because each service is either created for a domain or a business capability and each service has its own functionality right so that is the first principle coming to Second principle that is scalability so when you build micro Services what you can basically do is for example let's say you have four services for a specific business domain then what you can do is you can scale a specific service individually without scaling the others right so let's say in the example
• 55:00 - 55:30 that I took that is the e-commerce application we had free services right customers orders a product so if you want to scale the customer service individually you can definitely go forward and scale that particular service and you do not have to scale the orders of the product service similarly goes for the other services also coming to the third principle that is decentralization so decentralization is basically when you know you do not have a centralized architecture right what I mean by that is specific business domain when you build an application using
• 55:30 - 56:00 microservices your complete control is not there for a specific service right so all the controls are basically divided into Individual Services coming to resilient Services I would say microservices are resilient Services because you know let's say even if one service is completely down the complete application will not go down so in the e-comms application let's say if the product service is down that doesn't mean that you know your application will stop working only that particular service is not working and the team will be working on that particular service to get back the service right so the only
• 56:00 - 56:30 point that you have to understand is that you know even if a service goes down the complete application doesn't go down next we have is real-time load balancing so obviously when a client sends a requests it may happen that you know you have to retrieve data from multiple Services over there the load balancer comes into the picture and then it defines how much CPU or how much GPU should be used for a particular service to get the data and similarly how the client's request should be passed right so that's happening real time and in this kind of architecture the client doesn't have to wait for a really long
• 56:30 - 57:00 time right so you get the outputs within seconds coming to availability I think the principle itself defines its functionality it's basically means that the services are available 24 7 and all these Services can be basically used as much as they want right coming to the node right so once you understand devops you'll understand how to deploy a service and how to get the outputs right after that we come to the next principle that is seamless API integration and continuous monitoring all the micro Services have a specific API Gateway
• 57:00 - 57:30 which is basically the entry point to the client's request right so whatever client request has been sent it will be first sent to the API Gateway through which the request will be forwarded to the specific microservices and obviously these micro services are continuously monitored whether the response is sent back or not or maybe if the service is down or not coming to the next principle that is isolation from failures so when I say isolation from failures what I mean by that is you know all the services even if that down on maybe if they have any specific errors that
• 57:30 - 58:00 particular service will solve its own error and it won't disturb the complete application so let's say in the e-commerce application that we considered let's say if the product service is facing few errors then what will happen is only that particular service will be basically taken into account and the errors will be solved and those errors will not affect the application or maybe the other two Services coming to Auto provisioning auto provisioning is basically the ability to deploy the information by itself right so basically the service will generate the information for the client's request automatically without anybody's help right so Guys these were
• 58:00 - 58:30 the basic principles behind microservices that is independent and autonomous Services scalability decentralization resilient Services real-time load balancing availability continuous delivery through devops integration seamless API integration and continuous monitoring isolation from failures and auto provisioning right so guys I hope you've understood the principles behind microservices right so now once you start bringing microservices you often face few challenges through because of which you
• 58:30 - 59:00 have to start using design patterns so since this session is basically based on microservices we'll be looking into the microservices design patterns so let's get started with the first design pattern that is aggregator so when you hear the term aggregator what comes on to your mind in Computing World aggregator refers to a website or a program that collects related items of data and displays them right so even in microservices patent aggregator is basically a web page and invokes various services to get the required information
• 59:00 - 59:30 or achieve the required functionality apart from this when you basically build a microservices architecture maybe a microservices application by breaking down the monolithic application or the monolithic architecture the source of output gets divided right so when I say monolithic architecture you can just consider it to be a one big block right so when you break that one big block into small small Services the source of output also gets divided right so this pattern basically proves to be beneficial when you need an output by
• 59:30 - 60:00 combining data from multiple services so if you consider a client sending a request and maybe if we need data from two Services then aggregator is a design pattern that you should go for right now how do you think that happens so what basically happens is that you know let's say we have two Services when a client sends request and maybe that you know we want the data from both these services so what will happen is that both these services will be having their own database so with the help of aggregator design pattern what will happen is that you know each transaction will have a unique ID So based on that particular ID
• 60:00 - 60:30 the request will be sent and all the data will be collected from The Individual Services and the required business logic will be finally applied after that what will happen is that you know whatever data is collected it will be published to the rest endpoint and later on what will happen is that the data will be consumed by the respective Services which require that data right so it could be a specific consumer or maybe a user or maybe a group of users or so on right so if you have to understand aggregate Department guys it's really simple so aggregator pattern is basically a web page which invokes
• 60:30 - 61:00 various services to get required information so whenever a client requires a specific information from two or three services you can go forward with this aggregated design pattern also before I move forward to the next design pattern I would like to mention over here is that you know aggregate the pattern is basically based on the drive principle so what happens is that you know based on this principle you can abstract the logic that is the business logic into composite micro services and aggregate that particular business logic into one service right so let's say you
• 61:00 - 61:30 have a business logic right so that particular business logic what you can do is maybe you can put that particular business logic into two to three microservices later on what you can do is you can aggregate that business logic into one specific service right so for example if you consider two Services service a and service B then you can individually scale the services simultaneously by providing the data to the composite service right so that was about the aggregated design patterns guys let's move forward with the next design design pattern that is API Gateway now microservices are built in
• 61:30 - 62:00 such a way that you know each service has its own functionality but when an application is broken down into small autonomous Services there could be a few problems that a developer might face now the problems could be how can I request information from multiple microservices how can different uis require different data to respond for the same backend database service or how to transform data according to a consumer requirement from reusable microservices or how to handle multiple protocol requests right so Guys these are basically few problems
• 62:00 - 62:30 that all the developers face well if you wish to solve these problems then I would say the solution to these kind of problems could be the API Gateway design pattern so the API Gateway design patterns addresses not only the concerns that I mentioned right now but also it solves many other problems this particular pattern can be considered as a proxy service to route a request to their concerned microservice so basically as I mentioned before API Gateway is the entry point into the clients request also being a variation of the aggregator service it can send
• 62:30 - 63:00 the request to multiple services and similarly aggregate the result back to the composite service or the consumer service right so the API Gateway as I mentioned is basically at the entry point for all the microservices and can create fine-grained apis for different types of clients right so maybe you have a client sending a specific request or maybe the client B sends a different kind of request right so with the help of this particular pattern you can create fine-grained apis for all different kinds of clients and for the requests also since developers are
• 63:00 - 63:30 always concerned about you know how to handle multiple protocol requests API gateways can convert the protocol request from one type to another type similarly it can also offload the authentication responsibility of a specific microservice so once the client sends the request these requests are basically passed to the API Gateway which acts as an entry point to forward the client's request to the appropriate microservices then with the help of the load balancer the load of the request is handled and the requests are sent to the
• 63:30 - 64:00 respective Services right so microservices also use the service discovery which basically acts as a guide to find the root of communication between each of them so when I say each of them I mean two microservices so microservices can communicate with each other via stateless server that is either by HTTP request or message bus right so with the help of API Gateway pattern guys our client's request is basically forwarded to the correct microservice and even if there are different kinds of clients using different uis or maybe different
• 64:00 - 64:30 protocols and they want the data from the same backend service then API Gateway design pattern is a solution right so I hope that you've understood what is API Gateway design pattern now let's move forward with the next design pattern that is Chained or chain of responsibility so the change or chain of responsibility design pattern basically produces a single output which is a combination of the multiple chained outputs I hope that is clear to you guys right so as the name suggest just in this particular design pattern what happens is that the client request is
• 64:30 - 65:00 passed to let's say service a and then the request is passed to service B and then the request is passed the server C similarly the response is first collected from service C to service B and then from service B to service a and finally it goes to the client right so as the name suggests guys the chained or the chain of responsibility design patterns produces a single output which is a combination of the multiple chained outputs so for example if you have three services lined up in a chain then the request from client is first received by
• 65:00 - 65:30 service a and then this service communicates with the next service service B and collects the required data finally the second service communicates with the third service to generate the considered output and what happens is that all these Services response is sent again from server C to service B service B to service a and finally to the client right so all these services use synchronous HTTP request or response for messaging also until the request passes through all the services and respective responses are generated the client does not get any output right so guys this is
• 65:30 - 66:00 kind of a disadvantage in this particular design pattern because you know let's say you know you have 20 Services lined up and maybe the client request is a very big request right so until all the data is collected from all these particular services and then the response back is generated the client does not see any output right so it's always recommended not to make any long chain as the client has to wait until the chain is completed right but before I move forward to the design pattern one more important aspect of which you need
• 66:00 - 66:30 to understand is basically that you know the request from service a to service B may look completely different from how the request is from service B to server C similarly is the case for response maybe the response from service C to service B may be completely different from service B to service a right so that's what you have to understand about the chain of responsibility or change design pattern guys now let's move forward with the next design pattern that is asynchronous messaging design pattern so what do you understand by this term asynchronous messaging obviously the messaging pattern between
• 66:30 - 67:00 microservices is not synchronous right so in the previous design pattern we had discussed synchronous messaging right so that was because you know service a communicates with service B and b2c right but in asynchronous messaging pattern it's not necessary that you know all the services communicate like you know Service A to B or B to C maybe service a can directly communicate so with c and maybe service C can communicate with service b or maybe service B does not communicate at all right and server speak communicates with service a right so basically what you
• 67:00 - 67:30 have to understand is that you know since the client Waits a long time without any output and synchronous messaging and maybe you do not want the client to wait for a long time this is where basically you use the asynchronous messaging design pattern right so in this particular pattern what happens is that all the services communicate with each other but maybe they do not have to communicate with each other sequentially so if you consider free services as I just mentioned before Service A B and C the request from client can be directly
• 67:30 - 68:00 sent to server C and service B simultaneously when I say simultaneously what happens is that you know the single request from client is sent to both the services together that a service C and service B so then what will happen is that you know these requests will be in a queue so when I say queue you can understand that it is basically a line of request so when a client requests a simultaneously sent to two Services you basically build a queue and apart from that what you also have to understand is that you know let's say the service a sensor request to server C it's not necessary that you know server C sends
• 68:00 - 68:30 back a response to service a itself maybe it can follow a different path and then finally a response can be sent right so the path is not defined and it is not done sequentially in asynchronous messaging pattern right so guys that was about asynchronous messaging design pattern next let's move forward with the next design pattern that is database design pattern or shared data design pattern now for every application there's obviously a humongous amount of data present right so when we break down an application from its monolithic
• 68:30 - 69:00 architecture to microservices it's very important to know that you know each microservice has a sufficient amount of data to process a request right so I hope that point is clear to you when we break down the monolithic application into small spawn Services we need to make sure that you know each micro service has sufficient amount of data to process the client's request so either the system can have the database for each service or it can have shared database per service right so when I say database per service what I mean that is you know each microservice in the system
• 69:00 - 69:30 will have a specific database for themselves and share database for service is basically when two or three microservices together share a specific database right now you can use the database per service or share database per service to solve various problems so the problems could be basically the duplication of data and inconsistency different Services have different kinds of storage requirements so the problems could be basically the duplication of data and inconsistency different Services have different kinds of storage requirements few business transactions
• 69:30 - 70:00 can query the data with multiple services and the normalization of data is not easy right so to solve these kind of problems basically you can use the database per service or the share database for service right so if you have to solve let's say you know duplication of data and inconsistency and maybe different Services have different kinds of storage requirements or maybe a few business transactions can query the data with multiple Services I think you should go for database per Service as it will then be accessed by microservices API itself right so each
• 70:00 - 70:30 microservice will have its own database ID which thereafter prevents the other services in the system to use that particular database right so only that particular microservice can access a specific database present for that particular microservice itself right so apart from this to solve the issue of denormalization you can go forward with the shared databases for service to align more than one database for each microservice so what will happen is that this will help you get the data for the monolithic applications which are broken down into microservices but you have to
• 70:30 - 71:00 keep in mind that you know you have to limit this databases to two or three microservices else scaling these services will be a big problem right so guys that was about the database design patterns let's move forward with the next design pattern that is the event sourcing design pattern so the event sourcing design pattern basically creates events regarding the changes in the application state so these events are stored as a sequence of events to help the developers track which change was made when and by whom right so with
• 71:00 - 71:30 the help of this you can always adjust the application state to cope up with the past changes and also you can query these events for any data change and simultaneously publish this events from the event store right so once the events are published you can see the changes of the application State on the presentation layer right so that was about event sourcing design pattern guys event sourcing design pattern is basically used to create events regarding the changes in the application state right you've done a specific change and maybe you want to go back to the previous change that you have done
• 71:30 - 72:00 you can always use this particular kind of pattern to go back and see what changes was made and when and by whom right so that was about even sourcing design pattern guys let's move forward with the next design pattern that is Branch pattern so what do you understand by Branch pattern obviously as the name suggests it's all about branches right so for a specific service you can have different branches right so the branch micro service design pattern is basically a design pattern in which you can simultaneously process the request and response from two or more
• 72:00 - 72:30 independent microservices so unlike the chain design pattern that I discussed before the request is not passed in a sequence but the request is passed to two or more mutually exclusive micro Services change right so this design pattern basically extends the aggregated design pattern and provides the flexibility to produce responses from multiple chains or a single chain right so for example if you consider an e-commerce application then you may need to retrieve the data from multiple sources and this data could be a collaborated output from various
• 72:30 - 73:00 Services right so you can use the branch pattern to retrieve the data from multiple sources right so the branch pattern is really simple to understand guys it's basically where you want to simultaneously process the request and the response from multiple micro Services right so these could be either in a single chain or maybe it could be in multiple chains also but yes it's not necessary that you know the request or the response is done in a sequential manner so guys that was about the branch pattern now let's move forward with the next pattern that is command query
• 73:00 - 73:30 responsibility segregator design pattern so command query responsibility segregated design pattern or more commonly known as cqrs is basically used when you want to query for a specific data right now what happens is that you know when you have microservices design in the form of database per service or shared database per service what happens is that you know you have limited access to database right so basically you cannot Implement a query as the data is limited to only a single database so in such scenario we basically use the cqrs
• 73:30 - 74:00 pattern so according to this pattern what happens is that the application will be divided into two parts that is command and query so the command part will basically handle all the requests related to create update and delete while the query part will take care of the materialized views right so the materialized views are updated through a sequence of events which are created using the Event Source pattern that I just discussed before so in the cqrs pattern guys you basically divide the application into two parts that is the
• 74:00 - 74:30 command and the query the command will take care of the request related to create update and delete and the query part will basically take care of the materialized views right so with the help of this pattern you can make sure that you know you have good access to your databases and then the client's request is satisfied also you can make sure that you know your materialized views are updated through a sequence of events which are again created using the event sourcing design pattern so guys that was about the cqrs pattern now let's move forward with the next pattern that is circuit break pattern so the
• 74:30 - 75:00 circuit break pattern as the name suggests is basically used to stop the process of request and response if a service is not working so for example let's say a client is sending requests to retrieve data from multiple services but due to some issues one of the services down now there are mainly two problems which we'll see first the client will not have any knowledge about the service being down right so he or she will be continuously sending the request to that particular service the second problem that we see is basically the network resources will be exhausted
• 75:00 - 75:30 with low performance and bad user experience as the client without knowing will be waiting for the response to come back right so to avoid such problems what you can do is you can go forward and use the circuit breakup design pattern so with the help of this design pattern the client will invoke a remote service via proxy the proxy will basically behave as a circuit barrier so whenever the number of failures cross the threshold number the circuit breaker trips for a particular time period and then all the attempts to invoke the remote servers will fall in this timeout
• 75:30 - 76:00 period right so once that timeout period is finished the circuit breaker will allow a limited number of tests to pass through and only if those requests are succeeded the circuit breaker resumes back to the normal operation right so just in case if the tests don't go through then there'll be a failure and the timeout period will begin again right so in this particular pattern what you have to understand is that is basically that you know when the number of failures cross a threshold number the circuit breaker will trip for a particular time period and then all the attempts to invoke that particular
• 76:00 - 76:30 service will fall in that particular period right once that time period is done what will happen is that you know the circuit breaker will allow a limited number of tests to pass through and only if the test succeed it will resume back to normal operation else it will show failure again and again the timeout period will begin again so with the help of circuit breaker pattern guys you can make sure that you know there is no exhaustion of the network resources with low performance and always this user experience is kept under good node right so that was about the circuit breaker design pattern guys now let's move
• 76:30 - 77:00 forward with the last design pattern for today's session that is decomposition design pattern so microservices are basically developed with an idea on the developer's mind to create small services with each having their own functionality but breaking an application into small autonomous units has to be done logically right so to decompose a small or a big application into small Services you can go forward and use the decomposition patterns so with the help of these patterns either you can decompose an application based on the business capability or based on
• 77:00 - 77:30 sub-domains so for example if you consider an e-commerce application then you can have separate services for all those products and customers if you decompose by business capabilities but in the same scenario if you design the application by decomposing by subdomains then you can have services for each and every class so here in the example that I had considered before that is the e-commerce application if you consider a customer as a class then this class will be used in customer management customer support customer query and so on right so to decompose you can use the domain
• 77:30 - 78:00 driven design through which the whole domain model is broken down into subdomains then each of these subdomains will have their own specific model or a scope that is basically the bounded context so now when a developer designs microservices he or she will Design those services around that particular scope or bounded context right either you can decompose microservices by business capabilities or by domains right now obviously these patterns might be sounding very feasible to you but yes
• 78:00 - 78:30 these patterns are not feasible for a big monolithic application this is because of the fact that you know identifying subdomains or business capabilities is not an easy task for big applications right so the only way to decompose big monolithic applications is by following the wine pattern or the Strangler pattern so the wine pattern or the Strangler pattern is basically based on the analogy to a wine which basically strangles a tree that it is wrapped around right so when this pattern is applied onto web application a call goes
• 78:30 - 79:00 back and forth to each URI call and a service is broken down into different domains these domains are then hosted by separate Services right so according to the standard pattern two separate applications will live side by side in the same URI space and one domain will be taken into account at an instance of time So eventually what happens is that you know the new refracted application basically wraps around or you can say strangles or replaces the original application until you can shut down the monolithic application
• 79:00 - 79:30 [Music] the basic system requirements that I may suggest for you is that you have a minimum memory of 512 MB to 1 GB a Java version of 1.8.0 a processor speed of minimum 800 megahertz to 1.5 gigahertz and a free disk space of minimum 300 MP now as we have seen the Java is a basic system requirement before I move forward to tell you how to download and install Java let me preview a little bit about
• 79:30 - 80:00 Java well Java is a programming language and a Computing platform released by the sun Microsystems in the year of 1995. so just in case if you want to run any Java applications then Java runtime environment is fine but if you also want to develop Java applications then you must install Java development kit now let us get into how to download and install Java to download and install Java open your favorite browser and type Java jdk
• 80:00 - 80:30 the first website that you see is from the Oracle website underneath the link you see that there are various options provided by the Oracle website to download different versions of java such as Java SC development kit a Java IC development kit 9 jdk 7 Etc in this video I would be downloading Java IC development kit 8. so click on it once the website opens you see that the Oracle website offers different versions of java to download for various operating systems such as Linux Solaris
• 80:30 - 81:00 Mac OS and windows in this video I would be downloading for windows with 64-bit so before you click on the executable file what you have to do is accept the license agreement by clicking on this radio button and then click on this downloadable executable file so click on it you see that Java starts downloading so until Java is being downloaded let me show you how to check your system properties so go to start right click on this PC go to more and properties you'll
• 81:00 - 81:30 see a control panel window opening up showing the basic information about your computer such as processor install memory system type Etc in my case I have a windows with 64-bit operating system and with an 8GB Ram so let me minimize this okay now the executable file has been downloaded so let's go to downloads and you see that Java has been downloaded double click on this now we can see that there's a wizard which opens up which says welcome to the
• 81:30 - 82:00 installation of java SC development kit8 click next make sure that you choose the development tools and again click next here Java starts installing now choose the destination folder in my case I have chosen C program files Java and click next after Java has been installed you see your wizard which opens up and says Java development kit 8 has been successfully installed click on close
• 82:00 - 82:30 once Java has been installed on your PC you have to set the environment variables in Java for that go to start right click on this PC go to more and properties a control panel window opens up showing all the basic information now click on Advanced system settings go to environment variables and over here add a new variable by clicking on the option new and type the name as Java underscore home in the variable value
• 82:30 - 83:00 add the directory of your Java jdk folder so let's go to this PC see program files Java jdk right click here copy the address and paste it over here click on OK after this is done you also have to edit the path variable so go to path click on edit and over here append the Java bin folder so go to pin right click here copy the address click on
• 83:00 - 83:30 here and paste once it is pasted click on OK and even in this window click on OK finally to check whether Java has been installed or not go to command prompt and type Java space hyphen version you can see that the Java version 1.8 has been installed so that is how you can download and install Java now let's move further and see two different approaches to run the spring boot projects the
• 83:30 - 84:00 first approach I'm going to explore for you guys is by using a spring starter plugin in eclipse and the other approach I'm going to explore for you guys is by using a spring boot CLI with the passion Maven so let me start with the first approach before we get into how to download and install eclipse and use the spring starter plug it in red let me just brief you a little bit about eclipse and the tool we are going to use well eclipse is an integrated development environment containing a base workspace and an extensible plug-in system for customizing the environment so basically you can deal with various
• 84:00 - 84:30 kinds of projects like web-based projects Android applications software projects and others coming to a spring startup plugin that is the spring tool suit is an eclipse based development environment that is customized for developing spring applications so it is basically a ready to use environment to implement debug run and deploy spring applications now let us start by downloading and installing eclipse to download and install Eclipse go to your favorite browser and type Eclipse IDE for Java doubly Developers
• 84:30 - 85:00 open the first link that shows up that is from the official website of eclipse as the page opens up on the left side you can see that there's a list of various Eclipse releases and on the right side there is a list of various download links in this video I am going to download for Eclipse oxygen package since it's the latest one so click on oxygen packages now in the next link that opens up click on Eclipse ID for Java double e Developers
• 85:00 - 85:30 now on the right side from the download links list choose according to your Operating System since I have a windows with 64-bit I'll click on windows with 64-bit in the next page that you redirected to click on this download button well you can now see that Eclipse J oxygen has started downloading okay now you can see that Eclipse oxygen has been downloaded let's go to downloads again and you can see that the eclipse has been downloaded here so let's extract
• 85:30 - 86:00 these files to a specific folder let's say C click on OK now you can see that Eclipse folder is getting extracted to the C drive let's minimize this and go to C drive you see that there's a folder named Eclipse open this and here inside the folder you can see an application file of the named Eclipse so double click on it this launches the eclipse application
• 86:00 - 86:30 choose the directory for your Eclipse workspace like I have chosen CU society and then click on launch well now your Eclipse application has started to download the spring startup plugin go to help go to Eclipse Marketplace and type spring tool suit over here click on install a dialog box opens up with various
• 86:30 - 87:00 options make sure you have selected all the options and click on confirm click on this radio button to accept the license agreements and then click on finish you can see at the bottom that the software starts installing if you get this warning click on install anyway this will continue our installation now after the software has been installed a dialog box opens up which
• 87:00 - 87:30 says restart Eclipse so click on restart now so finally you can see that your Eclipse has restarted Now to create a spring boot project click on file go to new and choose spring startup project now a window opens up in this window you have to choose the full name for your project such as name group ID artifact ID Etc so let's suppose I choose the name as hello underscore word and the group ID as com.edurika
• 87:30 - 88:00 and make sure the package here is a combination of the group ID and the name so package name would be com Dot edureka dot hello underscore World make sure you have chosen Maven as a type and click on finish in this window you have to choose the dependencies for your project so let's suppose I choose web and then click on finish on the left side in the project Explorer you can see that the spring tool suit
• 88:00 - 88:30 has created a springboard project for us now let us explore the project structure of this project well this project has an auto created Java 5 which acts as an entry point for the application this project also has a form.xml file which houses all the dependencies required for this project now this application is ready as a standalone application and we can definitely launch it but I would be adding a configuration Java file to it so that it can handle HTTP requests so
• 88:30 - 89:00 to add the file go to the package right click on this package go to new and choose class in this window choose the name of your Java file let's say application configuration file click on finish now here to handle the HTTP request we need to import two annotations that are the rest controller and request mapping so to import these let's type import space org dot spring
• 89:00 - 89:30 framework dot web dot bind dot annotation dot request mapping and put a semicolon at the end of it similarly also in both the rest controller so for that type import space org dot spring framework dot web dot
• 89:30 - 90:00 find dot annotation dot rest controller after importing both the annotations create a method inside the configuration class which can be called when an HTTP request is made so type address request mapping and it's brackets and double quotes let's suppose I want to pass the request slash hello now create a method with a string
• 90:00 - 90:30 now let's suppose when we pass the request slash low we want to return hello world type hello world and close the brackets and save this file now to run this project right click on this project go to run and choose a springboard app at the bottom of the control you can see that Tomcat has started on port number 8080 and the hello world application has started to check whether the application is working or not go to the browser and
• 90:30 - 91:00 type localhost colon 8080 hello you can see that the output comes as hello world this means that our application is working now let me show you the second approach that is by using Springport CLI and Apache Maywood but before that let me brief you a little bit about Maven and spring boot Maven is a powerful project management tool that is based on Project object mode it is basically used for projects built dependencies and documentations coming to Springwood CLI springboot makes it easy to create spring powered production grade
• 91:00 - 91:30 applications and services now let me show you how to download and install Maven first to download Maven go to your browser and type cache may win download click on the first link that opens up now scroll down and go to the file section here choose the zip file that you want to download let's say Apache Maven 3.5.3 bin zip on the left side you can see that Maven has started downloading okay now let's go to
• 91:30 - 92:00 downloads you can see now that Maven has been downloaded let's extract these files to a specific folder let's say c and click ok let's go to C drive now and now you can see that the maven files have been extracted to the C folder similar to Java you also have to set the environment variables for mayway so for that go to start right click on this PC go to more and properties a control panel window opens up go to Advanced system settings
• 92:00 - 92:30 click on environment variables and here add a new variable with the name M2 underscore home in the available value add the path of your Maven folder so code is a folder right click here copy the address and paste it here click on OK once it is done also add one new variable with the name Maven underscore whole pointing to the same path so click on new and type Maven underscore home and paste the same directory here click
• 92:30 - 93:00 on OK once it is done you also have to edit the path variable so go to path click on edit and now over here add the directory of the maven bin folder so open bin copy the address click on new and paste it here then click on OK and again click on OK once this is done to check whether Maven has been installed or not go to command prompt and type mbn space hyphen hyphen version
• 93:00 - 93:30 you can see that Apache Maven 3.5.3 has been successfully installed now to install the springboot CLI what you have to do is go to the browser and type spring Booth CLI download open the first link that you can see in the browser scroll down and under the manual installation download the zip folder so click on that and you can see that spring would see
• 93:30 - 94:00 Eliza folder is getting downloaded once it's downloaded go to downloads and extract these files to a specific folder let's say see and click on OK once the file has been extracted to C drive you can see a folder named spring 2.0 release similar to maywind you also have to set the environment variables for spring so for that go to start right click on this PC go to more and properties in the control panel window
• 94:00 - 94:30 go to Advanced system settings click on environment variables and now over here add a new variable with the name spring underscore home so type spring underscore o and in the variable value add the directory of the spring folder so right click here and copy the address and paste it here click on OK once this is done you also have to update the path variable and append the spring bin folder so go to path click on edit and
• 94:30 - 95:00 go back to the folder choose bin right click here copy the address click on new and paste it here and again click on OK then click on OK once this is done to check whether spring has been installed or not go to command prompt and type spring space hyphen hyphen version you can see the spring CLI version 2.0 release has been installed now to run your springboard projects
• 95:00 - 95:30 what you have to do is you have to change the working directory of your command prompt to the project directory so let's suppose I have a project on the desktop I'll open it I'll right click here I'll copy the address I'll go back to command prompt I'll type the command CD space and paste the address here now click on enter this changes the working directory of your project now to run the springboot project you have to type the command mbn space spring
• 95:30 - 96:00 hyphen boot colon run and click on enter this starts building a springboard project once this is done at the end of the console you can see that the Tomcat has started on port number 8080 and the application hello world has started now to check whether our application is working or not let's go back to browser and type localhost colon 8080 slash hello
• 96:00 - 96:30 this prints hello world that means the application is working fine [Music] so the first challenge that we are going to discuss is called perceptibility now as we know that in a microservice there are small components to deploy and maintain and there are many of them so there are many small components that we need to deploy and maintain and at times it becomes very difficult guys to Monitor and identify problems right if I take the classic example of an e-commerce website so over there we have multiple small small Services running
• 96:30 - 97:00 for example the card service it can be the product service or the customer service so there are multiple Services running and we need to deploy and maintain those services so at times it becomes very difficult to Monitor and identify problems so what we require we require great perceptibility around all of these components the next challenge is configuration management now there is a great need to maintain the configurations for the components across the various environments because we have small small components right the idea and microservices to break down and break down an application into small composable pieces that can talk to each
• 97:00 - 97:30 other so we need to configure these components across various environments that is also a one very big challenge guys now the next challenge is debugging now it becomes very difficult to probe each and every service for an error right so you have multiple Services running now to debug error in each of those Services is very difficult so what we need we need centralized logging and dashboards to make it easy to debug the problems right then the next challenge that we are going to discuss is basically consistency now think about it guys you cannot have a wide range of
• 97:30 - 98:00 tools solving the same problem right and we know that it is important to Foster Innovation but we also know that it is also important to have some decentralized governance around the languages platforms technology and tools which are used for implementing or deploying or even monitoring the microservices right so I hope you're getting my point so maintaining consistency is also a very big problem now the next point is automating the components it becomes very difficult guys to automate everything because there are a number of smaller components instead of a monolith that is build
• 98:00 - 98:30 deployment and monitoring so now to automate this entire Cycles it's very difficult so these are the challenges with the microservice architecture now let us see the solution so solution is spring boot now spring boot enables building production ready applications quickly and provides many non-functional features let me discuss few of them so the first feature that I'm going to talk about is embedded servers so these servers are easy to deploy with the containers then the next point is it helps in monitoring multiple components so you have various various comprehensive various Services running
• 98:30 - 99:00 so in order to monitor those Services we can do that with the help of spring boot then and finally it facilitates in configuring the components externally so we saw whatever the challenges were right the consistency perceptibility configuration management Automation and all the challenges that we have just discussed were completely removed with the help of spring boot so let's move forward and now we're going to focus on how to build a top sports brand so this is our use case guys we'll be building a top sports brand let us see how we are going to do that so in this spring boot microservice example we'll be creating
• 99:00 - 99:30 top sports brand application which will have three services so you can see it in the diagram as well so we have three services here one is Eureka server then we have item catalog service and then we have ad service so these are the three services that we'll be running now let me discuss each of these one by one so the first thing is Eureka service now this service will register every micro service and then the client microservice will look up to the Eureka server to get a dependent microservice to get the job done so what I mean by that is a user will approach this Eureka service which
• 99:30 - 100:00 will have the other two Services registered with it so this is basically called a registry service in this registry service we have the other two Services already registered so based on what the user want Eureka server will get a dependent microservice to get the job done so I hope you have understood that now let's move forward and we are going to focus on what are item catalog service so item catalog service will generate the list of sports brands which are popular in the market so whatever the list of sports bands that are popular it will generate that and then the edge service is also pretty much
• 100:00 - 100:30 similar to the Standalone item catalog service however it will have fallback capabilities which prevent the client from receiving an HTTP error when a service is not available right I hope you have understood this architecture let me just repeat it once more so we have a Eureka service which is owned by Netflix and this is basically a registry service and we have the other microservices registered in this service the item catalog service will have the sports brands then the edge service will basically give us the top sports brand will filter only the top sports brand this is how the architecture of our spring boot
• 100:30 - 101:00 application is so we have given the numbers as well in the diagram so the first thing is it will register the other two applications in Eureka service so first we'll register the item catalog then we will register the ad service then we'll produce the sports brand names this item catalog service and the ad service will filter only the top sports brands so this is what is going to happen in today's use case now let us see what are the tools I'm going to use so I'm going to use Java 8 Eclipse ID oxygen and the spring tools so let me just quickly open my Eclipse ID and I'll
• 101:00 - 101:30 explain you the code there so this is my Eclipse ID guys and over here I've already written the code in order to execute the use case I'll just give you a walkthrough of what I've done here so I have all the three services that I've mentioned in the slide so we have Eureka service we have Edge service and we have item catalog so start with Eureka service first I've already written it so I'll just quickly show you how you can do that click on new over here go to other and over here select spring startup project click on next and just a couple of minutes and then just give the name to your service and then go ahead click on next and the
• 101:30 - 102:00 dependency so we want the Eureka server as a dependency and just finally click on finish so that's all you have to do and you'll find Eureka server already created and over here the first thing that I wanted to show you is application properties so over here I've mentioned the port I've modified it a bit so what modification I've done I've modified the file to add a port number and I've disabled the registration the port number is 8761 and this and I've disabled the registration right next what I'll open I'll just open Eureka service application.java
• 102:00 - 102:30 right so for that so this is the file that I was talking about and over here I've added a couple of notation first is enable Eureka server above the spring boot application so this Eureka server that you're seeing I have added that above the spring boot application right so this annotation will configure a registry that will allow other applications to communicate since I want the other applications to obviously communicate with it so it will basically configure a registry and it will allow the other applications to communicate so that's all for Eureka
• 102:30 - 103:00 service let me just go ahead and quickly run it to show you how uh it looks like in the browser so I'll just click on run as a spring boot application and you can see that it has started running already and I'll just quickly open my browser and at Port 8761 so you can see that Eureka service is running at Port 8761 but currently you can see there are no instances which are registered with Eureka right so we need the other two services to be registered here so this is it for Eureka server now let me talk about item catalog so for item catalog what we need to do is again click on new
• 103:00 - 103:30 go to other spring starter project like we have done it in Eureka Service as well give a name whatever name you want to give then in the dependencies there are a lot of dependencies that we need to import so let me just talk about that the first thing we need to import is an actuator right so we need to click on this and we need to import this so what is an actuator it is a feature that will help us to Monitor and manage our application after actuator I need to import Eureka discovery
• 103:30 - 104:00 yeah so I need to import this Eureka Discovery for Service registration since I want my service to be registered in the Eureka server so for this I need to import this particular dependency then I'm going to import jpa which is basically to save or retrieve data after that I'll import H2 which is an in-memory database all right then I'm going to import the rest repositories all right so these rest repositories are basically to expose jpa repositories as rest endpoints then I'm going to import
• 104:00 - 104:30 web all right so here we can see that we have web here so web will basically is nothing but spring MVC and embedded Tomcat then I'll import Dev tools devtools all right so this is to Auto reload the application when there's any change in the file now I'm going to import lombok in order to you know just to reduce the boilerplate code so since I've already done that I won't create another uh project here another service here basically so let me just give you a walkthrough of the code that I've written here so first let me show you uh
• 104:30 - 105:00 the item catalog application.java file so this is how it looks like first of all the couple of annotations so enable Discovery client is basically to register my application in the Eureka server then we have a one more annotation spring boot application right and so after that what I have written so this is my main class all right the main class will be executed first in my application and uh this is responsible for item catalog execution the item catalog application execution all right then I have few annotations at the rate
• 105:00 - 105:30 data all argument Constructor so in order to explain you that let me just tell you what at the rate data is a convenient shortcut annotation that bundles the features of two string you know equals in hash code getter Setter required argument Constructor together all right so people who are familiar with Java know all these annotations then the second annotation I'm using is all argument Constructor generator so basically it will generate a Constructor with one parameter for each field in your class all right so Fields marked with at the rate not null result in a
• 105:30 - 106:00 null checks on these parameters then we have no argument Constructor will generate a Constructor with no parameters yeah after that we have either a two strings so it'll also pretty easy so either a two string is basically you know it gives you the facility so that you don't have to start a debugger to see your Fields you can just let lombok generate a two string for you and then the entirety is basically is a lightweight persistence domain object typically an entity represents a table in a relational database and each entity instance corresponds to a row in that table so
• 106:00 - 106:30 the primary programming artifact of an entity is the entirety class although entities can use helper classes as well so this is about the annotations so the next thing that I'm telling you about is a parameterized Constructor of the item class so let me just write that here as well so it is a parameterized Constructor of the item class and here we are defining the class members the long ID and the string name so next we have a repository rest resource so basically we have an interface item repository that we are extending with jpr repository
• 106:30 - 107:00 over here what we are doing we are defining an implementation of the command line Runner interface that will need to override the run method and this method will be executed after the application context is loaded and right before the spring application run method is completed so if this will basically generate the key value pair using the for each Loop and we are basically overriding the run method to print our key value pair so that's what we are doing here so I believe you have understood this code or people who are familiar with Java for them it's not a tough task right so it's
• 107:00 - 107:30 a pretty basic code so let me just so we are creating an item entity a jpa repository for it and we are also creating a command line Runner to populate database with the default data all right so that's what we have done here now let me go to the application.properties and I wanted to show you a couple of things there so yeah in this application.properties what we have done we have added an application name in the file to display the Eureka service and set the port to a088 now also in the cloud properties file so let me just show you the cloud
• 107:30 - 108:00 properties file as well so you need to add all of these things in your Cloud properties file as well so this is the Eureka instance hostname then we have the non-secure port mentioned here the metadata map the instance ID over here we have it then eureka.instance lease renewal interval in seconds is 5 then Eureka client region it's a default region registry fetch interval seconds is we have given it as five so all of these things will be available with you if you can mention your email ID in the comment section you can find the entire code there so mention your email ID in
• 108:00 - 108:30 the comment section and we'll reply you with the entire code used in the video since I've configured out Port 8082 let me just go ahead and quickly run this first I'll clean it using Maven so I'll just click on mavenclean and now I'm going to build it using Maven again so just click on run as go to Maven build over here type spring hyphen boot colon run and just hit enter
• 108:30 - 109:00 so let me just go to the Eureka server let me just refresh this link once right so you can see that item catalog service is already registered my Eureka server now let me just go to the port 8082 slash items so it is displaying basically all the items present in my item catalog service right so let's just go through it it's pretty easy guys uh so we have the name of the sports brand right then we have again a bad boys and we have Air Jordan
• 109:00 - 109:30 Mike Adidas all the sports brands that we were talking about and uh the size of the page total elements and everything you can have a look and just play around with it so I'll just go back to my Eclipse idea once more so now we're going to create an edge service now ad service I've told you it is pretty similar to the Standalone item service that we have created however it will have fallback capabilities which will prevent the client from receiving an HTTP error when the service is not available and how we are going to do that similar fashion like we have created item catalog all you have to do
• 109:30 - 110:00 is click on file go to new and go to other select the spring startup project here click on next give a name to your service whatever name you feel like then go to next then over here we need to add dependencies so let me just tell you about that the first dependency we need is Eureka Discovery so just type here Eureka Discovery select that right so this is basically for Service registration like we have done in the item catalog Service as well so this will be registered in my Eureka server then we are going to add a
• 110:00 - 110:30 feed dependency let me just type that first so yeah so this feed dependency is basically a declarative web service client all right and now once it is done we are going to add Zool so basically zul is provides an intelligent routing system so just click on tool as well once that is done I'm going to import rest repositories so these rest repositories as I've told you earlier as well is Will expose the JPI repositories as rest endpoints uh then I'm going to again add a web as well so I've done that in the
• 110:30 - 111:00 item catalog as well so just click on web it is basically a spring MVC with spring MVC architecture and embedded Tomcat right so like we have MBC and MBT architecture then I'm going to type in here hysterics so this histrix uh just let me just check it once yeah so it is a circuit breaker to stop cascading failure and enables resilience right so that's what it is used for then let's go ahead and add one more dependency that is lombok
• 111:00 - 111:30 lombok is basically to reduce the boilerplate code that I've done in the previous project as well so I'll just click on cancel because I have already done that you can just go ahead and click on finish and you will find the edge service present here something like this right so now let me just take you through the edge Service as well we know that the item catalog service is running on Port 8082 so what we need to do we need to configure this application to run on a different port now this is pretty obvious guys right so let me just open this application.properties and you can see that I've configured it at Port
• 111:30 - 112:00 8089 right and I've given the application name for similar reason basically to add my service in the Eureka server right now I need to create the cloud properties file that I've already done right you can see it over here the cloud properties file it is already present and I need to add some code here that I've done it in the uh item catalog Service as well so this code you can again find it once you you know mention your email ID in the comment section will reply you ASAP the code all right all right we just open Edge service application.java file so
• 112:00 - 112:30 that I can find it here right now in order to you know enable fee in historics and registration with the Eureka server add the appropriate annotation so what are the proper annotations we have enabled field clients we have enabled circuit breaker we have Discovery client the Zool proxy and springboard application obviously right so uh these are the annotations that we are going to use and after that let me explain you the code although it's pretty simple guys people who know Java will find it really easy to understand
• 112:30 - 113:00 so this is again the main class which Java will be basically execute the first in my application right then I have a couple of Getters and setup methods defined here I have an API adapter that will return the array list of our items and the finally you can see the public collection item good item that you can see it in the end yeah this is basically for collecting items and adding it into a list finally this private Boolean is great
• 113:00 - 113:30 item this will return true and false if the item is not available for a particular brand all right so this is pretty easy guys now over here I've created a dto now let me just take you through the code once more so if you notice here I've already created a dto an item dto which means data transfer object in this same file and at the long box at the rate data will generate two string Methods the Getters and Setters the appropriate Constructors all right then I've created a item client interface so if you scroll
• 113:30 - 114:00 down you can see that we have an item client interface so we can see that we have an item client interface that uses fiend to communicate to the item catalog service so we have talked about item catalog service so this item client interface will use theme to communicate with the item catalog service right then we have a rest controller below the item client so over here we have the rest controller that will filter out less than top brands and shows the top brands endpoint so slash uh top brand endpoint so it will filter out the brands right
• 114:00 - 114:30 it will it will add a filter to all the brands that we have in order to get the top brands right so that's what the rest controller will do now what I'm going to do I'm going to start this service for you so I've configured this service at Port 8089 so let me just quickly go ahead and run this for you I am going to first click on run as Maven clean so I'm going to quickly run this as a spring boot app and let us see what happens all right so let me just quickly open
• 114:30 - 115:00 the Eureka server right and I'll just refresh this and you'll see that there are two instances currently registered with Eureka right so you can see that there are two instances currently registered with Eureka now let me just quickly go to a particular report that is 8089 so I'll just type in here localhost 8089 slash top hyphen brands and here we go so we have got the top brand so we have lining Puma bad boys and Air Jordan right now what I'll do
• 115:00 - 115:30 I'll just quickly shut down the item catalog service application uh for that let me go back and I'm going to shut down the item catalog application so this is what we have done in this particular use case now if we shut down the item catalog service application you'll get a 500 internal server error foreign so what exactly is rest well rest is the abbreviation for representational state transfer restful web services are built
• 115:30 - 116:00 to work best on the web so did you get an idea what rest is let me Define it for you rest is an architectural style that specifies constraints such as uniform interface that if applied to a web service induced desirable properties such as performance scalability and modifiability so this means that rest is a set of constraints that you need to Avail and once a service awaits to this constraints it is called a restful service coming to the rest architectural style
• 116:00 - 116:30 data and functionality are considered resources and are accessed using uniform resource identifiers the resources are then acted upon by a simple set of well-defined operations the rest architectural style constraints and architecture to a client server architecture and is designed to use a stateless communication protocol typically HTTP in the rest architecture style clients and servers exchange representations of resources by using a standardized interface and protocols so
• 116:30 - 117:00 at the end you can understand that the rest apis communicate between the clients and the databases so what exactly are these risk constraints well the first one is the client server this means that you should have a client and a server that is there should be a service provider and a service consumer the next one is that you should have a uniformed interface so you should know the functionalities of the application you should know the resources required and then you have to decide on how to
• 117:00 - 117:30 expose them out the other things are the services should be stateless and also they should be cachable that means that the values returned should be stored in Cache and the last constraint that I would like to mention is that it should be a layered architecture so basically client should not assume to get a direct connection to the server so now that you know the rest constraints let's Deep dive into what are the principles that encourage restful applications to be simple lightweight and fast restful web service exposes a set of
• 117:30 - 118:00 resources that identifies the targets of interaction with its clients resources are identified by Uris which provide a global addressing space for resource and service discovery the second thing is that resources are manipulated using a fixed set of create read update and delete operations so the put creates a new resource which can be then deleted by using the delete get retrieves the current state of resource in some representation and post transfers a new stage onto a resource
• 118:00 - 118:30 resources are takeable from the representation so that their content can be accessed in variety of formats such as HTML XML plain text PDF jpeg Json and others so metadata about the resource is available and used for example to control caching detect transmission errors negotiate the appropriate representation format and perform authentication or Access Control the final principle that I would like to tell you is that every interaction with the resource is stateless that is
• 118:30 - 119:00 request messages are self-contained so stateful interactions are based upon the concept of explicit State transfer several techniques exit to exchange states such as Ura rewriting cookies and hidden form Fields State can be embedded in response messages to point to valid future states of interaction so now that you know what has rest and its principles how do we set up Place full services for springboard application well there are three steps
• 119:00 - 119:30 that we will follow first we will set up a simple spring boot project using embedded Tomcat that is in the eclipse ID then we will add a get service to it after adding a guest service we will learn how to handle the post service so let's get started with it now let's look into the project we will use the concepts of customers ordering various products so we will start by creating a get service to return what are the products a customer has ordered then we will also create another get service to
• 119:30 - 120:00 retrieve the orders that is the details of the specific order for a customer so basically what I'm trying to do here is that I'm trying to get the details of a customer going for a particular product so is that clear to everybody okay I've got a yes after that I will also create a post service to register a customer for a product so let's get started now so let me just open my Eclipse ID so before getting into the project structure let me show you how to create
• 120:00 - 120:30 a simple Maven project for that you just have to go to file you have to go to new and choose Maven project in the window that opens up you have to choose create a simple project and click next after that you have to fill the following such as the group ID artifact ID name description for your project and then click on finish this will create your Maven project so now that all of you know how to create your own projects coming back to the project that I've already created let me take you to the project structure
• 120:30 - 121:00 of this project so let me just open all the files okay now let's start with the customercontroller.java file well this is the file which exposes the service methods such as get post put okay so Sonia just asked me a question if I can just tell you guys what do these methods get postpod do well get does not update anything it just gives the same results in multiple calls coming to post post creates a new resource ideally it returns a Json file
• 121:00 - 121:30 with a link to newly created resource I'll explain you in detail in the video now to update a known resource you have to use the put service so Sonia is that clear to you okay that's great now continuing with the project structure the product.java the customer.java and the customer service.java is the main business Logic for the application we're trying to implement so I would show you how does the customer service exposes a couple of methods that are consumed from the rest controller
• 121:30 - 122:00 coming to the customercontroller it.java it is basically for the integration test for S Services and customercontroller test.java is for the unit test for the rest services and the main file here is customer service application.java which is the launcher of the springboard application lastly you can see a palm file which houses all the dependencies you need to build for this project so in this project I'm using spring boot starter web okay now that all of you are familiar with the project structure let
• 122:00 - 122:30 me get you guys into the business service for our application as all of us know that a single application has various layers such as web database and business all these layers have their own specific responsibilities that you can understand by the name so now let me open the customer service.java file well so as all of us know that applications need data instead of talking to a real database I'll be using an array list which is kind of a memory data source
• 122:30 - 123:00 so now let me explain you the business Logic on which I've built this application well in today's world as all of us do online shopping you can very well understand that a customer can order multiple products so a product must have an ID name description similarly a customer has an ID name description and the list of products he or she has ordered so this customer service.java file is basically exposing the methods let me grief you a little bit about the methods so let me just scroll down so basically this retrieve
• 123:00 - 123:30 all customers method retrieves the details of the customers the public customer retrieve customer for a specific ID retrieves a specific customer details this particular method that leaves all the products a customer has bought scrolling down Okay so this method retrieves details for a specific product a customer is bought and finally if a product has to be added to an existing customer then this method is required so well these are the methods that we have we also have some entities such as
• 123:30 - 124:00 product.java and customer.java so when I open this product.java file I can see that the product is nothing but a simple object which has ID name and description coming to the second entity customer is also an object which has ID name description and also customer has a list of products he or she has bought coming back to this customer service file all it does is it initializes the list of products let me just explain you the code now so we start by using a simple static array list to store our data to
• 124:00 - 124:30 keep it simple so basically we're storing all the list of products here we are creating this application for five simple products and two customers buying those products so we have product one two three four five and payal and Neha buying those products other than that we also have some few important methods that I told you previously so let me just scroll it down for you so we have a method to retrieve all the customers to retrieve a specific customer for a product to retrieve all the products that we have and also to
• 124:30 - 125:00 add products so let me just tell you that all of these are very simple methods that we have created for our service now question comes why have we created this method well the answer to this question is that we just want to use these methods from the controller so now that we have our business logic ready which is very important to us is everybody clear with it okay I've got a yes from most of you that's great so now coming to the main concept how and where should we add our get service so to add a get service you
• 125:00 - 125:30 just need to add add the address control annotation which is used to expose the rest services so let me just open the controller file and show you okay so this controller file will expose our rest Services as this annotation is included here so now if you scroll down this file you can see a couple of get methods well let me tell you the meaning of all these methods look at the first method which says customers customer ID Products so basically slash customers is the part we
• 125:30 - 126:00 are using and the one in the flower bracket that is the customer ID is the path variable so you can see that the path variable is mapped to the customer ID so if I say suppose customer slash customer customer one then I'm talking about customer one and want to get the list of products that customer one has ordered similarly if you go to the second method that is the customers customer ID Products and product ID you can see that this method is used to retrieve a specific product for a specific customer
• 126:00 - 126:30 one interesting fact that I would like to tell you is that we have used The annotation Accurate Auto wired what does it mean why are we used well in detail you can refer to my previous video on Spring boot tutorial but let me just brief you a little bit about it well at the red Auto white annotation is used to Auto wire in the customer service so now if you just want to check whether the service is working or not let's just launch this application so let me just right click on this project go to run as and choose spring boot app
• 126:30 - 127:00 well at the end of the console you can see that Tomcat has started on port number 8080 and the customer service application has started so now to check if your application is working or not open the browser and type localhost colon 8080 slash customers suppose if you want to check for customer 1 given the parameter as customer 1 and map it to products
• 127:00 - 127:30 okay so on the screen you can see the details of products that customer one has bought so have you all just thought how are we getting the output as Json file when we just listed the data as a list well this happens because of something known as message converters so springboot has this thing called Auto configure through which it configures many message converters so message converters basically look at the request and identify what exactly client is looking for so if a client is looking for Json file then the message converter
• 127:30 - 128:00 would convert this Java object product to a Json file now let me just tell you that the message converter is auto registered with the spring boot okay so the post method that I mentioned in the starting of the video well I told you that we use it to create a new resource so just in case if I have to create a new resource for this application I'm going to post map and map the URL to it so what does this post mapping do so post mapping would be to expose this as a post request and path variable is mapped to it now one more
• 128:00 - 128:30 thing that you can see here is the request body product new product so whatever product you would put in the request body would be automatically bound to here so when you execute the request we would put the details of the product in the body of the request and then the request gets bound to the request body once the product is found the location of the product is printed but if the product is not found then it returns null foreign [Music]
• 128:30 - 129:00 Services security let's understand the problems faced in microservices well the problems faced in microservices are as you can see on my screen starting with the first problem consider a scenario where a user needs to log in to access a resource now in microservice architecture the user login details have to be saved in such a manner that the user does not asked for verification each and every time he or she tries to access that particular resource right now this creates a problem as user details might not be secure and also
• 129:00 - 129:30 could be accessed by the third parties now obviously guys to anybody user credentials are the most important credentials which have to be secured right now in a scenario where a client is logging to an application to access a resource the application gets the complete credentials of the user now if the credentials are not secured by those Services then that's definitely a problem because anybody can exploit it so that is one problem that I clearly see problem number two is basically I would say when a client sends a request
• 129:30 - 130:00 then the client details need to be verified and also the permissions given to the client needs to be checked right so when you use microservices it may happen that you know for each and every service you have to authenticate and authorize the client so authenticate is basically to check what permissions are given to you and authorize the client is basically to check who are you right so basically the use of credential subject now to do this developers might use the same code for each and every service right so what I mean by that is when a client is trying to access few data from different Services it may happen that
• 130:00 - 130:30 you know the client details have to be checked to make sure if the data has to be sent to that person or not right now to check that maybe a specific code is used in all these services for a specific application like Service A B C D E can all use the same code to check the authenticity of the client don't you think relying on a specific code reduces the flexibility of microservices well obviously that's a yes right so this is one of the major problems also I see in the microservice architecture that the complete
• 130:30 - 131:00 application having various Services is based on a single code base and let's say you build an application now with that particular code in all the services to check the authenticity of the client but let's say after 10 years that particular code doesn't work now you have to change the code for all these services and in the same time you also have to make sure that you know nobody is exploiting the data from the services because there will be no security layer then right so this is one major problem that I see that you know there has to be catered so the next problem that is very
• 131:00 - 131:30 prominent in this particular architecture is basically the security of each individual microservice now what I mean by that is basically in this architecture all the microservices communicate with each other simultaneously in addition to the third-party applications right so when a client logs in from a third party application you have to make sure that you know the client does not get the access to the data of microservices in a way that you know he or she might exploit them right so it obviously makes sense because he's logging from a third-party application so maybe that
• 131:30 - 132:00 particular application is not that secure so maybe instead of the client the third party application is basically trying to access the data so we have to make sure that you know the data is secure and not every application is given an access to the data in the services right so Guys these are a few problems that I see very much prominent in microservice architecture well there could be lot other problems based on security of microservices so these are few problems that I thought would be very prominent right now obviously things so many problems we have to
• 132:00 - 132:30 figure out a way to secure our services right now to secure our services all we can do is we can put up security layers firewalls and you know use some methods to make sure our services are secure right so on that note next in the session let's say the best practices for microservices security well the best practices for microservices security a lot I would not say the ones that I mentioned are the only ones there are a lot of ways through which you can secure your services but I would say these are few methods you know through which you
• 132:30 - 133:00 can start at least securing your services or maybe you can figure out a way to at least make sure your data is secured right so let's start with the first one that is defense in-depth mechanism now as microservices are known to adopt any mechanism on a granular level you can apply the defense in-depth mechanism to make sure that you know the services are more secure now what I mean by that is the defense in depth mechanism is basically a technique through which you can apply layers of security countermeasures to protect the sensitive services so as a developer you
• 133:00 - 133:30 just have to identify the services with the most sensitive information and then apply a number of security layers to protect them so in this way you can make sure that you know any potential attacker cannot crack the security on a single goal and has to go forward and try to crack the other layers in the defense mechanism right so basically if you say you know service B is the most sensitive service which has you know a lot of information which has to be secured right so what you can do is you can basically have layers of security
• 133:30 - 134:00 and maybe if some attacker cracks the security of the first layer he or she has to still go and crack the other layers but by that time you'll definitely understand that you know there's some problem in security happening and then you'll again secure Services right also since in a micro service architecture you can Implement different layers of security on different Services an attacker who is successful in exploiting a particular service might not be able to crack the defense mechanism of the other services for example let's say you have service a and service page and let's say you know
• 134:00 - 134:30 you have few layers of security and service a and few different layers of security and service speed now maybe an attacker who has attacked service a and has cracked the security might not be able to do the same voiceover speed right so that was about the defense in depth mechanism guys let's take a look at the second best practice that is usage of tokens and API Gateway now often when you open an application you see a dialog box saying accept the license agreement and permission for cookies right now what does this message signify well once you accept it your
• 134:30 - 135:00 user credentials will be stored and a session will be created now the next time you go on the same page what will happen is that you know the complete page will not be loaded from the server but but will be loaded from the cache memory right so I hope that's clear so for example let's say you know you open bookmyshow.com so now the first time that you open and then you accept the license agreements on the cookie permissions what will happen is that your user credentials will be stored and a session will be created now the next time again maybe sometime later you open took my show again that particular page
• 135:00 - 135:30 will be retrieved from the cache memory rather than the service itself right now before this concept came into the picture sessions were stored on a server side centrally now this was one of the major problems as you know storing the session centrally was being a barrier to horizontally scaling the application so to overcome that what people started doing is basically everybody started using tokens and API gateways to secure the services right so what would happen with tokens is that you know tokens would be used to record the user
• 135:30 - 136:00 credentials so basically you can understand that you know tokens have used to store the user credentials so these tokens are used to easily identify the user and are stored in the form of cookies now each time a client requests a web page the request is forwarded to the server and then the server determines whether the user has access to the requested resource or not right now the main problem which is prominent in tokens is that the user information is stored right so the date of the tokens needs to be encrypted to avoid any other exploitation or from third party resources and I would say JWT or
• 136:00 - 136:30 most commonly known as Json Web format is an open standard which defines the token format to provide libraries for various languages and also encrypt the user details right so guys just to avoid storing sessions centrally what people started using is tokens now tokens are used to store the user credentials and since the user credentials are stored in the tokens tokens have to be encrypted themselves so you can go forward and use JWT to encrypt the respective tokens right coming to API gateways API
• 136:30 - 137:00 gateways ads as an extra element to secure the services through token authentication so the API Gateway acts as an entry point to all the client requests and efficiently hides the micro services from the client so the client basically has no direct access to the services and thus in that way no client can exploit any of these micro Services right so what happens is that you have a client and then you have API Gateway Now API Gateway will communicate with all the apis present in the Microsoft courses right so basically over here if
• 137:00 - 137:30 you visualize the client has no direct access to the services instead it's just the API Gateway and it's completely the responsibility of the API Gateway to forward the request to the respective micro servers so guys that was about tokens and API Gateway let's move forward with the third best practice that is distributed tracing and session management now talking about distributed phrasing all of you might be observing that you know while you use microservices you have to monitor all these Services continuously right but
• 137:30 - 138:00 when you have to monitor humongous amount of services simultaneously that definitely becomes a problem right for example if you just have to monitor five Services then maybe that's an easy task but in a scenario maybe if you have to monitor 50 or 100 tasks simultaneously and 24 7 then that's a problem right now to avoid such challenges what you can do is you can use the method of distributed tracing so distributed tracing is basically a method to pinpoint the failures and identify the reason behind it now not only this but you can also
• 138:00 - 138:30 identify the place at which the failure is happening so basically with that you can easily track down which microservice is facing a security issue right for example let's say you know you have five services and then there's some error happening at service B right so you can directly go and pinpoint that it is because of service B there's some failure and maybe then you can directly go and figure out that you know there's some security issue at service B rather than to check all the services and the complete application right so that's what distributed tracing helps you guys it makes you identify where is the
• 138:30 - 139:00 failure happening why is the failure happening and then bit service is it affecting moving on to session management session management is an important parameter that you have to consider while securing microservices now what happens is that a session is basically created whenever a user comes onto the application so what you can do is you can handle these sessions in many ways I could figure out three ways the first way is basically you can store the session date of a single user in a specific server what I mean by that is the session date of user is maybe stored
• 139:00 - 139:30 on server a the session date of user B is basically stored on server B and session date of user C is basically stored on server C right so in that way you can make sure that if there is some exploitation of services then you can track down which user is doing it directly without having to figure out what is happening and all you can directly track down that you know maybe user is exploiting or user b or user C right but the only problem over here that I see is that you know it the system is completely based on load balancing between the services and it
• 139:30 - 140:00 meets only horizontal scaling rather than the vertical scaling so for small applications which let's say you know have three to four Services maybe this kind of system can be used but if you want to use this scenario for a large application then I think that will create a problem right coming to the second way well what you can do is to complete session data can be stored on a single instance then what can happen is that you know the data can be synchronized to the network and the requested responses can be generated and you can also make sure that you know the
• 140:00 - 140:30 data doesn't go anywhere right so what happens is that you know you have a single instance and then through Network the data is completely circulated between services and the client now the problem if you think over here is basically the exhaustion of the network resources right for example let's say you need a data from 10 Services right and all the data is completely stored on the single end steps now all these Services have to communicate with that particular instance get the requested response and then finally send back to client right now this is a little bit problematic when you have that Services
• 140:30 - 141:00 again but I would say for small Services you can go forward right now finally coming to the third method what you can do is you can make sure that the user data can be obtained from the shared session storage so as to ensure that all the services can read the same session data so what I mean by that is if you have five services and the five Services need the user data then the user data is obtained from a shared session storage through which the data can be retrieved right but since the data is retrieved from a shared storage you need to make sure that you
• 141:00 - 141:30 know you have some security mechanism to access the data in a secured way so basically you have to make sure that you know you add another security layer Maybe by using the defense and depth mechanism to make sure that you know the data is encrypted with the help of tokens or maybe you know you have a specific firewall that you know not all of them can access the data and no third-party applications can access and only a few admins can access right so you can use it the way that you want so guys that was about distributed tracing and session management let's move
• 141:30 - 142:00 forward with the next practice that is first session and mutual assessor now the ideal first session is really simple guys what you can do is basically when the users log in for the first time into the application then they can access all the servers in the application right so what you can do is whenever the user logins for the first time you can store his or her details in an encrypted format in a secured way so that they don't have to keep verifying their credentials each and every time they are trying to access different servers for example if you have 10 Services then maybe the user needs to log into all the
• 142:00 - 142:30 10 Services what you can do is you can have an initial login and when the user logs in for the first time maybe he or she gets access to all these services but the only problem over here is that you know you have to make sure that you know the user who is trying to log in as a client himself and maybe he or she is not an attacker and is not trying to exploit to the sources right coming to Mutual SSL applications often face traffic from users third parties and also microservices communicating with each other right but since these
• 142:30 - 143:00 services are accessed by the third parties there's always a risk of attacks now the solution to such scenarios is by using Mutual SSL or Mutual authentication between microservices with this the data transferred between the services will be encrypted and the only problem with this method is that you know when the number of microservices increases then each and every service will have its own TLS certificate it will be very tough for the developers to update the certificates else if I would say the developers are ready to update the certificate and maybe they're not scaling the number of services then I
• 143:00 - 143:30 think they can go forward with this particular method as you know each particular service will have its own PLS certificate and that particular certificate will Define which microservice has what access and which data can be retrieved from each of these Services right so mutual SSL sounds like a good option guys I think you should go forward or not but the only thing is that when you're scaling your service you have to make sure that you know you have to update all these TLS certificates on that note let's move forward with the final practice that is the third party application access now
• 143:30 - 144:00 all of us access applications which are third party applications right right so the third party applications basically use an API token generated by the user in the application to access the required resources so the third party applications can access that particular user's data and not the other user credentials well this was with respect to a single user but what if the applications need to access data from multiple users how do you think such request is accommodated well I think the solution to this is by using auth so
• 144:00 - 144:30 when you use auth the application prompts to use it to authorize the third-party applications to use the required information and generate a token for it so generally what happens is that an authorization code is used to request a token to make sure that you know the user's callback URL is not stolen right so in this way the user of the client communicates with the authorization server one mentioning the access token and also the authorization server authorizes the client to prevent others from forging the client's identity so when you use microservices
• 144:30 - 145:00 with auth guys the services act as a client in the art architecture to simplify the security issues right so I would say guys all these methods that you know that I've explained you are one of the best practices that I've observed to secure your microservices but if you ask my personal opinion I think I would always go for auth with a collaboration of JWT that is basically generating client tokens and always follow the defense and depth mechanism to make sure that you know there are a number of security layers to my services so that the data stored in my services is
• 145:00 - 145:30 completely secure right so if you're someone who is aspiring to build an application based on microservices then remember that the security of the services is one important factor which you need to be cautious about right [Music] number four we go into details about sov and micro Services let's see what is a monolithic application and how that functioned first of all you can think of a monolithic application as a container which is basically hosting a number of
• 145:30 - 146:00 software components right there can be a number of software components as part of your software application and if they are all hosted together and delivered together then that's called a monolithic application now there are various challenges with any software application which is implementing the monolithic architecture first of all they are not flexible okay monolithic applications they cannot be built using different Technologies that's the problem the Second Challenge is that they are unreliable even if one feature of the system does not work then the entire
• 146:00 - 146:30 system will not work the third challenge is that these monolithic applications are not scalable they cannot be easily scaled and even if the application needs to be updated then the complete system has to be rebuilt the next problem is that with these monolithic applications they block continuous development all the features cannot be built and deployed at the same time they will have to be done separately the next challenge with monolithic applications is that the development is very slow they take a lot of time to be built since each and every
• 146:30 - 147:00 time every feature has to be built one after the other and most of all the monolithic applications are not fit for complex architecture because of course you cannot use different Technologies you are very limited and very constrained right so that is the challenge with monolithic applications so now let's go on to SOA which is nothing but service oriented architecture now with SOA these services or features they are broken down right the entire software application is not built as one but the different features
• 147:00 - 147:30 and the different services are broken down into smaller components right so that's why it's called Coors grained architecture and over here if we have let's say one software application inside which it provides and if it provides like five features or four features then all those four features are delivered by four different services and that is what you can see over here right there are four different services and each of these Services would have multiple tasks inside them and these smaller tasks are together delivered as
• 147:30 - 148:00 one particular feature and the whole software application comprises of a number of these features but with micro Services it's a little more different now these features or services are further broken down into task level services so here it was feature level Services whereas the services here their task level each and every task in a particular feature that was broken down and that's why you have multiple tasks and multiple services in a micro service
• 148:00 - 148:30 architecture and that is why this is called fine-grained architecture so that is what the differences are between these three on a high level now before I go further and confuse you people let me just go into more details about the differences between SOA and micro services you can think of the difference between sov and micro services with the help of these images so SOA is like an orchestra similar to you having multiple performers you will have multiple services but each of these performers will be controlled by one particular director and similarly in SOA even
• 148:30 - 149:00 though you have multiple Services these services will be interacting with one another and then they will be delivered as one particular software application but whereas in case of a micro service there are multiple or let's say there are independent performers but these independent performers are not controlled by any director so they work separately and they work in silos so that is a difference so I hope you can understand the difference between the two from these images right even though they work together they are controlled
• 149:00 - 149:30 by one particular director and that's why this is called a centrally governed architecture and whereas micro Services you do not have a centrally gone architecture and that's why it's called a decentralized governing architecture so let me go forward and talk about the difference between these two which is nothing but Micro service and SOA with respect to certain parameters let's look at the difference between them with respect to architecture and coordination so first of all in SOA there are four different
• 149:30 - 150:00 types of services first is business service the Nexus Enterprise service then we have application service and then we have infrastructure service so these four service types together form your SOA and they together deliver your software application now what are these different services and what do they do let's see that first is business service right so your business service is the one that's going to be performing your core business operations
• 150:00 - 150:30 and it can be either represented by your XML or by web service definition language and then we have Enterprise service the Enterprise service is that service which implements the functionality defined by your business service and the Enterprise service does it with the help of the application service and the infrastructure service now moving on we have application service the application service is the actual core application or the core functionality of that feature and these application Services
• 150:30 - 151:00 can be either invoked directly or they can be invoked through a user interface and now we have infrastructure service the infrastructure service refers to those non-business or those non-technical operations such as auditing scaling or security and all these things those are the different services in a SOA but in case of micro Services architecture you do not have these many types of services you just have a functional service and you have a infrastructure service the functional service is basically the combination of
• 151:00 - 151:30 a business service an Enterprise service and an application service now a functional service is a fine grain service so basically if your business logic or your business operations requires a particular feature to work then the task that is related to exactly that particular feature that is performed by the functional service and besides the functional service we have an infrastructure service and the infrastructure service over here is very similar to the infrastructure service that is there in SOA the uh it does all the non-business or the on technical
• 151:30 - 152:00 operations such as your security auditing and logging okay so that is the difference with respect to architecture and coordination so now moving on to the next slide we have heterogeneous interoperability now what this means is any software application and need not be developed on the same programming language now in your main software application you might have smaller applications right and each of those smaller applications could be written on Java or it could be written on see uh dot dot net or it could be written on C
• 152:00 - 152:30 sharp or python or anything now when it's written in different programming languages it's tough for them to interact with one another and if you want the different services to communicate with one another then you would have to bring a particular platform right so that's where you have this messaging middleware so in case of SOA there is something called as a messaging middleware which acts as the communication point or the interaction point between the different applications which are in a different language so you can see that this application is on either C sharp or dotnet and this is on
• 152:30 - 153:00 elastic Java beans right so not only here it's C plus plus and here it's Java so and all of these communications they go through this one particular messaging middleware but in case of micro Services we do not have any broker here the communication happens directly between application to application even if they are in different programming languages even if they are structurally different and even if they are built in different grounds so look at this if you have a c shot or a dotnet application which is communicating with a Java application
• 153:00 - 153:30 but then how does it happen it happens with the help of a rest API there is a direct communication between these two services and similarly if you have another Java application which wants to communicate with another Java application the communication would take place with the help of rest API and similarly Java to c-sharp or dot net would again take place with the help of a rest API so there is no broker here or middleman which is a messaging middleware the communication is directly to the other application then comes service granularity
• 153:30 - 154:00 if you can remember I earlier told that in microservices you do not have the software delivered as a whole right it is broken down into smaller features and if you're basically performing an operation which involves multiple applications or multiple Services then those services are called by one another when it's needed so as an end user as a consumer you might be performing one operation okay so that one operation would not be calling all the different Services it would call one service and
• 154:00 - 154:30 this service when it needs to interact with the second service this would make the call to service too and similarly your service to when needed it would call service number three and similarly the once the service requested made the service response is also given to the one that's invoking the request now the catch here is each and every service request and service response takes 100 milliseconds okay so let's assume it takes this much time the API calls and this is in case of micro services so in the microservices architecture when each call takes 100 milliseconds in total for
• 154:30 - 155:00 this service to get successfully returned it would take 600 milliseconds now that's an awful lot of time for an API call to complete successfully right for an API called we made successfully and to be returned and this is where it is different from an SOA so in case of an SOA the service consumer would again be calling would be would be performing one particular operation and uh what happens here is this operation would be calling the different Services all at the same time so the operation over here
• 155:00 - 155:30 would be calling the service number one service number two and service number three it should be encompassed all together so one particular call will be made to the servers and all three would be servers at the same time and by this you would be saving time because all the three requests and responses would be made simultaneously so you would be saving a good 400 milliseconds over here so that is the difference in service granularity between SOA and micro services so the next difference we are going to see is with respect to component sharing this is very similar
• 155:30 - 156:00 to the previous slide again right because then it would be the same order service which would be interacting with your different smaller applications each for customer management and for warehouse management and for order fulfillment and the data again would be stored in different databases But there again is the difference in micro Services because in the micro Services architecture for each and every application so for customer management we have a separate order service and that order service would be accessing its own database for
• 156:00 - 156:30 Barrows management you have a separate order service which should be accessing a different database and then for order fulfillment which is again a different application this would be using a different order service and this order service would be using a different database from where it would be accessing data right so that's how there's a difference in even competent sharing between these two architectures and then we have the next difference between them and that is the middleware versus API layer this we also spoke about earlier right your SOA uses
• 156:30 - 157:00 middleware for communication and your micro Services uses an API layer for communication so that is about the differences between SOA and micro services now let's go ahead and look at the differences between the two by understanding with an example of a shopping cart so every e-commerce portal will have a shopping cart right uh where you can add your products to the cart and then you can check out later so for adding an item for removing an item for checking what is the tax for checking the total
• 157:00 - 157:30 bill amount for all those things you have a shopping cart application and then finally we have another application which is the main application which gives details about the product so it will give us details about the product name what is the product ID what is the product rate uh how many quantities are present and all different other options right what color the product is and all these things now these are three different applications and when they work together you get the complete software application right now each of
• 157:30 - 158:00 these applications would have smaller tasks a shopping cart application like I told you before it would have an ad or remove functionality where you can add a product to your card you can remove a product from your cart you can check what is a bill in your cart you can check out what is the tax that is there and all these things similarly if you talk about a product catalog you have other tasks right so all these tasks together form one particular application service in case of a SMA shopping application but in case of micro Services shopping application each of
• 158:00 - 158:30 the different tasks that these Services provide those tasks are broken down into smaller fine-grained services so here we have feature level Services Where Shopping Cart is one feature product catalog is one feature and user account application is one more feature but in case of micro Services we have a separate billing service for shipping we have a shipping options service we have a tax calculation service right so the different tasks in this particular feature it's broken down similarly for
• 158:30 - 159:00 product catalog application we have different task level breakdown such as display product service you have an update display service we have user default service and many more similar for user account application right we have a send email service and many more now that you've understood that micro server is all about breaking a particular feature or a feature level service into task level services so let's see how microservices shopping application is different so first let's take the case of where a micro service
• 159:00 - 159:30 shopping application is better so here we'll have certain features which are common to multiple applications right so we have something like display image server so it's a smaller task level servers over here but the image of the product being displayed might be common across all the three applications it might be present in the shopping cart also and the image of the product might be present in the user account application also with us showing which are the products which the particular
• 159:30 - 160:00 user bought and then you might have the product you might have the image of the product in the product catalog application also so in this case if there's a change in the image Dimensions or in the license of the image or anything with respect to the products image then the code of course would be similar in all the three applications right the code may be similar but the code has to be changed everywhere right and when you change the code when you rework then it causes a lot of problem again now when you change the code here
• 160:00 - 160:30 you're changing the functionality and that might cause this particular application to behave abnormally it might have bugs or the application might cause failure and similarly if you change the code over here then even this might throw errors and you might have bugs similarly to this particular application also so if you want to avoid all those things you have to test each of these applications separately after changing the code and after updating the required details and after testing it you will have to deploy each of these applications and you have to deploy them separately now all these things is time
• 160:30 - 161:00 consuming right so it is the same change that you are doing across all the different parts of your application but even though you're doing it everywhere even though you're doing something similar you'll have to test and deploy each of them and sometimes you might have errors in only one particular application and not everywhere so these are all time consuming tasks but if it's in case of a micro Services shopping application you would not have this problem because all the different tasks over here they are provided as a service if you want to change the way the product's image looks then you will have
• 161:00 - 161:30 to change only this particular application right so by only changing this service your job will be done you do not have to worry about the other services and you do not have to change anything over there so the main change you will have to be doing will be restricted to only this particular service so you save time and you save effort over here in case of micro Services shopping application now this was a use case where the micro Services shopping application was better but then there are also times when an SOI shopping application is better for you so this was a classic use case of where
• 161:30 - 162:00 a micro server swapping application is a best fit but let's see a use case where an SOA type of a shopping application and the sov architecture comes out better and that example is when your product is not actually that big so in this case yeah you have a lot of functionalities you have a lot of features and tasks so just consider the example of a very simple software application which needs three primary functionalities one which has like a shopping cart which into
• 162:00 - 162:30 where you can add your or you can add your items and then you have another user account application where you will have the user profile and then you'll have a product information application right so over here all these different applications will not have too many sub-level features or sub-level applications yeah very straightforward they are very simple in this case if you're having if you're implementing micro Services architecture then you will have to go through a lot of trouble which can simply be avoided because your application is in itself very simple you
• 162:30 - 163:00 have to just you know create one one website where you can have one website in which you have a cart wherein you can add your products which you want to buy then when you're checking out you can have the user information displayed and then you have details about the product which is a separate application so in this case it could just be these three different services so that is the difference between an SOA so I think by now you understand that neither of them is better than the other right so there are times when micro Services is preferred and there are times when soas preferred and you cannot hardcore it by
• 163:00 - 163:30 saying that uh one is better than the other [Music] now if you consider an e-commerce application what do you think are the main three functionalities of it for example let's say you're using Amazon what all do you see you're a customer right you see all the products on Amazon and then you put your products into the cart and finally you order those products right that is basically the simple workflow if you have to understand now if you have to build this
• 163:30 - 164:00 application using microservices what you can do is you can have mainly three functionalities that is the customer information the products available in the cart and all the products available on the website right now all these three functionalities can be put into different different Services what I mean by that is you can have service a having customer information so always be having the products available in the cart and service C having all the products available in the application right now when the customer goes forward and orders a particular product you can have
• 164:00 - 164:30 a composite micro service which will basically take data from all these three services and generate the output for the client right so I hope you've got an idea of what I'm talking about right now as I was telling you that you know before microservices came into the picture there was monolithic architecture how do you think all these functionalities of the application were stored in this kind of architecture well it's really simple what would happen would be all these three services that is the customer service the product service and the card service would be residing in a single area and then there
• 164:30 - 165:00 would be a data access layer through which you can access the data right so as you can see on my screen you have a client browser through which the client it was for the information so as soon as the client would request for the information on the application the request would be passed to this particular area where all the functionalities are present and the data would be retrieved from the data access layer on the database so if I have to just Define monolithic architecture for you then it's really simple guys monolithic architecture is an architectural style in which all the functionalities or the required
• 165:00 - 165:30 components would be inside one single block right so I hope that particular part is clear so I hope that you've understood what was monolithic architecture and what are microservices on that note let's get into the second topic for today's session that is what are apis what do you think apis are obviously everybody has heard of this term API right so you can basically understand apis as a point of contact through which all the services communicate with each other to process the client request and send the response right so for example let's say you know
• 165:30 - 166:00 you've sent a client request let's say on Amazon you've requested for a phone right so if you just type phone what will happen is that you know this particular request will be sent through apis to the respective functionality or a feature right and that particular functionality or a feature will retrieve the requested data and then we'll send back the response to the a client right so if you see you're a client then this particular functionality or a feature present in the application and then in between both of you this API through which we can communicate right so I hope
• 166:00 - 166:30 that point was clear now while building and using these applications what developers do is that you know we basically use the crude operations when I say crude operations what I mean by that is we basically create a resource read a resource update a resource and delete the resource so apis are generally developed by using the restwork style and these methods are nothing but the HTTP methods now I'm sure you must have got confused when I said create a resource read the resource update the resource and delete a resource well guys it's really simple to
• 166:30 - 167:00 understand for example let's say you know you're using bookmyshow and then you want to find out the details of a specific movie so what you do is you send a client request so when you send a client request you're basically asking for the information right so what will happen is that you know the information has to be read and then the response has to be sent as a client so that's basically resource coming to creating updating and deleting this is on basically the developer side where you know they keep adding the information to the application or maybe specific movies
• 167:00 - 167:30 details are updated or maybe the complete movie is deleted right so basically the information of the movie is deleted once it is out of the market right so that's how basically it works now whenever we send a request what happens is that we are basically sending an HTTP request right so for that we use the HTTP methods right so next in the session let's understand the different HTTP methods so the HTTP methods are as you can see on my screen we basically have the post get put and delete methods
• 167:30 - 168:00 so whenever you want to create a resource you basically use the post method whenever you want to read the resource you use the get method whenever you want to update a resource you used put method and whenever you want to delete a resource you use a delete method right so basically guys apis use these methods to basically communicate gate between the client and the respective functionality of the feature of the application right now if you want to know more about HTTP methods and apis you can refer to my session on what is
• 168:00 - 168:30 this API so on that note this is all that you have to understand to understand the differences between apis and microservices right so now that I've told you you know what are microservices and what are apis let's continue where are exactly apis used in microservices now when I was explaining apis for you I was always saying that you know they're basically a middle person between the client and the respective feature or the functionality now obviously that particular feature or the functionality can go into a specific service right so
• 168:30 - 169:00 let's say you know we have a functionality of all the products present in the application now that particular feature can be present in a specific service right so now when a client requests for all the products available in the application the request can directly go to that particular service and the response can be generated back so I hope that point is clear so what you can do is basically the application that we took the example that we took we had a client browser and in the monolithic architecture the customer information the product service and the card service all these three
• 169:00 - 169:30 services basically all these three functionalities were residing in the same area and then there was a common data access layer and then a common database right now when you break down this application or maybe when you refactor this application into microservices what you can do is you can have a specific microservice and then you can have its own data access layer and database and for each microservice there's a separate API right so basically the customer microservice will have a specific API its data access
• 169:30 - 170:00 layer and database similarly goes for the product microservice and the cart microservice now it's not necessary that you know there's single database for each and every microservice it may also happen that you know two or three microservices share a common database through which the data is retrieved right so basically guys if you have to understand where apis I used in microservices it's really simple each service will basically have its own API through which the services will communicate with the client right so for example let's say you know you're a client and then you're asking for your
• 170:00 - 170:30 own information your own customer details what will happen is as soon as you send the request basically the API Gateway will decide to which service this particular request has to be sent now since we want the customer details this particular request will directly go to the customer micro service and what will happen is that you the required data will be retrieved from the API and then again the API will send back the requested response to the client right so basically that's all that you have to understand guys that you know each service will have its own API and then
• 170:30 - 171:00 through that particular API you can communicate with that particular service right now it's not necessary that you know you need information from a single service right even in that scenarios what will happen is that you know each microservice will generate the requested data and all of them together will send back the requested response to the client right so I hope that you've understood where our apis used in microservices right now let's move forward with the final topic for today's session that is the differences between microservices and API now in this
• 171:00 - 171:30 tutorial on microservices versus API I hope that you know you've understood what are basically microservices and what are apis guys these are completely two different things microservices is basically an architectural style through which you can build the applications in the form of small and autonomous Services coming to apis apis are a set of procedures and functions which allow the consumer to use the underlying service of an application right so basically guys this is the main difference between microservices and API
• 171:30 - 172:00 the microsource is basically an architecture through which you can build the application and apis is basically like a middle person between the client and the services through which you can establish communication between both of them right so I hope that point is clear also from the example that I had explained you I'm hoping that you know it's clear to you that you know apis are part of microservices and thus it helps these Services communicating with each other however while communicating with the other services each service can have its own crude operations to store the
• 172:00 - 172:30 relevant data in the database not only this but while performing recruit operations apis generally accept and return the parameters based on the request sent by the user so for example if the customer wants to know the order details right so maybe he must have ordered few items what will happen is that you know the product details will be fetched from the product service the billing address and the contact details will be fetched from the customer service and the product purchased will be fetched from the card service right so basically if you have to you know
• 172:30 - 173:00 generate a specific data or maybe if you want a specific data all these Services can communicate within each other with the help of apis and generate the requested response right so I hope it's clear to you guys so guys this was the basic differences between microservices and API microservice is basically a simple architectural style and apis are a set of procedures and functions which allow the consumer to use the underlying service of the application so if you're someone who is aspiring to build an application using microservice
• 173:00 - 173:30 architecture I would always say that you know make sure that you know your apis are working and then all the services are working are collaborated with the apis in such a way that you know no request is harmed and maybe all the client requests are satisfied with the requested response right so I would just say go forward and build applications using microservices [Music] so the first question is what are micro Services now think of it as an approach
• 173:30 - 174:00 towards software development what do I mean by this what this approach does is it aims at having small autonomous services that Focus towards a common business goal now as you can see in this image what we have is we have n number of business domains and surrounding that are certain micro Services now each of these micro Services they focus at a particular business functionality only that means if a particular business domain has say 20 functionalities each of microservices would focus at one
• 174:00 - 174:30 functionality only for 20 micro Services 20 corresponding functionalities so that is how you simplify an architecture and this approach is called as micro Services architecture as we move further we would be understanding a lot more points and Concepts about microservices so you would have a lot more clearer picture as to what a micro service exactly is meanwhile you just bear with me so that we can move further and discuss as the other questions as well so what are the advantages of micro Services architecture well there are
• 174:30 - 175:00 quite a few advantages to be honest these are some of the important ones which we have jotted down the first one is independent development now when you talk about micro Services you have to relate it to this point because we are talking about having an individual micro service for individual functionality that means for each functionality you can develop a separate service and you can manage it and control it totally apart from that we also ensure independent deployment that means if you have developed a single service you can
• 175:00 - 175:30 go ahead and deploy that service you do not have to wait for the complete architecture or other services to be ready and up for deployment even if there is certain amount of change in a particular service you have to make change only to that service and then deploy it again you do not have to deploy the complete architecture here fault isolation now if a particular micro service goes down it does not affect the functioning of other services now what do I mean by this say for example I have an architecture where I
• 175:30 - 176:00 have some printy applications or 20 Services working parallely if one of the application fails at times what happens is these applications are interdependent as it is in the case of a monolithic architecture basically if one of the system fails or one of the services fails it takes the whole system down now this is not true with microservices if one service fails it does not affect the functioning of other services in any possible way mixed technology stack now what do I mean by this well since you have different micro services and you
• 176:00 - 176:30 have an independent approach towards development you can go ahead and pick the technology that suits the need of that service and accordingly you can have a mixed technology stack for your complete architecture granular scaling now this is an important Point scaling can be a huge problem because again you have to take into consideration the complete architecture but since you are having small Services you can actually go ahead and scale those independently again now these are some of the advantages which I just mentioned so so let us move further and take a look at the next question as well what are the features of microservices well the first
• 176:30 - 177:00 feature is decoupling that means your applications can be easily decoupled or rather separated to have individual functionality and that means it assures easy development maintenance and deployment componentization now this point is similar to the first point but it is little different what happens here is every micro service is treated as an individual component and it is responsible or manages all the entry cases as far as a particular service is
• 177:00 - 177:30 concerned and it focuses only on that it is Loosely coupled with other services that is why each micro service can be thought of as a single component or a container business capabilities now business capabilities can be focused much better because why since you are setting up smaller goals and you focus on individual functionalities it becomes easier to go ahead and develop applications to meet these requirements as far as your business is concerned autonomy what happens is your developers
• 177:30 - 178:00 are now free because you are talking about small clusters of teams and they're free to go ahead and develop the applications that means other teams and developers they aren't interdependent on each other this assures Speedy development of software basically continuous delivery now since you have so many features which we just discussed this ensures that you have constant and frequent releases of softwares and a system can be continuously updated and basically modified as per the needs of a particular company or a particular
• 178:00 - 178:30 business domain rather responsibility what happens in this approach is every domain or every project is treated as a product that means a team will take responsibility of that so-called product and they'll bring it to life and it is their responsibility to build it test it and carry on with the whole life cycle that means people are supposed to take in responsibility of the micro service that is their Iran this helps in a much better architecture other decentralized
• 178:30 - 179:00 governance now what happens is since you have individual applications it is very important to have an independent approach towards the life cycles of each microservice since they are working independently they should be managed independently as well and this also brings in another concept into picture which is decentralized data management as we move further we would be discussing that as well agility now what happens is since you have a decentralized architecture here you can easily go ahead and build applications and also discard them if they are not
• 179:00 - 179:30 needed so it gives you a lot of agility basically so these were some of the features of microservices let us move further now what are the characteristics of microservices now first few questions might sound a little repetitive because these concepts are kind of interlinked so we would be discussing quite a few Concepts again and again but as we move further the breadth of questions are the type of questions would definitely vary and you'll be having much more topics to discuss this question on the other hand might sound a little repetitive so just
• 179:30 - 180:00 bear with me let's quickly walk through it and let me just try to give you some answer to this question in a little different perspective rather so firstly we have organized on business capabilities now what do I mean by this basically what happens is since you have individual micro Services here what happens is you have an application that works on its own you also have a database that corresponds to individual microservice that means if you have 10 Micro Services you'll have 10 individual databases that are corresponding or answering only to that particular
• 180:00 - 180:30 microservice so this gives you a complete decentralized structure and this also means better organization because every micro service is very clear as to what it is supposed to do and it has all the resources in that single container as to this is what is to be done and this is what we are focused on and that is why this organization or better management comes into picture products are not projects now what do I mean by this well basically what happens is suppose you have again say 10 Micro Services now
• 180:30 - 181:00 you'll be having small clusters of team who would be responsible for building up this application and also maintaining it now what Amazon thinks is you should have a two-piece dot team basically what do they mean by this well they mean is you should have such small team that can survive on two pizzas and they should also be able to go ahead and maintain the software so every responsibility as far as a software and application is concerned it is given to that size of a team that is that can survive on two pizzas now this ensures modularity that
• 181:00 - 181:30 is why when you talk about microservices basically you are talking about products when you talk about a team they're focused on a particular functionality and that functionality is not as a project for them it is more of a product for them smart endpoints and dumb pipes now basically this means that you have different applications and they're quite decentralized and there has to be a way of communication basically so you should have Smart endpoints and good ways to integrate your applications with each other decentralized governance we've
• 181:30 - 182:00 already discussed this one so I would just skip this point for now decentralized data management we've also discussed this that means you're free to have an individual approach where you have your own database and your single database in your microservice is treated as an individual entity or a container rather infrastructure automation yes this is an important point now since you have so many microservices it is important that there is proper automation this ensures Speedy development and also maintenance design for failure now this is another
• 182:00 - 182:30 important point now your applications are such built that they do not hamper the progress of any other applications even when they fail but still you need to have a mechanism that takes care of failure as well so you have real-time monitoring and Analysis here which ensures that if an application goes down the fastest possible action is taken so that that application also comes back to running and also it does not hamper the working of any other applications in any possible way so what are some of the best practices to design micro Services now it is pretty evident you can just go
• 182:30 - 183:00 ahead and read these punch and you would understand what it means firstly you need to have a separate data store for each micro service which we have already discussed this one because we have a database which corresponds to particular microservice basically keep code at a similar level of maturity now what do I mean by this it means yes you have enough freedom to go ahead and build application the way you want to but each of these applications are at a similar level of understanding now when you talk about a similar level of understanding you are talking about a similar level
• 183:00 - 183:30 from the a business domain perspective and what this means is all the teams are on a similar page even though they're working on different things they all are on a very same level when they're working separate build for each micro service yes we've discussed this already these micro Services they get deployed in containers as we move further we'll be understanding what containers are and what they do exactly and it treats servers as stateless this helps in better communicate education basically what is a DDD now it stands for domain
• 183:30 - 184:00 driven design again it is an approach an approach that actually helps you collaborate all the teams together and it also helps you simplify the creation of complex applications now what this does is it focuses on core domain and core logic at times you let go of what is right for you rather you focus only on the business domain that means this is what the business domain needs and this is what we would include in this architecture this kind of an approach is called as domain driven approach or a domain driven design basically now what they do is they try to bring again every
• 184:00 - 184:30 team on the very same page and you would be using something called as a ubiquitous language which helps you achieve this domain driven design approach now what do you mean by a ubiquitous language to give you an example suppose I have a ticket reservation system for flights now here all the terminologies that are used would be related to maybe airplanes flight attendants customers and all those things now even if a man is refers to this so-called architecture he should be able to understand the terminologies
• 184:30 - 185:00 that are used here and also the developer that means we are bringing every team on the very same page and a language that does that for you is called as a ubiquitous language now again a ubiquitous language would be designed in such a way that it focuses around a particular domain and the architecture that is developed out of it is called as a domain driven architecture what is a ubiquitous language we just discussed that so why is there a need of a domain driven design yes there are quite a few reasons
• 185:00 - 185:30 actually firstly we need to understand that here the focus is on a particular domain so if you take a look at the last point on the left bottom side of the slide you would understand that it is mapping to a domain that means we are mapping our architecture to a particular domain that means we are focusing on that particular domain now this helps you reduce complexity why because your concern is just that domain again testing the application also becomes easier and maintaining it also becomes easier because everybody is on the very
• 185:30 - 186:00 same page knowledge rest design yes these applications are very heavy on knowledge that is particular or that is very much focused on a particular domain it brings business and service together and it is very context focused plus it uses ubiquitous language so how does the architecture of a microservice work when you talk about microservices architecture now there is no particular pattern for this kind of an architecture because it can be very complex at times and if you have a number of micro
• 186:00 - 186:30 Services all of those will have different architectures but you have to understand one thing the base Remains the Same that means no matter how complex or how big actually the architecture will never become complex but yes it might become big because we might think of having n number of micro Services maybe thousands and even blacks if required if the application is that big but let's say that you have an application which is huge in size no matter how huge it is it would never get complicated because we are developing small applications here and each of
• 186:30 - 187:00 these small applications will have an architecture that is more or less like this or at least would be on these pages so what do we have here basically we have a client an identity provider we have API Gateway static content CDN which is nothing but content delivery networks we have Micro Services a management and a service Discovery portal or a module rather and you have your servers and all those things and basically what happens is if a client wants to use a particular service the
• 187:00 - 187:30 client would send in a request now it is the job of an identity provider to verify whether the user is valid or not once the identity provider authenticates a user the request is then forwarded to API Gateway because a client cannot directly communicate to a service there has to be an intermediary or some intermediate approach that lets us communicate with the micro Services as well now in this case what happens is we have API Gateway now this API Gateway it finds the right service that a client is looking for and the request is forwarded
• 187:30 - 188:00 to that service the service does it basically communicates with other services and sees how a solution is generated for this so-called client and once the solution is generated it is sent back to the client using CD and is your content delivery Network now the static content basically what happens is whatever content that is generated and is in the form of static it is basically held by a static content and the management and the service Discovery portals they have a particular task as well what they do is say for example I have a number of services now the
• 188:00 - 188:30 Management console or the portal places those services on respective nodes service discovery on the other hand keeps a track of all these Services makes note of services that have failed and all those things and this record is communicated back to the management portal and it is the job of this management portal to go ahead and resolve if there is any failure in the corresponding architecture or any of the services so these components all of them they work in Tandem and this is how they bring the architecture together apart from that there are some other Concepts which are not there in this architecture
• 188:30 - 189:00 say for example the messaging module basically so we have an approach where messaging also happens in case if the client is waiting for a particular reply from a service in that case we have a way of communication and that way of communication is through synchronous message passing and if the client won't be waiting for a response from the service in that case we have a synchronous way of communication so yes there are those little components which are not there in this diagram but they do exist and as I've already mentioned
• 189:00 - 189:30 based on every architecture it might be little different but this is how the general idea is when you talk about a micro Services architecture so let us move further and take a look at the next question as well so what are the pros and cons of micro service architecture well we've discussed most of these points already especially the pros we've already discussed though so I'm just going to read them quickly and switch to the cons part and discuss those as well freedom to use different Technologies discussed each microservice focuses on a single business capability discussed support
• 189:30 - 190:00 individual Deployable units discussed allows frequent software releases ensures security of each service and multiple services are parallely developed and deployed and what are the cons it increases troubleshooting challenges and increases delay due to remote calls yes this can be a problem why because you're talking about n number of micro services and at times since they are so independently working that the whole system as an architecture when you talk about troubleshooting
• 190:00 - 190:30 certain challenges it can be a problem because we are talking about a complete decentralized governance but that is something that can be managed and as I mentioned we have different portals that take care of all the services and and these sizes are since monitored in real time this does not become a huge issue now increased effort for configuration and other operations yes configuring these applications can be a problem but then we have something called as rest apis that ensure complete integration of these services and again this issue can
• 190:30 - 191:00 be taken care of difficult to maintain transaction safety security can be an issue and that is a concern that affects almost every software and you cannot be 100 secure in any possible way but this approach gives room for security as well tough to track data across various service boundaries Yes again individuality may not be always good so this can be a drawback and difficult to move code between services but that is not needed in most of the cases so that is not a problem here again so these
• 191:00 - 191:30 were some of the cons and the pros which we already discussed so let us move further and take a look at the next question what is the difference between monolithic SOA and a micro service architecture now when you go back in time the first architecture that we had was a monolithic architecture that means you had a single container that had the complete architecture all your services all your databases not all your databases basically you had a single database that corresponded to all these services and yes all the
• 191:30 - 192:00 interdependencies those were inside one single container now all the advantages that we discussed about micro Services become a disadvantage here because since you had a single container or a single architecture deploying was a huge issue a single failure would mean that you would have to go ahead and work on the application and then deploy the complete architecture there was no fault isolation because if something failed everything depended on it and then you had to go ahead and repair that part and the other services had to wait for that
• 192:00 - 192:30 thing to mend and then go back to working again so yeah monolithic architecture had quite a few other problems scaling was a problem as I mentioned fault isolation was a problem then there was no individual development and deployment was a huge issue so this architecture too simple to build actually it wasn't even simple to build to be honest because you're talking about a complete application development and since you do not have individual applications that are being developed the whole team had to work in together and bringing up such huge teams can be a
• 192:30 - 193:00 problem plus there is too much dependence on each other so this also affects the functioning or basically development of a software so it wasn't even conducive or easy for development in any possible way so these are some of the disadvantages when you talk about a monolithic or a single unit architecture now when you take a look at the next approach that is SOA it is similar to micro services but here the difference is your monolithic architecture is basically divided into smaller units but these smaller units will also have some
• 193:00 - 193:30 subunits and that means you do not have complete modularity you do have modularity but that is to a smaller extent not to the best possible extent when you want complete modularity you have to go ahead and choose micro Services where if you take a look at monolithic it is a single architecture SOA it will have say four features in this case and each of these features will have individual modules that is not the case with microservices you'll have individual models directly or the
• 193:30 - 194:00 complete modularity that we are looking for when it talk about features features are just for the reference sake and all of these modules would be able to go ahead and refer these features so that is the difference between SOA and micro Services now these two are little close to each other so we can just go ahead and discuss those but when you talk about monolithic architecture it is completely different from these two architectures and there you go we have the same question that is what are the key differences between SOA and microservices to be honest there are quite a few differences that means the
• 194:00 - 194:30 approach is very different when you talk about SOA they focus on sharing almost everything with other modules but when you talk about micro Services here the aim is share as less as possible so the approach is completely different apart from that as I've mentioned you have modular applications in SOA but there are still a lot of interdependencies that is not the case with micro Services basically the other thing is when you talk about inter communication between services in SOA you need a middle there
• 194:30 - 195:00 for communication but Micro Services they're completely independent and you do not need a middleware they directly communicate through rest apis if you take a look at this architecture or this image what you see here is it is nothing but a shopping application now these are the three common things that you need you have a user account application a shopping cart application and a product catalog application now what happens is inside these applications you would be having minor services so what microservices does is it just goes ahead
• 195:00 - 195:30 and has three features that is a shopping cart feature product catalog feature and a user account feature now this feature will have nothing but those policies or those functionalities that would be needed by the individual models that your so is hiding so you have these three features and apart from that you have the models that are independent of all these features and they can just go ahead and use these features if required say for example you need something like display product service or update your display service now you have various
• 195:30 - 196:00 other things like check inventory service product creating service now all these are terms related to your shopping application but as you can see that this architecture is completely independent and it is more modular compared to what you have in an SOA kind of an architecture so these are some of the key differences when you talk about SOA and micro Services let us move further and take a look at the next question as well what are the challenges with microservice architecture now when you talk about challenges first thing that should come to your mind is automating
• 196:00 - 196:30 the components yes you can go ahead and automate all the components but maintaining these components is a huge task and automation is working smoothly something that needs constant attention configuration management and possibility perceptibility basically now when you talk about possibility and configuration management you need to understand that this is nothing but an approach that deals with the complete design that you're talking about and configuring these many micro services and having clear architecture for it can be a
• 196:30 - 197:00 problem at times debugging now debugging is another issue here because we have fault isolation and if some application fails it does not affect the working of any other application but that also means that you also have to be continuously monitoring these applications or individual monitoring is something that has to be done and that is why when you talk about system failures dealing with such failures can be a problem in the overall architecture even if it does not affect the functioning of other applications still
• 197:00 - 197:30 that application has gone down and it needs to go up so monitoring becomes a problem here plus troubleshooting so many errors for individual microservices can be a problem at times so the next question that we have is cohesion now when you talk about microservices architecture you need to understand it is a designing pattern now when you talk about a designing pattern two points that should come to your head is cohesion and coupling because a good design will always have high cohesion and low coupling to understand this we need to understand these two terms as in
• 197:30 - 198:00 what is cohesion and what is coupling link cohesion is nothing but the bond between an application or an intra Bond within an application to give you an example we have a molecule inside a molecule you will be having atoms now these atoms how closely are they bonded to each other this bond is something that is called as cohesion now cohesion should be high when you talk about a micro service that means we are referring to the fact that the interdependencies inside a container the
• 198:00 - 198:30 database and the service that is running how closely or how well gelled up are these with each other if they are very closely bonded that is good for the micro service now when you take a look at it from a bigger picture you are talking about different micro Services the bond between these micro Services should be low I mean if one fails it should not affect the other one if one is being developed the others one should still work smoothly that means inter bond between two applications on
• 198:30 - 199:00 Microsoft Services it should be loose that is why we are talking about low coupling and this interborn is nothing but coupling intra Bond inside a container it is cohesion interborn between two different applications or two different containers is coupling that is why when you want a good design you need High cohesion and low coupling the next question is what is rest and restful and what are its uses now these are nothing but apis that means
• 199:00 - 199:30 application protocol interfaces now rest stands for representational State transfer these are more or less used for integrating with your applications much better now you are talking about a decentralized architecture and to bring up such an architecture you need to have a medium through which you can communicate with all these services in a much better way and your rest or restful apis basically help you do that what is an actuator in a spring boot now this is something that would give you real-time analysis or rather it would give you or
• 199:30 - 200:00 let you monitor your application when it is in its production State now what it does is it just goes ahead and gives you all the information about a particular application that means you can go ahead and monitor all of its metrics that is what an actuator does it gives you information about an application in its running state what is spring boot now for that you need to understand what spring is now when you talk about spring the first thing that should come to your mind is it is nothing but an approach towards software development or not software
• 200:00 - 200:30 development basically web services development it gives you all the ingredients that are needed as far as a web application is concerned think of it as a shop where you get all the ingredients for web development when you talk about spring boot it is the customized version of your spring to give you an analogy think of this approach or relate it with something called as cooking and eating food now when you have spring here you'll have all the ingredients but you'll have to go ahead and cook your own food and eat it when you talk about spring boot it is
• 200:30 - 201:00 a customized approach we have ready to eat food right so ready to eat food or ready to cook food is something that is your spring boot that means all your ingredients spices would be mixed all you have to do is you have to put that food inside the oven heat it and eat it as simple as that so that is what a spring is what is a spring Cloud now when you talk about a spring Cloud again it is something that lets you get real-time analysis and perform finite amount of data processing it is nothing but an API that is provided to you by
• 201:00 - 201:30 Spring and it helps you get rid of various complexities as far as an architecture is concerned so what are the problems that are solved by a spring Cloud well firstly what it does is it reduces the complexity with distributed systems or the complexity that is associated with distributed systems service Discovery becomes very easy and it also helps in load balancing it takes care of redundant code and application development and does help in improving performance so what is the difference between rest and micro Services now you
• 201:30 - 202:00 need to understand this point that micro Service as I've already mentioned is an approach towards software development rest on the other hand it uses this approach and helps you develop applications plus micro Services when you talk about these small individual applications they work very well or function very well Plus it becomes very easy to develop microservices when rest is used for developing these micro services so these two are kind of interdependent but you need to understand this basic difference micro
• 202:00 - 202:30 service is an approach rest is a way of building microservices what are the different types of tests for microservices under quite a few tests I mean if you've ever heard or learned testing to any extent I believe since you all are here for this session you might have heard about basic testing that is manual testing and automation testing and what those things are or at least read about it a little if not do not worry I would be talking about these as well but these are very common terminologies and they're used in almost any kind of testing so let's go ahead
• 202:30 - 203:00 and try to understand them a little more so when you talk about microservices architecture it follows the pyramid law as we move further we'll be discussing this as well so when you talk about pyramid law certain tests they are actually performed at almost every stage and those are at the highest priority of the pyramid that forms the testing pyramid is what I'm talking about so certain tests as I mentioned they have higher priority or not higher priority rather they are implemented lot more times than the other tests those tests
• 203:00 - 203:30 are your unit test basically and to some extent at times performance testing as well but to just to some extent not completely then you have at the second level you'll be having your exploratory tests where these tests are also happening or happen frequently but not as frequently as your unit test and then you have your acceptance test and performance tests now these tests are for the stakeholders that means when you're presenting or giving your end product so these are superficial not
• 203:30 - 204:00 superficial but they actually go ahead and just test the end working of an application so they happen very less compared to the other two tests so these are some of the different tests that are used as far as your micro services are concerned what is coupling I believe we've already discussed this point so just let us move further what is a distributed transaction now you're talking about a number of applications or services so all of these services will commit changes so when you commit changes to a particular client request what happens is you need to make sure
• 204:00 - 204:30 that all the applications are on a similar page so we have something called as think of it as a managing entity that ensures that there is a commitment for a particular service from all the applications or all these services and when that commitment arrives it is then that a transaction is completed and this kind of a transaction is called as distributed Transaction what is an indimportance law and where is it used exactly now when you talk about an indempotence law you have to understand one thing there are certain results
• 204:30 - 205:00 where you would want uniformity that means if there would be a particular application that would execute 10 times but that should not vary my end result that means no matter how many times the application executes the end result should be same each time so to ensure this we have something called as an indimpotence law or that is what it does basically it ensures that uniformity what is a bonded context now when you talk about bonded context you need to
• 205:00 - 205:30 understand this point we are talking about microservices and modularity to give you an example on the organizational level we have different teams working on different things like your marketing team focuses on marketing your product sales team has the job of selling your product you have a development team that develops your product a maintenance team that maintains your product so you'll be having different teams they would be having different concerns and different interdependencies so each of this team
• 205:30 - 206:00 should exist in a single module now same as with the application development as well your each module should have its own independence now this kind of an approach is called as a bonded context or a bounded context that means your application is bounded Within These limits and these are the things you use and this is how you go ahead and proceed with the application or towards your functionality rather what is a two-factor authentication well we are talking about most of the transactions
• 206:00 - 206:30 that we do these days yes we use two-factor authentication but we do not realize that we are using that to give you an example I used a Motorola phone and it has a finger scanner but at times when I use or restart my phone or reboot my phone and I use the finger scanner to unlock my phone it says enter in the password that means I've given in a fingerprint as well but it still needs a second level authentication just to verify that I am the very same person so
• 206:30 - 207:00 next time I enter in the four digit password which I've set and it unlocks this is in a little reverse order normally what we do is we enter in the credentials and then we do all these Biometrics but this is an example of two Factor authentication another example would be your ATM transactions when you've given your credit card details you are actually putting in your credentials that is your card number your name and your CV but when you do enter those details you are expected to also enter the OTP that means what your
• 207:00 - 207:30 card does is it re-verifies that the detail is that you've given are correct and you are the owner of this card and also the number which you've entered and it is registered with your service so this is where the second step of the authentication happens so this kind of an authentication is called as a two-factor authentication what are client certificates now think of it as gateways or passes if you have to go for a movie you would be buying passes or if
• 207:30 - 208:00 you have to go ahead and attend certain concert let me give you another example a better example say for example you visit a certain restaurant or maybe some club now there what you do is you pay in your cover charges right so you are given a band or something which says that for tonight you can go ahead and you can use their services so once you have that band on your wrist or whatever a card or something when you go in you have certain freedom to go ahead and use maybe the dance floor or consume there whatever it is cocktails or food and all
• 208:00 - 208:30 those things so this is what a client certificate is like when when you have a particular application when you have a client certificate you have a digital certificate that tells you that you can go ahead and use a particular client system or you are authenticated to go ahead and use following Services basically what are the types of credentials of a two-factor authentication now we just discussed it with few examples let us just walk through these points quickly now what are the credentials that would be needed something that you know or in simple
• 208:30 - 209:00 words it is nothing but your credentials your card details or your CVV number and all those things something you have here again a part of your credentials that you have and which you can enter and finally you have your something you are this is where they're referring to the fact that if you're using some Biometrics in the example which I gave you where I used my finger basically for the scanning purpose that is what they mean maybe your retina scan or all those things so something you know is your credentials your password and all those
• 209:00 - 209:30 things something you have is your OTP or the value that is generated back to you and something you are is nothing but your bodily scannings and all those things which you use for unlocking so these are the credentials you might require when you talk about a two-factor Authentication okay so the next question is what is the use of pact in microservices architecture now you can think of it as a testing approach what it does is it lets you test your contracts basically now not contracts since you have a provider in microservices and a client
• 209:30 - 210:00 that is using these Services now both these teams are these people they come on terms or an agreement now when you talk about these agreements you are talking about communication between these two and these communications are governed or rather tested by something called as a pact now it is nothing but a testing approach and it is used for testing these communications which I just discussed what is an oauth now when you talk about oauth you are talking about open authorization protocol here you can actually go ahead and use the
• 210:00 - 210:30 Provider Services and to do that you'll have to go ahead and use some third party tools which would let you access those services what is conveys law now this is something that helps you maintain the Integrity of an organization now when you talk about an organization they would be having applications or a particular structure for the applications that are built now if a new system or a new application is to be built it has to be on the similar lines or the guidelines that the organization
• 210:30 - 211:00 has defined to give you an example Coca-Cola makes cold drink cans now when you talk about these golden cans they have fixed dimensions and those have been decided by the company's organization now if they are launching a particular product they might not make the exact same can but what they would do is they would be having certain principles that need to be followed that keeps the other product or the newer product also on the similar lines now this is what conveys law preserves each
• 211:00 - 211:30 time you have a new system it has to be constrained or it is constrained with the properties the organization and follows so this is what Conway's law is as you can see in this image organization has a particular definition as far as your software development is concerned as you can see the organization has a particular approach what conveys law does is it lets you have a system that follows a similar approach and that is what is reflected in the system that is being developed as well so the next question is what is contract
• 211:30 - 212:00 testing now contact testing is nothing but a superficial testing superficial again would be a wrong word but it is a test that does not go deeper or test the complete application now what do I mean by this these are more or less the behavioral tests and these are done just to ensure that the system is working fine or the expected output as far as a system is concerned is up to the mark to give you another example we all appear
• 212:00 - 212:30 for examinations suppose you need to prepare for a particular examination and you maybe prepare for it for say three months duration and then comes in your exam time and you revise it for two days and then you go for the exam and on the day of exam what you do is you just Overlook or walk through the concepts quickly now this kind of an approach when you bring it into testing it is called as contract testing what is end-to-end micro Services testing now this is completely opposite from what we just discussed to give you an example
• 212:30 - 213:00 think of it as your bike servicing basically when you give your bike for servicing there are certain issues that do not occur every time you give your bike for servicing say for example your brake failed completely and your brake wire needed replacement now this is something that won't happen every month but this was an issue this time but there are certain things that happen every month like your oil checking your bike washing tightening certain screws and all those things so this kind of an approach that happens every now and then
• 213:00 - 213:30 has to be done frequently or has to be done end to end this kind of testing is called as end-to-end testing now when you talk about microservices you'll be having quite a few loose ends because you're talking about n number of services bringing them together and fixing in the loopholes can be a problem and end-to-end testing fixes those loopholes well this is something that is little out of context to explain this I'll have to go into something else so I would rather skip this question and move to the next one what is the use of a container in microservices now this
• 213:30 - 214:00 gives you modularity you have your code libraries in a single container your micro services and also the database now this means your application it works independently so this is what a container does it gives you that modularity what is dry in microservices architecture since you're talking about too many applications and too many micro Services there might be a possibility of code redundancy now what happens when the code redundancy occurs well basically what it does is there might be a piece of code which everybody is
• 214:00 - 214:30 writing instead what you do is if you have a particular set of code once you write it you kind of patent it patent won't be a right word but you would create a library out of it and once you have that Library it can be used by others as well now that is what dry stands for don't repeat yourself this ensures code reusability a code that has been created by someone and if it can be used by others let them use it a consumer driven contract now this kind of a contact is used to keep people on
• 214:30 - 215:00 similar pages that means your provider is allowed to set certain set of rules when he is deploying a particular application and the consumer who wants to consume that application when they have this contract they basically try to be on the similar page that means client has a particular set of requests and when the client mentions those requests to the developer or the provider he should adhere by those requests so this kind of an contact is called as consumer driven contract where consumer is made a
• 215:00 - 215:30 priority and accordingly a software is deployed basically what is the role of web restful apis in microservices again rest plays a very important role I believe we've already discussed this point microservices you are talking about independent development and for that rest is a very good approach of web services which can be used and it also provides you with various apis that help you in various other things we discussed something like monitoring or getting real-time analysis and all those things
• 215:30 - 216:00 we discussed spring cloud and all those things right so what restful does is it gives you something on the similar lines it gives you apis that suit the need of your micro services and accordingly you can go ahead and have your micro Services up and running me what is semantic monitoring in microservices architecture now when you talk about semantic monitoring you're referring to the fact that okay let me give you an example again you have your application which is up and running but you still do not know whether it gives you the best output or every module that
• 216:00 - 216:30 is there in your application is working in the best possible way so what you do is you go ahead and generate a pseudo transaction now this transaction it runs through every module and generates an output and when you assure or verify this output and find that all the readings are as you expect it to be then you actually go ahead and deploy that software now this sort of monitoring or testing is called as semantic monitoring how can we do cross-functional testing now when you talk about cross-functional
• 216:30 - 217:00 testing you need to understand what it is first well it is nothing but an approach where let me give you the scenario again first of all you have a client who gives you certain requirements and then he enters in output and tries or expects an output from your application that you build for him but there are certain parameters which the client might not think of or he might enter and you expect output for those inputs as well now while building an application you might not consider every possible faucet as in what kind of
• 217:00 - 217:30 an input the user is going to give in so it is the responsibility of the Builder or the provider rather to ask for these requirements and then accordingly a test is taken care of to test your application for these kind of inputs as well now this kind of a test is called as your cross functional test how do you eradicate non-determinism in tests now basically these are different approaches first thing you need to understand is is what are non-deterministic tests now
• 217:30 - 218:00 when you talk about non-determinism you're talking about a series of inputs for which you may not know what the exact output is now in this case what happens is when you're generating a particular output the output might vary each time you enter in a particular input and there are certain outputs only that are correct not all of those so what do you do in these situations because this is a very non-deterministic situation where you do not know what is happening with you so in that case what you do is you take in various approaches
• 218:00 - 218:30 one of those approaches is quarantine now what happens here is suppose you have maybe say 100 outputs or results out of which there are 20 which are not correct so what you do you put the 18 in one cluster and 20 in the other cluster and then you test them differently a synchronous approach you might come across tests where asynchronous messaging is used now in this case the output that is generated may be different because a synchronous
• 218:30 - 219:00 messaging is something that is little different here the user does not wait for your reply and the output that is generated might be a little different so again what you do is you use pseudo applications or sudo inputs for your so called asynchronous requests and those are dealt with differently remote services and isolation again here too you use something called a stub or those are predefined inputs or predefined models that can be used as we move further we'll be discussing that as well so you'd have a clear understanding of
• 219:00 - 219:30 these terms as well so yep remote services and isolation again they can be dealt with determinism or non-determinism rather but how do you deal with it you use something called as your steps so as we move further let's discuss steps and you can relate to these terms as well time now time can be a constraint because you are talking about applications that run for different times but yes a pseudo time again is generated for certain applications and the non-determined is something that can be taken care of so what is the difference between mock or a
• 219:30 - 220:00 stuff for microservices test as I've just mentioned we have something called as a stub now what happens in a stub basically well you need to understand this thing a stub is nothing but a dummy object now this is used for testing purposes it would have a preset or a predefined set of behavior and that individual or particular behavior is something that it would Implement each time it is used now in cases where you do not want to go away from normal behavior you have this predefined step
• 220:00 - 220:30 that can be used mock is similar to it but it has a set of predefined rules this is where it is different it has a set of predefined rows that are set initially it goes ahead and it functions accordingly okay so the next question is what is Mike cohan's test pyramid in microservices now when you talk about the pyramid there are three levels in this pyramid so first level will have unit tests now these are tests that happen for individual units you have service tests now these tests they test
• 220:30 - 221:00 the complete service that is there and then you have your end-to-end tests which are for the complete development or architecture now as per the law the tests in the first layer that is for unit tests they are the maximum service tests are lesser than what unit tests are but more than what end-to-end tests are and finally we have the end-to-end test now here these are the least compared to the about two what is the purpose of a Docker now Docker is nothing but a container basically that
• 221:00 - 221:30 means it gives you a containerized approach and it also ensures virtualization at the operating system level now it has three components you have your Docker client your demon or your server basically and then you have of your Docker containers and these containers would contain your complete micro service or a complete application you'd have your database there should have your interdependencies and also the complete functioning of that microservice so when you need a containerization approach you can use something like a Docker which is a very
• 221:30 - 222:00 wonderful and a popular technology to have what is Canary releasing now you are talking about an application which might be used by lacks of people or maybe millions of people in that case when there is a new version you cannot just go ahead and launch the complete version for everyone who is around what you do is you launch it for a certain set of people and when it works perfectly then it is launched to the entire segment and this kind of an approach is called as Canary releasing
• 222:00 - 222:30 that means you release a particular software update or version to a specific set of people that's it what do you mean by continuous integration we read something about dry that is do not repeat yourself this is what continuous in integration is also about first the code that is generated it is saved in the form of libraries so that others can use it and there is a continuous integration of your system that means even if there's an update it is recorded and it is released so that others can
• 222:30 - 223:00 refer it if there's an improvement it is updated and it is released that means throughout the lifecycle of your software there is a continuous integration and updation what is continuous monitoring it is similar to continuous integration but this deals with monitoring now when you talk about continuous monitoring you are talking about monitoring in every aspect of your application almost everything is monitored and taken care of what is the role of an architect in a micro service architecture all the activities which we actually discussed are all the questions which we discussed now that is something
• 223:00 - 223:30 an architect has to plan it is similar to building a house now there you have an architecture or an architect who takes care of the construction part here the architect needs to take care of the software development part his responsible for creating the blueprint or the design he zones out all the components or plans where all the components should reside and how they should work whether they are mutually cohesive and how Loosely coupled are they he's also responsible for deciding or helping plan what tools to use where
• 223:30 - 224:00 plus there's technical governance which he needs to take care of so these are some of the roles that an architect takes care of can we create microservices as state machines well the answer is yes definitely you can create State machines or microservices as state machines why because we are talking about individual applications you have your individual databases and since you have a single architecture or a uniquely defined architecture for each micro service and it is smaller in size you can go ahead and have a state machine for each individual micro Service as
• 224:00 - 224:30 well so this brings us to the last question of today's session that is what is reactive extensions now when you talk about reactive extensions these are an approach which lets you collaborate your results so what they do is they bring in or collect all the results by using multiple services and then they combine these results are compile these results together to give you a combined effect and there is a short abbreviation that is used for it which is called as RX so
• 224:30 - 225:00 yes this is what a reactive extension is as far as this session goes I believe we are done with 50 questions and this is where we have to rest our session I hope you all had something nice and new to learn and I hope to see you all again thank you I hope you have enjoyed listening to this video please be kind enough to like it and you can comment any of your doubts and queries and we will reply them at the earliest do look out for more videos in our playlist And subscribe to edureka channel to learn
• 225:00 - 225:30 more happy learning