41,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Master the art of implementing scalable microservices in your production environment with ease
About This Book
- Use domain-driven design to build microservices
- Use Spring Cloud to use Service Discovery and Registeration
- Use Kafka, Avro and Spring Streams for implementing event based microservices
Who This Book Is For
This book is for Java developers who are familiar with the microservices architecture and now wants to take a deeper dive into effectively implementing microservices at an enterprise level. A reasonable knowledge level and understanding of core microservice elements and applications is expected.
What You Will Learn
- Use domain-driven design to design and implement microservices
- Secure microservices using Spring Security
- Learn to develop REST service development
- Deploy and test microservices
- Troubleshoot and debug the issues faced during development
- Learning best practices and common principals about microservices
In Detail
Microservices are the next big thing in designing scalable, easy-to-maintain applications. It not only makes app development easier, but also offers great flexibility to utilize various resources optimally. If you want to build an enterprise-ready implementation of the microservices architecture, then this is the book for you!
Starting off by understanding the core concepts and framework, you will then focus on the high-level design of large software projects. You will gradually move on to setting up the development environment and configuring it before implementing continuous integration to deploy your microservice architecture. Using Spring security, you will secure microservices and test them effectively using REST Java clients and other tools like RxJava 2.0. We'll show you the best patterns, practices and common principals of microservice design and you'll learn to troubleshoot and debug the issues faced during development. We'll show you how to design and implement reactive microservices. Finally, we'll show you how to migrate a monolithic application to microservices based application.
By the end of the book, you will know how to build smaller, lighter, and faster services that can be implemented easily in a production environment.
Style and approach
This book starts from the basics, including environment setup and provides easy-to-follow steps to implement the sample project using microservices.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 306
Veröffentlichungsjahr: 2017
Ähnliche
Mastering Microservices with Java 9
Second Edition
BIRMINGHAM - MUMBAI
Mastering Microservices with Java 9
Second Edition
Copyright © 2017 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 author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be 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.
First published: June 2016
Second edition: December 2017
Production reference: 1051217
ISBN 978-1-78728-144-8
www.packtpub.com
Credits
Author
Sourabh Sharma
Copy Editor
Safis Editing
Reviewer
Guido Grazioli
Project Coordinator
Vaidehi Sawant
Commissioning Editor
Aaron Lazar
Proofreader
Safis Editing
Acquisition Editor
Denim Pinto
Indexer
Aishwarya Gangawane
Content Development Editor
Zeeyan Pinheiro
Production Coordinator
Melwyn D'sa
Technical Editor
Romy Dias
About the Author
SourabhSharma has over 15 years of experience in product/application development. His expertise lies in designing, developing, deploying, and testing N-tier web applications and leading teams. He loves to troubleshoot complex problems and look for the best solutions.
Throughout his career, he has successfully delivered various on-premise and cloud applications/products to some of the fortune 500 companies that has amazed stakeholders, including happy satisfied customers.
Sourabh believes in the continuous process of learning and has been continuously updating his skill set—from standalone application development to microservices development, from JDK 1.2 to Java 9, from IE 5 dependent frontend code to cross-browser development, and from on-premise deployment to cloud deployment. He has effectively managed delivering single products to bouquets of applications.
About the Reviewer
GuidoGrazioli has worked as an application developer, software architect, and systems integrator for a wide variety of business applications across several domains. He is a hybrid software engineer with deep knowledge of the Java platform and tooling as well as Linux systems. He is particularly interested in SOAs, EIPs, continuous integration and delivery, and service orchestration in the cloud.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.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.PacktPub.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.PacktPub.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.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/1787281442.
If you'd like to join our team of regular reviewers, you can e-mail us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Table of Contents
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the example code
Errata
Piracy
Questions
A Solution Approach
Evolution of microservices
Monolithic architecture overview
Limitation of monolithic architecture versus its solution with microservices
Traditional monolithic design
Monolithic design with services
Services design
One dimension scalability
Release rollback in case of failure
Problems in adopting new technologies
Alignment with Agile practices
Ease of development – could be done better
Microservices build pipeline
Deployment using a container such as Docker
Containers
Docker
Docker's architecture
Deployment
Summary
Setting Up the Development Environment
NetBeans IDE installation and setup
Spring Boot configuration
Spring Boot overview
Adding Spring Boot to our main project
Sample REST program
Writing the REST controller class
The @RestController annotation
The @RequestMapping annotation
The @RequestParam annotation
The @PathVariable annotation
Making a sample REST application executable
Adding a Jetty-embedded server
Setting up the application build
Running the Maven tool
Executing with the Java command
REST API testing using the Postman Chrome extension
Some more positive test scenarios
Negative test scenarios
Summary
Domain-Driven Design
Domain-driven design fundamentals
Fundamentals of DDD
Ubiquitous language
Multilayered architecture
Presentation layer
Application layer
Domain layer
Infrastructure layer
Artifacts of domain-driven design
Entities
Value objects
FAQs
Services
Aggregates
Repository
Factory
Modules
Strategic design and principles
Bounded context
Continuous integration
Context map
Shared kernel
Customer-supplier
Conformist
Anticorruption layer
Separate ways
Open Host Service
Distillation
Sample domain service
Entity implementation
Repository implementation
Service implementation
Summary
Implementing a Microservice
OTRS overview
Developing and implementing microservices
Restaurant microservice
OTRS implementation
Controller class
API versioning
Service classes
Repository classes
Entity classes
Registration and discovery service (Eureka service)
Eureka client
Booking and user services
Execution
Testing
References
Summary
Deployment and Testing
Mandatory services for good microservices
Service discovery and registration
Edge servers
Load balancing
Circuit breakers
Monitoring
An overview of microservice architecture using Netflix OSS
Load balancing
Server-side load balancing
Client-side load balancing
Circuit breakers and monitoring
Using Hystrix's fallback methods
Monitoring
Setting up the Hystrix dashboard
Creating Turbine services
Building and running the OTRS application
Microservice deployment using containers
Installation and configuration
Docker machine with 4 GB
Building Docker images with Maven
Running Docker using Maven
Integration testing with Docker
Pushing the image to a registry
Managing Docker containers
References
Summary
Reactive Microservices
An overview of the reactive microservice architecture
Responsive
Resilient
Elastic
Message driven
Implementing reactive microservices
Producing an event
Consuming the event
References
Summary
Securing Microservices
Enabling Secure Socket Layer
Authentication and authorization
OAuth 2.0
Usage of OAuth
OAuth 2.0 specification - concise details
OAuth 2.0 roles
Resource owner
Resource server
Client
Authorization server
OAuth 2.0 client registration
Client types
Client profiles
Client identifier
Client authentication
OAuth 2.0 protocol endpoints
Authorization endpoint
Token endpoint
Redirection endpoint
OAuth 2.0 grant types
Authorization code grant
Implicit grant
Resource owner password credentials grant
Client credentials grant
OAuth implementation using Spring Security
Authorization code grant
Implicit grant
Resource owner password credential grant
Client credentials grant
References
Summary
Consuming Services Using a Microservice Web Application
AngularJS framework overview
MVC
MVVM
Modules
Providers and services
Scopes
Controllers
Filters
Directives
UI-Router
Development of OTRS features
Home page/restaurant list page
index.html
app.js
restaurants.js
restaurants.html
Search restaurants
Restaurant details with reservation option
restaurant.html
Login page
login.html
login.js
Reservation confirmation
Setting up the web application
References
Summary
Best Practices and Common Principles
Overview and mindset
Best practices and principles
Nanoservice, size, and monolithic
Continuous integration and deployment
System/end-to-end test automation
Self-monitoring and logging
A separate data store for each microservice
Transaction boundaries
Microservices frameworks and tools
Netflix Open Source Software (OSS)
Build - Nebula
Deployment and delivery - Spinnaker with Aminator
Service registration and discovery - Eureka
Service communication - Ribbon
Circuit breaker - Hystrix
Edge (proxy) server - Zuul
Operational monitoring - Atlas
Reliability monitoring service - Simian Army
AWS resource monitoring - Edda
On-host performance monitoring - Vector
Distributed configuration management - Archaius
Scheduler for Apache Mesos - Fenzo
Cost and cloud utilization - Ice
Other security tools - Scumblr and FIDO
Scumblr
Fully Integrated Defence Operation (FIDO)
References
Summary
Troubleshooting Guide
Logging and the ELK stack
A brief overview
Elasticsearch
Logstash
Kibana
ELK stack setup
Installing Elasticsearch
Installing Logstash
Installing Kibana
Running the ELK stack using Docker Compose
Pushing logs to the ELK stack
Tips for ELK stack implementation
Use of correlation ID for service calls
Let's see how we can tackle this problem
Use of Zipkin and Sleuth for tracking
Dependencies and versions
Cyclic dependencies and their impact
Analyzing dependencies while designing the system
Maintaining different versions
Let's explore more
References
Summary
Migrating a Monolithic Application to Microservice-Based Application
Do you need to migrate?
Cloud versus on-premise versus both cloud and on-premise
Cloud only solution
On-premise only solution
Both cloud and on-premise solution
Approaches and keys to successful migration
Incremental migration
Process automation and tools setup
Pilot project
Standalone user interface applications
Migrating modules to microservices
How to accommodate a new functionality during migration
References
Summary
Preface
Microservices are the next big thing in designing scalable, easy-to-maintain applications. They not only makes application development easier, but also offer great flexibility to utilize various resources optimally. If you want to build an enterprise-ready implementation of a microservice architecture, then this is the book for you!
Starting off by understanding the core concepts and framework, you will then focus on the high-level design of large software projects. You will gradually move on to setting up the development environment and configuring it before implementing continuous integration to deploy your microservice architecture. Using Spring Security, you will secure microservices and test them effectively using REST Java clients and other tools such as RxJava 2.0. We'll show you the best patterns, practices, and common principles of microservice design, and you'll learn to troubleshoot and debug the issues faced during development. We'll show you how to design and implement reactive microservices. Finally, we'll show you how to migrate a monolithic application to a microservice-based application.
By the end of the book, you will know how to build smaller, lighter, and faster services that can be implemented easily in a production environment.
What this book covers
Chapter 1,A Solution Approach, covers the high-level design of large software projects and helps you understand the common problems faced in a production environment and the solutions to these problems.
Chapter 2, Setting up the Development Environment, shows how to set up the development environment and configure Spring Boot effectively. You will also learn how to build a sample REST service.
Chapter 3, Domain-Driven Design, teaches you the fundamentals of domain-driven design and how is it used practically by design sample services.
Chapter 4, Implementing Microservices, shows you how to code the service and then write the unit test for the developed code.
Chapter 5, Deployment and Testing, covers how to deploy microservices and develop them on Docker. You will also learn to write the Java test client for microservices.
Chapter 6, Reactive Microservices, shows how to design and implement reactive microservices.
Chapter 7, Securing Microservices, covers the different security methods and the different ways to implement OAuth. You will also understand Spring Security implementation.
Chapter 8, Consuming Microservices Using Web Application, explains how to develop a web application (UI) using the Knockout. You will require Bootstrap JS libraries to build a prototype of a web application that will consume microservices to show data and flow of sample project—a small utility project.
Chapter 9, Best Practices and Common Principles, talks about microservice design principles. You will learn an effective way of developing microservices and how Netflix has implemented microservices.
Chapter 10, Troubleshooting Guide,explains the common problems encountered during the development of microservices and their solutions. This will help you follow the book smoothly and would make learning swift.
Chapter 11, Migrating a Monolithic Application to a Microservice-Based Application, shows you how to migrate a monolithic application to a microservice-based application.
What you need for this book
For this book, you can use any operating system (Linux, Windows, or Mac) with a minimum of 2 GB RAM. You will also require NetBeans with Java, Maven, Spring Boot, Spring Cloud, Eureka Server, Docker, and a CI/CD application. For Docker containers, you may need a separate VM or a cloud host with preferably 16 GB or more of RAM.
Who this book is for
This book is for Java developers who are familiar with microservice architectures and now wants to take a deeper dive into effectively implementing microservices at an enterprise level. A reasonable knowledge of core microservice elements and applications is expected.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "The produceBookingOrderEvent method is added, which takes the booking object."
A block of code is set as follows:
angular.module('otrsApp.restaurants', [ 'ui.router', 'ui.bootstrap', 'ngStorage', 'ngResource' ])
Any command-line input or output is written as follows:
npm install --no-optional gulp
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "On theToolsdialog, selectCreate package.json,Create bower.json, andCreate gulpfile.js."
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book--what you liked or disliked. Reader feedback is important to us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply email [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you. You can download the code files by following these steps:
Log in or register to our website using your e-mail address and password.
Hover the mouse pointer on the
SUPPORT
tab at the top.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box.
Select the book for which you're looking to download the code files
Choose from the drop-down menu where you purchased this book from.
Click on
Code Download
.
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/Mastering-Microservices-with-Java-9-Second-Edition. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code--we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
A Solution Approach
As a prerequisite, you should have a basic understanding of microservices and software architecture style. Having a basic understanding could help you to understand the concepts and this book thoroughly.
After reading this book, you could implement microservices for on-premise or cloud production deployment and learn the complete life-cycle from design, development, testing, and deployment with continuous integration and deployment. This book is specifically written for practical use and to ignite your mind as a solution architect. Your learning will help you to develop and ship products for any type of premise, including SaaS, PaaS, and so on. We'll primarily use the Java and Java-based framework tools such as Spring Boot and Jetty, and we will use Docker as a container.
In this chapter, you will learn the eternal existence of microservices, and how it has evolved. It highlights the large problems that on-premise and cloud-based products face and how microservices deals with it. It also explains the common problems encountered during the development of SaaS, enterprise, or large applications and their solutions.
In this chapter, we will learn the following topics:
Microservices
and a brief background
Monolithic architecture
Limitation of monolithic architecture
The benefits and flexibility that microservices offer
Microservices
deployment on containers such as Docker
Evolution of microservices
Martin Fowler explains:
Let's get some background on the way it has evolved over the years. Enterprise architecture evolved more from historic mainframe computing, through client-server architecture (two-tier to n-tier) to Service-Oriented Architecture (SOA).
The transformation from SOA to microservices is not a standard defined by an industry organization, but a practical approach practiced by many organizations. SOA eventually evolved to become microservices.
Adrian Cockcroft, a former Netflix Architect, describes it as:
Similarly, the following quote from Mike Gancarz, a member that designed the X Windows system, which defines one of the paramount precepts of Unix philosophy, suits the microservice paradigm as well:
Microservices shares many common characteristics with SOA, such as the focus on services and how one service decouples from another. SOA evolved around monolithic application integration by exposing API that was mostly Simple Object Access Protocol (SOAP) based. Therefore, middleware such as Enterprise Service Bus (ESB) is very important for SOA. Microservices are less complex, and even though they may use the message bus it is only used for message transport and it does not contain any logic. It is simply based on smart endpoints.
Tony Pujals defined microservices beautifully:
Though Tony only talks about the HTTP, event-driven microservices may use the different protocol for communication. You can make use of Kafka for implementing the event-driven microservices. Kafka uses the wire protocol, a binary protocol over TCP.
Monolithic architecture overview
Microservices is not something new, it has been around for many years. For example, Stubby, a general purpose infrastructure based on RemoteProcedureCall (RPC) was used in Google data centers in the early 2000s to connect a number of service with and across data centers. Its recent rise is owing to its popularity and visibility. Before microservices became popular, there was primarily monolithic architecture that was being used for developing on-premise and cloud applications.
Monolithic architecture allows the development of different components such as presentation, application logic, business logic, and Data Access Objects (DAO), and then you either bundle them together in Enterprise Archive (EAR) or Web Archive (WAR), or store them in a single directory hierarchy (for example, Rails, NodeJS, and so on).
Many famous applications such as Netflix have been developed using microservices architecture. Moreover, eBay, Amazon, and Groupon have evolved from monolithic architecture to a microservices architecture.
Now that you have had an insight into the background and history of microservices, let's discuss the limitations of a traditional approach, namely monolithic application development, and compare how microservices would address them.
Limitation of monolithic architecture versus its solution with microservices
As we know, change is eternal. Humans always look for better solutions. This is how microservices became what it is today and it may evolve further in the future. Today, organizations are using Agile methodologies to develop applications--it is a fast-paced development environment and it is also on a much larger scale after the invention of cloud and distributed technologies. Many argue that monolithic architecture could also serve a similar purpose and be aligned with Agile methodologies, but microservices still provides a better solution to many aspects of production-ready applications.
To understand the design differences between monolithic and microservices, let's take an example of a restaurant table-booking application. This application may have many services such as customers, bookings, analytics and so on, as well as regular components such as presentation and database.
We'll explore three different designs here; traditional monolithic design, monolithic design with services, and microservices design.
Traditional monolithic design
The following diagram explains the traditional monolithic application design. This design was widely used before SOA became popular:
In traditional monolithic design, everything is bundled in the same archive such as Presentation code, Application Logic and Business Logic code, and DAO and related code that interacts with the database files or another source.
Monolithic design with services
After SOA, applications started being developed based on services, where each component provides the services to other components or external entities. The following diagram depicts the monolithic application with different services; here services are being used with a Presentation component. All services, the Presentation component, or any other components are bundled together:
Services design
The following third design depicts the microservices. Here, each component represents autonomy. Each component could be developed, built, tested, and deployed independently. Here, even the application User Interface (UI) component could also be a client and consume the microservices. For the purpose of our example, the layer designed is used within µService.
The API Gateway provides the interface where different clients can access the individual services and solve the following problems:
What do you do when you want to send different responses to different clients for the same service? For example, a booking service could send different responses to a mobile client (minimal information) and a desktop client (detailed information) providing different details, and something different again to a third-party client.
A response may require fetching information from two or more services:
After observing all the sample design diagrams, which are very high-level designs, you might find out that in monolithic design, the components are bundled together and tightly coupled.
All the services are part of the same bundle. Similarly, in the second design figure, you can see a variant of the first figure where all services could have their own layers and form different APIs, but, as shown in the figure, these are also all bundled together.
Conversely, in microservices, design components are not bundled together and have loose coupling. Each service has its own layers and DB, and is bundled in a separate archive. All these deployed services provide their specific APIs such as Customers, Bookings, or Customer. These APIs are ready to consume. Even the UI is also deployed separately and designed using µService. For this reason, it provides various advantages over its monolithic counterpart. I would still remind you that there are some exceptional cases where monolithic application development is highly successful, such as Etsy, and peer-to-peer e-commerce web applications.
Now let us discuss the limitations you'd face while working with Monolithic applications.
One dimension scalability
Monolithic applications that are large when scaled, scale everything as all the components are bundled together. For example, in the case of a restaurant table reservation application, even if you would like to scale the table-booking service, it would scale the whole application; it cannot scale the table-booking service separately. It does not utilize the resources optimally.
In addition, this scaling is one-dimensional. Running more copies of the application provides the scale with increasing transaction volume. An operation team could adjust the number of application copies that were using a load-balancer based on the load in a server farm or a cloud. Each of these copies would access the same data source, therefore increasing the memory consumption, and the resulting I/O operations make caching less effective.
Microservices gives the flexibility to scale only those services where scale is required and it allows optimal utilization of the resources. As we mentioned previously, when it is needed, you can scale just the table-booking service without affecting any of the other components. It also allows two-dimensional scaling; here we can not only increase the transaction volume, but also the data volume using caching (Platform scale).
A development team can then focus on the delivery and shipping of new features, instead of worrying about the scaling issues (Product scale).
Microservices could help you scale platform, people, and product dimensions as we have seen previously. People scaling here refers to an increase or decrease in team size depending on microservices' specific development and focus needs.
Microservice development using RESTful web-service development makes it scalable in the sense that the server-end of REST is stateless; this means that there is not much communication between servers, which makes it horizontally scalable.
Release rollback in case of failure
Since monolithic applications are either bundled in the same archive or contained in a single directory, they prevent the deployment of code modularity. For example, many of you may have experienced the pain of delaying rolling out the whole release due to the failure of one feature.
To resolve these situations, microservices gives us the flexibility to rollback only those features that have failed. It's a very flexible and productive approach. For example, let's assume you are the member of an online shopping portal development team and want to develop an application based on microservices. You can divide your application based on different domains such as products, payments, cart, and so on, and package all these components as separate packages. Once you have deployed all these packages separately, these would act as single components that can be developed, tested, and deployed independently, and called µService.
Now, let's see how that helps you. Let's say that after a production release launching new features, enhancements, and bug fixes, you find flaws in the payment service that need an immediate fix. Since the architecture you have used is based on microservices, you can rollback the payment service instead of rolling back the whole release, if your application architecture allows, or apply the fixes to the microservices payment service without affecting the other services. This not only allows you to handle failure properly, but it also helps to deliver the features/fixes swiftly to a customer.
Problems in adopting new technologies
Monolithic applications are mostly developed and enhanced based on the technologies primarily used during the initial development of a project or a product. It makes it very difficult to introduce new technology at a later stage of the development or once the product is in a mature state (for example, after a few years). In addition, different modules in the same project, that depend on different versions of the same library, make this more challenging.
Technology is improving year on year. For example, your system might be designed in Java and then, a few years later, you want to develop a new service in Ruby on Rails or NodeJS because of a business need or to utilize the advantages of new technologies. It would be very difficult to utilize the new technology in an existing monolithic application.
It is not just about code-level integration, but also about testing and deployment. It is possible to adopt a new technology by re-writing the entire application, but it is time-consuming and a risky thing to do.
On the other hand, because of its component-based development and design, microservices gives us the flexibility to use any technology, new or old, for its development. It does not restrict you to using specific technologies, it gives a new paradigm to your development and engineering activities. You can use Ruby on Rails, NodeJS, or any other technology at any time.
So, how is it achieved? Well, it's very simple. Microservices-based application code does not bundle into a single archive and is not stored in a single directory. Each µService has its own archive and is deployed separately. A new service could be developed in an isolated environment and could be tested and deployed without any technical issues. As you know, microservices also owns its own separate processes; it serves its purpose without any conflict such as shared resources with tight coupling, and processes remain independent.
Since a microservice is by definition a small, self-contained function, it provides a low-risk opportunity to try a new technology. That is definitely not the case where monolithic systems are concerned.
You can also make your microservice available as open source software so it can be used by others, and if required it may interoperate with a closed source proprietary one, which is not possible with monolithic applications.
Alignment with Agile practices
There is no question that monolithic applications can be developed using Agile practices, and these are being developed. Continuous Integration (CI) and Continuous Deployment (CD) could be used, but the question is—does it use Agile practices effectively? Let's examine the following points:
For example, when there is a high
probability
of having stories dependent on each other, and there could be various scenarios, a story could not be taken up until the dependent story is complete
The build takes more time as the code size increases
The frequent deployment of a large monolithic application is a difficult task to achieve
You would have to redeploy the whole application even if you updated a single component
Redeployment may cause problems to already running components, for example, a job scheduler may change whether components impact it or not
The risk of redeployment may increase if a single changed component does not work properly or if it needs more fixes
UI developers always need more redeployment, which is quite risky and time-consuming for large monolithic applications
The preceding issues can be tackled very easily by microservices, for example, UI developers may have their own UI component that can be developed, built, tested, and deployed separately. Similarly, other microservices might also be deployable independently and, because of their autonomous characteristics, the risk of system failure is reduced. Another advantage for development purposes is that UI developers can make use of the JSON object and mock Ajax calls to develop the UI, which can be taken up in an isolated manner. After development completes, developers can consume the actual APIs and test the functionality. To summarize, you could say that microservices development is swift and it aligns well with the incremental needs of businesses.
Ease of development – could be done better
Generally, large monolithic application code is the toughest to understand for developers, and it takes time before a new developer can become productive. Even loading the large monolithic application into IDE is troublesome, and it makes IDE slower and the developer less productive.
A change in a large monolithic application is difficult to implement and takes more time due to a large code base, and there will be a high risk of bugs if impact analysis is not done properly and thoroughly. Therefore, it becomes a prerequisite for developers to do thorough impact analysis before implementing changes.
In monolithic applications, dependencies build up over time as all components are bundled together. Therefore, the risk associated with code change rises exponentially as code changes (number of modified lines of code) grows.
When a code base is huge and more than 100 developers are working on it, it becomes very difficult to build products and implement new features because of the previously mentioned reason. You need to make sure that everything is in place, and that everything is coordinated. A well-designed and documented API helps a lot in such cases.
Netflix, the on-demand internet streaming provider, had problems getting their application developed, with around 100 people working on it. Then, they used a cloud and broke up the application into separate pieces. These ended up being microservices. Microservices grew from the desire for speed and agility and to deploy teams independently.
Micro-components are made loosely coupled thanks to their exposed API, which can be continuously integration tested. With microservices' continuous release cycle, changes are small and developers can rapidly exploit them with a regression test, then go over them and fix the eventual defects found, reducing the risk of a deployment. This results in higher velocity with a lower associated risk.
Owing to the separation of functionality and single responsibility principle, microservices makes teams very productive. You can find a number of examples online where large projects have been developed with minimum team sizes such as eight to ten developers.
