34,79 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Cloud-based applications have been increasingly in demand, and this has caused a shift from monolithic to microservice applications. With the help of Java EE 8 Microservices, you‘ll get to grips with the components of Java EE 8 and understand how they are used to implement microservices. This book explains how a monolithic application is transformed into a microservice application, then helps you connect it in a traditional way and use advanced approaches for asynchronous communication. Once you have learned the basics, you’ll explore advanced topics to make your microservices robust, scalable, and secure. Microservices form distributed applications, and by the end of this book you’ll have discovered how to develop, pack, ship, and support distributed applications using Java EE.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 277
Veröffentlichungsjahr: 2018
Ähnliche
.
Java EE 8 Microservices
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Commissioning Editor: Aaron LazarAcquisition Editor: Sandeep MishraContent Development Editor: Digvijay BagulTechnical Editor: Aniket IswalkarCopy Editor: Safis EditingProject Coordinator: Ulhas KambaliProofreader: Safis EditingIndexer: Pratik ShirodkarGraphics: Tom ScariaProduction Coordinator: Deepika Naik
First published: December 2018
Production reference: 1271218
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78847-514-3
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools, to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and videos from over 4,000 industry professionals
Improve your learning with Skill Plans designed especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
Packt.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.packt.com and, as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the authors
Kamalmeet Singh got his first taste of programming at the age of 15, and he immediately fell in love with it. After spending over 14 years in the IT industry, Kamal has matured into an ace developer and a technical architect. He is also the co-author of a book on design patterns and best practices in Java. The technologies he works with range from cloud computing, machine learning, augmented reality, and serverless applications to microservices and more.
Mert Çalışkan is a coder living in Ankara, Turkey. He has over 10 years experience in software development in the architectural design of enterprise Java applications. He is an open source advocate for software projects such as PrimeFaces, and has also contributed to and been the founder of various others. Currently, he also works as a consultant for Payara Application Server. He is a co-author of PrimeFaces Cookbook, by Packt Publishing, and a co-author of Beginning Spring, by Wiley Publications. He is an occasional author for Oracle Java Magazine. He is the founder of AnkaraJUG, which is the most active JUG in Turkey. In 2014, he was recognized as a Java Champion for his achievements. He is a part-time lecturer at Hacettepe University on enterprise web application architectures and web Services. He shares his knowledge at national and international conferences, including JavaOne 2016, JDays 2015, JavaOne 2013, JDC 2010, and JSFDays'08. You can reach Mert via his Twitter handle: @mertcal.
Ondrej Mihályi is a software developer and consultant specializing in combining standard and proven tools to solve new and challenging problems. He's been developing in Java and Java EE for 9 years. He currently works as a support engineer and a developer advocate for Payara Services Ltd. As a scrum master and experienced Java EE developer, he also helps companies build and educate their development teams. He loves working with the Java EE community and is a contributor to a number of open source projects in the Java EE ecosystem, including Payara Server and Eclipse MicroProfile. He's a co-leader of the Czech Java user group and talks at international conferences such as JavaOne, Devoxx, GeeCon, and JPrime.
Pavel Pscheidl is a man of many interests. He works as a researcher in the faculty of informatics at the University of Hradec Králové. Pavel, with his focus on statistics and agent-based simulations, currently specializes in smart systems and highly parallel simulations. In addition, he is usually to be found developing for various big companies as a consultant. Pavel enjoys the beauty and simplicity of Java EE in many projects on a daily basis and does his best to pass on his knowledge by teaching students, attending conferences, and giving talks. He is also a passionate blogger and Java EE article writer.
About the reviewer(s)
Aristides Villarreal Bravo is a Java developer, a member of the NetBeans Dream Team, and a Java user groups leader. He lives in Panama. He has organized and participated in various conferences and seminars related to Java, JavaEE, NetBeans, the NetBeans platform, free software, and mobile devices. He is the author of jmoordb and tutorials, and he blogs about Java, NetBeans, and web development. Aristides has participated in numerous interviews on sites about topics including NetBeans, NetBeans DZone, and JavaHispano. He is a developer of plugins for NetBeans. He is the CEO of Javscaz Software Developers. He has also worked on Developers of jmoordb.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Java EE 8 Microservices
About Packt
Why subscribe?
Packt.com
Contributors
About the authors
About the reviewer(s)
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the example code files
Conventions used
Get in touch
Reviews
From Monoliths to Microservices
What is Monolith design?
The challenges associated with Monolith design
Service-oriented architecture
Understanding Microservices
Advantages of Microservices
Challenges with Microservices
Summary
Creating your first Microservice
Setting up the Development Environment
Environment installation
Installing Java Development Kit
Installing Apache Maven
Downloading development tools
cURL
Postman
Creating the project with Maven
Your very first Microservice
A Java EE Microservice
Coding the Microservice
Configuring the Microservice
Code summary
Running the Microservice
Building and running the Weather Microservice
Invoking the Microservice
A Spring Boot Microservice
Creating the project with Maven
Coding a Spring Boot Microservice
Building the Spring Boot Weather Microservice
Running the Spring Boot Weather Microservice
Summary
Connecting Microservices Together
Building a client
Using third-party reactive frameworks
Connecting two Microservices together
Creating and pooling web targets
Making Microservices discoverable
Snoop
Running Snoop and registering our service
Consuming registered services
Eureka
Installing Eureka Server
Registering the service
Discovering and invoking the service
Summary
Asynchronous Communication for Microservices
Speeding up services with the Reactive API
Collecting results of multiple parallel calls
Completing a REST response asynchronously
Asynchronous exceptions
Specifying and handling asynchronous timeouts
A complete reactive REST service
Simplifying the code with a third-party reactive framework
Streaming responses with SSE
Building an asynchronous service
Invoking the SSE service
Invoking the SSE service from JavaScript
Building an SSE Java client
Automatically reconnecting of SSE clients
Two-way asynchronous services with WebSocket
A quick comparison between HTTP and WebSockets
Decoupling services with message-oriented middleware
An example of message-oriented middleware
Summary
Path to Robust Microservices
Building for failure
Isolating the failure
The bulkhead pattern
Stateless services
The robustness principle
Handling the failure
Asynchronous communication
Fail fast
Timeouts
Circuit breakers
A circuit breaker code example
Fan out and fastest response
Recovering from failure
Preparing for failure
Summary
Scaling Microservices
What is scalability?
Microservices and scalability
Stateless versus Stateful scalability
Scaling on the cloud
Going serverless with microservices
Scaling databases with Microservices
Scaling Microservices with caching
Summary
Securing Microservices
Securing Microservices with JWT
Anatomy of a JWT
How does JWT work for Authentication?
Java Security API – JSR 375
The HTTPAuthenticationMechanism API
Basic HTTP Authentication
Form-based Authentication
Custom form-based Authentication
Identity Store
Built-in and Custom IdentityStores
The security context API
Spring Security with Spring-Boot-based Microservices
Configuring Spring Security with the In-memory realm
Configuring Spring Security with the database realm
HTTPS – The Secured Protocol
Summary
Monitoring Microservices
What is monitoring and why is it required?
Monitoring Microservices
Understanding core concepts and terms
Taking a closer look using an example
Creating the example services
Monitoring Microservices with Zipkin
Case 1 – service is unresponsive
Case 2 – service responding slowly
Tools for monitoring Microservices
Prometheus for monitoring and alerting
Elasticsearch, Logstash, and Kibana (ELK)
Considering more tools
Summary
Building, Packaging, and Running Microservices
Introduction to Java Packaging
Understanding Archives
Fat packages
FatWAR packaging
FatJAR packaging
Java EE MicroService solutions
OpenLiberty
The OpenLiberty Maven plugin
Configuring OpenLiberty
The Weather Microservice with OpenLiberty
The Gradle plugin
WildFly Swarm
The WildFly Swarm generator
The WildFly Swarm Maven plugin
HollowJAR
Payara Micro
The Payara Micro Maven plugin
The Payara Micro UberJar
The Deployment Architecture for Microservices
Summary
Documenting and Testing MicroServices
Documenting Microservices
Swagger
APIdoc
Additional Documentation Frameworks
Testing Microservices
Unit testing
Integration Testing
Service Testing
End-to-end testing
Levels of Testing
Summary
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
Microservices is one of the hot topics in today's IT world. Though the topic is popular, it is not perfectly understood the majority of the time. Everyone seems to have a different understanding of the concept. This book tries to simplify the concept and discuss it in a manner that everyone can understand. It talks about the various basic concepts that each microservices-based application should implement.
The book starts with an introduction to microservices, and explains why it is de rigueur. It dwells on the existing challenges being faced by the software industry, and how microservices can help us to solve them. The book focuses on the Java-based implementation of microservices, and will help readers to explore different ways of creating them.
The book covers core concepts, such as creation, scaling, securing, monitoring, building, deploying, documenting, and testing microservice-based applications. With each of these concepts being covered, the book provides best practices that can be followed by developers.
Who this book is for
This book is for anyone who works with microservice-based architecture, or who would like to learn about it. It covers basic concepts, such as understanding microservice-based architecture and various ways of implementing a microservice in Java. Then, it moves onto advanced topics, such as how to create communication channels among microservices, managing scalability and security in an application based on microservice architecture. The book also covers topics on monitoring, deploying, documenting, and testing a microservice-based application.
What this book covers
Chapter 1, From Monoliths to Microservices, covers a brief history of software development, starting with monolith application design, through to microservice-based design.
Chapter 2, Creating Your First Microservice, introduces the tools that will be used throughout the book, followed by a hands-on exercise involving Microservice implementation.
Chapter 3, Connecting Microservices Together, discusses how microservices can interact with one another.
Chapter 4, Asynchronous Communication for Microservices, focuses on asynchronous communication between microservices, and how can it be implemented.
Chapter 5, Path to Robust Microservices, discusses how, in the world of microservices, the performance and overall availability of one service may affect the performance of other dependent services. This chapter focuses on developing applications for survival in the real world.
Chapter 6, Scaling Microservices, demonstrates how to design applications to take full advantage of the Microservice architecture when optimizing the application for unexpected loads.
Chapter 7, Securing Microservices, covers the ways of securing Microservices by enabling authenticated and authorized clients to consume the endpoints in question.
Chapter 8, Monitoring Microservices, discusses how the reader is going to learn how to gather and view data regarding application performance and health over time.
Chapter 9, Building, Packaging, and Running Microservices, examines the various methods of building, packaging, and distributing Java EE Microservices.
Chapter 10, Documenting and Testing Your Microservices, deals with various tools that are available for documenting and testing microservices.
To get the most out of this book
Readers with prior experience of Java stand to gain the most from this book. It is recommended that readers should try to explore and play around with the code examples provided in the various chapters.
Download the example code files
You can download the example code files for this book from your account at www.packt.com. If you purchased this book elsewhere, you can visit www.packt.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Log in or register at
www.packt.com
.
Select the
SUPPORT
tab.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box and follow the onscreen instructions.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR/7-Zip for Windows
Zipeg/iZip/UnRarX for Mac
7-Zip/PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Java-EE-8-Microservices. In case there's an update to the code, it will be updated on the existing GitHub repository.
We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Conventions used
There are a number of text conventions used throughout this book.
CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "Mount the downloaded WebStorm-10*.dmg disk image file as another disk in your system."
A block of code is set as follows:
html, body, #map { height: 100%; margin: 0; padding: 0}
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
[default]exten => s,1,Dial(Zap/1|30)exten => s,2,Voicemail(u100)
exten => s,102,Voicemail(b100)
exten => i,1,Voicemail(s0)
Any command-line input or output is written as follows:
$ mkdir css
$ cd css
Bold: Indicates a new term, an important word, or words that you see on screen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Select System info from the Administration panel."
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packt.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in, and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packt.com.
From Monoliths to Microservices
Welcome to the exciting world of Microservices! In this chapter, we will try to understand what Microservices are, how and why we are shifting from age-old practice of creating a giant monolithic application to Microservices, and the advantages and challenges of using Microservices.
In this chapter,we will try to answer some of the important questions regarding Microservices, and then in the rest of the book, we will take a deeper look at things such as the creation of Microservices, security, communication, monitoring, and documentation.
In this chapter, we will cover the following topics:
What is Monolith design?
The challenges associated with Monolith design
Service-oriented architecture
Understanding Microservices
The advantages of Microservices
The challenges associated with Microservices
What is Monolith design?
If you have been in the industry for more than six to eight years, monolithic applications are not new to you. Even today, a lot of old applications that are in production follow monolith design architecture. Well, let's try to understand what a monolith design is and what the word monolith means to you.
If you look at these definitions and try to apply them to a software application, it will be clear what we mean when we say the application follows a monolith design. We are talking about the following characteristics:
Single
: In the case of an application, we are talking about a single piece of code or a deployable. An application that can and should be deployed on a single machine.
Indivisible
: We cannot break the application down; there is no easy way to divide the application code or deployable.
Slow to change
: This is more of an implication of monolith design. It is a well-known fact that changing a small piece of code is easier than a big, monolith code, especially since you don't know what implications such a change will have.
The following diagram shows the architecture of a monolithic design based on a Java application:
We can see the whole application is deployed as a single deployable, that is, a WAR or EAR file. The design looks very simple, but it does hide a lot of complexities. The single deployable, in this case, a WAR file or EAR file, might have a lot of functionality implemented.
Let's take an example: say we have to implement an application for our company where we can manage data for employees. Let's call this the Employee Management System, which should be able to handle core requirements such as maintaining employee data, project data, hierarchy, attendance, leave data, salary, and financial information. In addition to these core requirements, our application would also handle additional requirements, such as reporting needs for management.
In a monolith design, we code all this functionality and build it into a single deployable. If you have been in the software industry for more than 10 years, you have probably seen and worked on some applications that follow this design. The design has been good for small and simple applications, but as the complexity of the application increases, it gets challenging to manage a monolith design.
The challenges associated with Monolith design
The following challenges make the monolith design unsuitable for large applications:
Huge code base
: As we are developing the application as a single unit, everything is placed under a single code base. In our previous example, we have all the Employee-Management-related functionality in a single code base. So, even if we are making a small change, such as updating a tax slab for employee salaries, we have to take the whole code for our Employee Data Management project and build the whole application instead of just the tax-related part.
Testing
: As the application is managed as a single unit, we need to test the whole application, even if a small change is made, to make sure there are no integration or regression issues.
Availability
: Let's say that, while updating an employee data report, a developer introduced an error that caused the system to run out of memory, which will bring down the whole system. So a report that actually might not add too much value to the system and may be used rarely by users has the capability of bringing down the whole system.
Scalability
: The code is deployed as a single unit, hence we can only scale the application as a whole, making it a heavy operation. For example, if we just need to execute multiple instances of salary processing on pay day, we cannot do that in isolation; and we need to scale the whole application by providing more hardware firepower (vertical scaling) or make copies of the whole application on different machines (horizontal scaling).
Inflexible
: Say we need to create a special reporting feature and we know a tool or framework is available in a different language than we use. It is not possible in a monolith architecture to use different programming languages or technologies. We are stuck with the original choice, which might have been made years ago and is not relevant anymore.
Difficult to upgrade
: Even a small decision, such as moving from Java EE 6 to 8, would mean that the whole application, along with all the features, needs to be tested and even a small problem would hinder the upgrade, whereas if we were dealing with multiple small services, we could upgrade them independently and sequentially.
Slow Development and time to market
: For these reasons, it is difficult to make changes to an application with a monolith design. This approach does not fit well in today's agile world, where customers need to see changes and modifications as soon as possible, rather than waiting for a release that takes years.
We have talked about some of the challenges of monolith applications. As the application size grows and it becomes complex, it is not possible to manage a monolith application easily. Due to these challenges, the industry has explored different approaches to manage applications, with Microservices being a very popular solution.
Service-oriented architecture
Before moving to Microservices, it is important to understand what Service-oriented architecture (SOA) is. SOA is the base on which Microservices are built. As the name suggests, SOA is about services. With SOA, we try to visualize and design the application as a combination of services that can talk to each other and to the end user, and fulfill the user's requirements.
If we go back to our Employee Management System example, we can try to visualize the application as a set of different services:
Employee Data Management
Salary Management
Project Data Management
Attendance and Leave Management
Reporting Management
Based on our needs, we can divide the application into various services.
The following diagram should help us to visualize our application:
Again, we do not need to get into complex decisions at this point, such as whether we should deploy these services as a single application or keep the data in a single database. Instead, we would like to emphasize the core idea in this section. The base of SOA is trying to think and visualize your application as a set of different services rather than a single, monolith deliverable.
Why does breaking the application into services help? A simple example is when we need to make changes to the code for salaries, the developer does not need to worry about what is happening in Employee-, project-, or attendance-related code. Also, if we were to get an error while generating a report for a manager, we would know we need to start looking for a problem in the reporting service. While testing, we will focus on only one aspect of the system. So the code becomes easy to manage and maintain.
Once we understand SOA and start to think of our application as a group of services, we can take the next step and move toward a Microservices-based architecture, which we'll discuss in the next section.
Understanding Microservices
Microservices are not a completely new concept. In the past, there have been many attempts, such as EJBs,Remote procedure calls (RPC), and implementations of services through SOAP, that aimed to reduce dependencies among various application components. Let's look at a formal definition to set the context and then we will try to understand it in detail:
-http://microservices.io/
In the previous section, we discussed SOA. Microservices are the logical next step, where we extend the SOA and start thinking about dividing the services at a granular level. As the name suggests, we divide our services down to a Micro level when we are talking about Microservices. The next most important aspect is to think about these Microservices as independent entities that can be developed, tested, deployed, and managed as complete sub-applications in themselves.
If we try to visualize our previous example of the Employee Management System in terms of design, the following diagram should demonstrate a Microservices-based implementation:
Let's take a look at the design and how is it different from our previous SOA approach. First, notice that we have divided our services at a granular level. For example, we are supporting Excel and PDF-based reporting, but the actual generators need not be part of the reporting service. The reporting service should only be responsible for generating data, but how the data is represented should not be part of this service. An additional advantage it gives us is that, if in future, we want to support other formats, say a Word DOC report, we don't need to touch any of the existing code; we just create a new service, say Word Document report generator, and plug it in. So we can say that a Microservices-based architecture is easy to extend and maintain.
As we have divided the application into smaller services that can be managed independently, we also talk about smaller teams and decentralized management. Each team can take independent decisions on the design and technology stack they want to use, and hence there is no dependency on other teams. Each service can be easily tested independently.
Another thing you might have noticed is that each service is deployed independently. Well, this might not be the exact scenario and you might deploy multiple services on the same machine, but the idea is that you should have the capacity to deploy each service independently.
Though we have not looked at the data storage part, ideally, each service will manage its own data. There should be a single point of managing one data entity. This helps in the decentralization for data, which helps with easy scalability and maintenance.
Communication between the services is another important aspect you should consider when choosing a Microservices-based architecture. We need to decide whether the communication needs to be synchronous or asynchronous, through REST, Queue-based, or some other communication medium. A well-architected system will be fault-tolerant, as a failure in no single service can bring down the system as a whole, so there is no single point of failure.
There are no fixed, industry-wide set of rules to follow for a Microservices-based architecture. This causes a lot of confusion, as well as flexibility. But to keep it simple, let's take a look at some of the common characteristics of a good Microservices-based architecture:
Decoupled architecture
Independent deployables
Decentralized data
Smaller code bases and teams
Decentralized management
Fault-tolerant
Next, let's take a look at some of the advantages and challenges that can be expected when using a Microservices-based architecture.
Advantages of Microservices
Now that you're comfortable with the concept of Microservices, let's take a look at the advantages they provide, which has made them so popular over the last few years. We already discussed the challenges that come with a monolithic architecture. Most of the challenges of Monolithic applications can be handled by the use of a Microservices-based approach. The following are some of the advantages of a Microservices-based architecture:
Easy-to-manage Code
: As we are able to modularize and divide our huge application code base into various Microservices, we are not dealing with the whole application code at any point in time.
Flexibility of choosing the tech stack
: As every Microservice we create is potentially a separate application in itself with a different deployable, it is easy to choose a technology stack based on need. For example, if you have many Java-based services in an application, and a new requirement comes in which you feel can be easily handled by using Python instead of Java, you can go ahead build that service in Python, and deploy it without worrying about the rest of the application.
Scalability
: As every Microservice can be deployed independently, it is easy to scale them without worrying about the impact on others. For example, let's say we know the reporting service is used heavily at every end of a quarter
–
we can scale only this Microservice by adding more instances, and the rest of the services remain unaffected.
Testing
: Unit testing, to be more specific, is easy with a Microservices-based approach. If you are modifying the leave-management service with some new rules, you need not worry about other services, such as Employee Project Management. In the worst case, if your leave-management service breaks down due to faulty code, you can still edit and update the Employee project-related information without even knowing that some other service is broken.
Faster time to market
: As we are dealing with only one part of the application at a time, it is easier to make changes and move to production. Testing and deployment efforts are minimal as we are dealing with a subset of the whole system at a time.
Easy to upgrade or modify
: Let's say we need to upgrade a Microservice, upgrade software or hardware, or completely rewrite the service, this is much easier in a Microservice based architecture, as we are only upgrading one part of the application.
Higher fault tolerance
: In a monolith architecture, one error can cause the whole system to crash. In a Microservice-based architecture, in the worst case, a single service will crash, but no other services will be impacted. We still need to make sure we are managing errors properly to take advantage of Microservice-based architecture.
