The aim of this video is to provide you with a brief overview about microservices and monolithic architecture, along with their benefits.
- [Instructor] Hey, let's start our first section on Solution Approach using New Architecture Paradigm Microservices. In this section, we'll cover Microservices and its brief background, Monolithic architecture and its limitations and Monolithic architecture benefits, and benefits of Microservices and its design. So let's move forward.
So, first we'll discuss the Microservices and its background. So here you can see like first we'll discuss the Enterprise architecture evolution and then, its overview. So let's move to the architecture evolution. This diagram is very simple, you can see the Mainframe Computing which was very popular in 1980's. And then, in Mainframe Computing, you have one server which is a Mainframe server and then, you have many clients which we call the workstations.
So, everything is being processed on the Mainframe server. So, opposite of that is Client-Server Architecture which came after we had the Internet. So, here I'm referring the end here because here we will have a separate (mumbles) for database. Then we will have for business logic, the web application and there are many clients. So, the simplest example is equity trading system where you have the servers in the stock exchange and then, you have multiple clients who could be on your desktop application or your web application and then, later on, the next one came, the new one, Service-oriented architecture.
Service-oriented architecture became very popular in 2000 and all the enterprise applications were being developed using it. Now, it's very simple; now, since we are discussing Microservices, obviously, this is the new hard architecture style which it's being used across. So, let's move to Microservices Overview. So, the first question comes to the mind, is it something new or existing? So, yeah, there is no way to guess, and it is not something new, it has been used for quite some time.
(mumbles) a Google tool which was being used in the data centers, so that it was being used in 2003 or around, so it was a tool which was built around PC infrastructure and it was being used to connect number of Microservices within across the data centers, so Microservices; it's not something new; then, who coined it and from what time it was called Microservice, so let's move to the next slide, so as you can see on the slide, Martin Fowler in 2011; he shared in 2009 in Venice there was a workshop and many architects were part of it and they were discussing the similar architecture style and they were referring it as Microservice and in the same conference in 2012, they named it Microservices, so that is (mumbles) origin.
Let's move to the definition. We'll first discuss the Adrian who was the Netflix architect, so it's a fine grain SOA and the most important part is component and another thing is loosely coupled and bounded context. Why? So, first loosely coupled. So, if every service has to be updated at the same time, it is loosely coupled, so, let's say, you have four, five services and you just updating one of the service and it has no impact on another four services, so it means it is a loosely coupled.
Then, bounded context are given of Domain Driven Design. He simplified it in terms of bounded context. Why? If you have to know too much about surrounding services, you don't have a bounded context, so that's the reason of Microservice which is a component; independent component is something which have the bounded context and we'll learn more about the bounded context once we go to the Domain Driven Design section and similarly, Mike also mention the small is beautiful, so this is something which is for UNIX, but it is more relevant for Microservice also.
Then, next definition is from Tony and the most important part is lightweight process; each Microservice have its own process, so that is very important concept for Microservice and thought he's talking more about (mumbles) we could have another mode of communication for APIs like even base system; The next one is monolithic architecture, so after the brief background of the Microservices, we would like to know why the new architecture evolve and it has become so popular.
Is it only the hype or something else? So, for that, we need to understand the monolithic architecture, so here, we'll go to the four points. Traditional monolithic architecture, then, Monolithic design with services. Then, benefits of monolithic, shortcoming of monolithics or we could say in other way, it represents the benefit of Microservice, so let's move to this next slide and here you must be feeling very familiar with this diagram, because it represents a quite simple monolithic design, so this blue box is very important and it represents the fetch chart; it could be not only chart; it could be any archive var or (mumbles), so here, what we are having basically everything is inside this blue box, which represents the archive, so we have our presentation logic, our application logic, business logic (mumbles) also; all the layers inside the same archive and it is connected with the database, so this is a traditional monolithic design and then, we can move to the next one where we'll discuss the monolithic design with services, so you could see like the blue box is still there; you may have one or two APIs outside this blue box, but, basically, their design is you have presentation logic and they are different layers of APIs, so, basically, each API here representing a service and then, we have database that could be same database for all the services or that could be one or two, but this was more about monolithic, so it has been in the market for quite a long time, so there could be some benefits, so let's discuss first about the benefits or monolithic.
Monolithic; the biggest benefit is it's code reusability. How many times we could have seen like whenever we walk in monolithic, a code written by (mumbles) which is already available and simply we use it, so it increases the productivity in terms of writing a code which is common, so this is a biggest advantage of monolithic.
The next one is minimal overhead, so you have single archive; everything is inside that (mumbles) archive; you have a database which could be used by many applications, so in such case, you have minimal overhead as far as development process is concerned. Then, the next one is easy to extend feature in APIs. That's the reason whenever a small team is told to come and forced to start with monolithic and then, once you have (mumbles) of it, you can divide it into the Microservice, so the idea is monolithics are very good if you have to build the features quickly whenever business requires, so that is something where monolithics change (mumbles).
So far, whatever we discuss about the benefits, so let's discuss the shortcoming, so why we are discussing the shortcoming. It could be the point where Microservice changes (mumbles), so in other way, it could be benefit for Microservice. Multi-dimension scaleability. You cannot increase the scaleability of monolithic application horizontally, so let's say, if you have four APIs: restaurant, table, reservation; you can set the booking and then, use (mumbles) so on and so forth; any table reservation system, for example, then, you cannot increase only service or API where you have the maximum payload.
Let's say it's a user; then, you cannot increase this user, but if you have Microservice-based system, because it is componentize, you can easily have the horizontal scaleability for the user API; for this something which is being used highly as compared to others. The next one is rollback of release in case of failure. So, this is something which was quite (mumbles) whenever you have some serious problem in your release you have to roll back or you have to extend the release time x, so here, Microservice give you some flexibility, because it is based on independent components, so wherever if you have any failure, you can just try a patch on that service or you have a release which is not impacting the other components at all and another problem which was there for monolithic is you cannot adopt a new technology very easily, because you have already decided the technology (mumbles); the product is already in production; it's very difficult to even upgrade the technology So far, we (mumbles) about having a new technology, but in Microservice-based system, because the complete system is divided into components and the most important thing is independent component, so you can any time, based on the requirement and the business are technological; you can change the technology of any component at any time.
Also, even if some new development is done the component, you can have different technologies for different components; failure cascade; this was something which was very; I would say it was a limitation in monolithic, so let's say you have a failure in any specific part of your application and because some monolithic application is not designed properly, it will cascade the failure and your entire system may get down, so to avoid such thing, in Microservice, we have the circuit breakers, so, this is something; a drawback for monolithic.
Now, since we are having the incremental development, so Microservice system or Microservice-based system are well suited for agile and the last one is easy maintenance; maintenance in terms of because its independent components; you can fix it and you're at least worried about the component, because it's waking dependently; obviously, you need to have your all integration to end scenarios in place. Another thing is if you have a new member which is quite easy for her to onboard, because initially one has to learn about the component and the time they can learn about the complex system, so it's something which is very unique for Microservice-based system, so, so far, we have discussed the monolithic design and some another way, we discuss about the monolithic shortcomings and advantages of microservices, so here, we'll discuss the Microservice design four parts; simple design, then, we will discuss the high level design; we'll discuss about the nano services and tera services; at the end, we'll discuss about the challenges, which is a big and very important while implementing the Microservices, so let's move to the next section, so as you can see like if you just focus on this component which is a part of Microservice design.
It's a very simple design, but if you just focus on this internal part, you could see it is very similar to monolithic components, so here, you could see like this blue bound represents the Microservice-based system. Here, we are having API gateway and then, we have three Microservices which represents API one, API two, API three, so if is, let's say, online table booking system, then, we can say: use one or user service, restaurant service and booking service.
All of these are components and the major highlight is database, so each component or each service is having their own database, so this is something very unique in Microservice-based system, so this is as we have mentioned; it's very simple one, so let's move to the next one which is high level, so here, you could have a very good overview about the Microservice systems, so, again, we are having three APIs representing three separate components of Microservices and we are having different components which are very important for Microservice-based system.
We need service discovery in residuation where each service will (mumbles) and other services can discover, so here the important thing is we are referring Netflix OSS components, so (mumbles) all are part of Netflix OSS, so Netflix OSS is open software suit for Netflix which provides all the features which is required for Microservices, so eureka server as you can see; it is basically for service discovery (mumbles); then, you have a Hystrix which is circuit breaker and this what we discussed about failure cascades and Ribbon for load balancer; then, there is this Zuul for A server or API gateway and there is a tool for monitoring where (mumbles) dashboard and it makes use of turbine to get all the valuable feedback about the running Microservices.
We will discuss all of this while implement the Microservice. Now, let's move to the nano and tera services. This is something which are more related with services, Microservices, so these are different forms of Microservices. If you really use the size of Microservice; I mean to such an extreme so it's very small, then we can say it's nano and opposite of that if you increase the service size of bigger, bigger and bigger, then, it is a tera service, so this is something very simple, but if it really want to discuss about the nano service, so nano service is an empty pattern, so we need to keep in mind while designing the Microservice, we should not convert the Microservice into nano service, so basically, what is nano service? Nano service is an empty pattern where a service is too fine green, so fine green to that level (mumbles), for example, like communication maintenance and so on; outweigh its utility.
Then, it's a nano service, so we need to keep in mind we should not use nano services at all, but tera services; tera services are opposite of micro services; a service that requires two terabyte of memory or more than that, so the advantage of tera service is those are completely remain in the memory, so, basically, it minimize infrastructure cost; that is the biggest advantage; for example, if you are using-quad core processor, then the same work if you use tera services, basically, which internally uses the in-memory database and quad-core can be replaced by the dual-core.
This is as good as it is, so this is about nano services and tera services. Let's move to the next slide. Challenges. So, challenges; it's very important and these are the focus video while developing the Microservice, so your success and failure depends on these six things. The first one is flow. If you're developing a small Microservice-based project, it's okay, but once you develop enterprise or a big Microservice-based project; for example, like Netflix, anything else than the flow; it's very difficult to identify the flow from one request which passes from several Microservices, so this is something; a challenge; like in monolithic and simply use a SQL diagram which moves from UI to the database.
In Microservice-based system, it is a challenge. Configuration; now, typical Microservice-based system may have many; 50 or more services; 100 of Microservices. If it is a big project, it could have 500 Microservices. Then, in such case, configuring all those 500 Microservices are very challenging and difficult, so you have some tools; you can use it; then, monitoring; so, obviously, in monolithic, if you have few instances, this monitoring then, on your (mumbles) network and this identifying the load and seeing all the metrics is difficult and think about once you have 50 or more Microservice and then multiple instances, so this is a big challenge.
Logging. You have hundreds of Microservice. Each may have one or more log file and you want to not only look into the all log file you have to trace where a request moves from one micro service to another micro service, so it's a challenging projection. In monolithic, most of the things are inside same continuum or same fracture, but in Microservice, the transaction could be between the multiple Microservices, so establish that perfect transaction is a challenge.
Automation. So, if you don't have automation or if you don't automate your process for continuous integration and delivery, then, it's very difficult to have a successful Microservice-based system, so automation is the key for having a successful Microservice-based router or service. Let's move, so let's see what we have cover, so we have covered Microservice and brief background.
We discussed about the evolution from main frame to Microservice; then, we discussed about the monolithic architecture; we discussed about its limitation and we also discussed about the Microservice flexibility, benefit and challenges, so what you can do from this point onwards? So, you can explore the projects you have developed so far, so you can compare their design; again, identify the pitfalls; whatever project you have worked; whether it was monolithic or (mumbles); then, again, list all the challenges you have faced while developing any system, especially about monolithic.
Thank you; happy learning.
Note: To get the best results from this course, you should be familiar with the Spring Framework.
This course was created and produced by Packt Publishing. We are honored to host this training in our library.
- Writing sample tests
- Domain-driven design
- Strategic design
- Wrapping controls and pages
- Complex cases for pages and elements
- Testing microservices