Mastering Microservices With Java 9

What this book covers, A Solution Approach, covers the high-level design of large software projects and helps youunderstand the common problems faced in a production environment and the solutions to theseproblems.Chapter 1, Setting up the Development Environment, shows how to set up the development environmentand configure Spring Boot effectively. You will also learn how to build a sample REST service.Chapter 2, Domain-Driven Design, teaches you the fundamentals of domain-driven design and how is itused practically by design sample services.Chapter 3, Implementing Microservices, shows you how to code the service and then write the unit testfor the developed code.Chapter 4, 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 5, Reactive Microservices, shows how to design and implement reactive microservices.Chapter 6, Securing Microservices, covers the different security methods and the different ways toimplement OAuth. You will also understand Spring Security implementation.Chapter 7, 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 webapplication that will consume microservices to show data and flow of sample project—a small utilityproject.Chapter 8, Best Practices and Common Principles, talks about microservice design principles. You willlearn an effective way of developing microservices and how Netflix has implemented microservices.Chapter 9, Troubleshooting Guide, explains the common problems encountered during the developmentof microservices and their solutions. This will help you follow the book smoothly and would makelearning swift.Chapter 10, Migrating a Monolithic Application to a Microservice-Based Application, shows you how tomigrate a monolithic application to a microservice-based application.Chapter 11

What you need for this bookFor this book, you can use any operating system (Linux, Windows, or Mac) with a minimum of 2 GBRAM. 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 hostwith preferably 16 GB or more of RAM.

Who this book is forThis book is for Java developers who are familiar with microservice architectures and now wants totake a deeper dive into effectively implementing microservices at an enterprise level. A reasonableknowledge of core microservice elements and applications is expected.

ConventionsIn this book, you will find a number of text styles that distinguish between different kinds ofinformation. 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, dummyURLs, user input, and Twitter handles are shown as follows: "The produceBookingOrderEvent method isadded, which takes the booking object."A block of code is set as follows:angular.module('otrsApp.restaurants', e'])Any command-line input or output is written as follows:npm install --no-optional gulpNew terms and important words are shown in bold. Words that you see on the screen, for example, inmenus or dialog boxes, appear in the text like this: "On the Tools dialog, select Create package.json,Create bower.json, and Create gulpfile.js."Tips and important notes appear in a box like this.Tips and tricks appear like this.

Reader feedbackFeedback from our readers is always welcome. Let us know what you think about this book--what youliked or disliked. Reader feedback is important to us as it helps us develop titles that you will really getthe most out of. To send us general feedback, simply email feedback@packtpub.com, and mention the book'stitle in the subject of your message. If there is a topic that you have expertise in and you are interestedin either writing or contributing to a book, see our author guide at www.packtpub.com/authors.

Customer supportNow that you are the proud owner of a Packt book, we have a number of things to help you to get themost from your purchase.

Downloading the example codeYou can download the example code files for this book from your account at http://www.packtpub.com. Ifyou purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have thefiles e-mailed directly to you. You can download the code files by following these steps:1.2.3.4.5.6.7.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 filesChoose 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 latestversion of:WinRAR / 7-Zip for WindowsZipeg / iZip / UnRarX for Mac7-Zip / PeaZip for LinuxThe code bundle for the book is also hosted on GitHub at services-with-Java-9-Second-Edition. We also have other code bundles from our rich catalog of books andvideos available at https://github.com/PacktPublishing/. Check them out!

ErrataAlthough we have taken every care to ensure the accuracy of our content, mistakes do happen. If youfind a mistake in one of our books-maybe a mistake in the text or the code--we would be grateful if youcould report this to us. By doing so, you can save other readers from frustration and help us improvesubsequent 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 thedetails of your errata. Once your errata are verified, your submission will be accepted and the errata willbe 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 thename of the book in the search field. The required information will appear under the Errata section.

PiracyPiracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we takethe protection of our copyright and licenses very seriously. If you come across any illegal copies of ourworks in any form on the internet, please provide us with the location address or website nameimmediately so that we can pursue a remedy.Please contact us at copyright@packtpub.com with a link to the suspected pirated material.We appreciate your help in protecting our authors and our ability to bring you valuable content.

QuestionsIf you have a problem with any aspect of this book, you can contact us at questions@packtpub.com, and wewill do our best to address the problem.

A Solution ApproachAs a prerequisite, you should have a basic understanding of microservices and software architecturestyle. 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 productiondeployment and learn the complete life-cycle from design, development, testing, and deployment withcontinuous integration and deployment. This book is specifically written for practical use and to igniteyour mind as a solution architect. Your learning will help you to develop and ship products for any typeof premise, including SaaS, PaaS, and so on. We'll primarily use the Java and Java-based frameworktools 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. Ithighlights the large problems that on-premise and cloud-based products face and how microservicesdeals 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 backgroundMonolithic architectureLimitation of monolithic architectureThe benefits and flexibility that microservices offerMicroservices deployment on containers such as Docker

Evolution of microservicesMartin Fowler explains:The term microservice was discussed at a workshop of software architects near Venice in May 2011 todescribe what the participants saw as a common architectural style that many of them had been recentlyexploring. In May 2012, the same group decided on µServices as the most appropriate name.Let's get some background on the way it has evolved over the years. Enterprise architecture evolvedmore from historic mainframe computing, through client-server architecture (two-tier to n-tier) toService-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 becomemicroservices.Adrian Cockcroft, a former Netflix Architect, describes it as:Fine grain SOA. So microservice is SOA with emphasis on small ephemeral components.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 aswell:Small is beautiful.Microservices shares many common characteristics with SOA, such as the focus on services and howone service decouples from another. SOA evolved around monolithic application integration byexposing API that was mostly Simple Object Access Protocol (SOAP) based. Therefore, middlewaresuch as Enterprise Service Bus (ESB) is very important for SOA. Microservices are less complex, andeven though they may use the message bus it is only used for message transport and it does not containany logic. It is simply based on smart endpoints.Tony Pujals defined microservices beautifully:In my mental model, I think of self-contained (as in containers) lightweight processes communicatingover HTTP, created and deployed with relatively small effort and ceremony, providing narrowly-focusedAPIs to their consumers.Though Tony only talks about the HTTP, event-driven microservices may use the different protocol forcommunication. You can make use of Kafka for implementing the event-driven microservices. Kafkauses the wire protocol, a binary protocol over TCP.

Monolithic architecture overviewMicroservices is not something new, it has been around for many years. For example, Stubby, a generalpurpose infrastructure based on Remote Procedure Call (RPC) was used in Google data centers in theearly 2000s to connect a number of service with and across data centers. Its recent rise is owing to itspopularity and visibility. Before microservices became popular, there was primarily monolithicarchitecture 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 themtogether in Enterprise Archive (EAR) or Web Archive (WAR), or store them in a single directoryhierarchy (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 microservicesarchitecture.Now that you have had an insight into the background and history of microservices, let's discuss thelimitations of a traditional approach, namely monolithic application development, and compare howmicroservices would address them.

Limitation of monolithic architecture versusits solution with microservicesAs we know, change is eternal. Humans always look for better solutions. This is how microservicesbecame what it is today and it may evolve further in the future. Today, organizations are using Agilemethodologies to develop applications--it is a fast-paced development environment and it is also on amuch larger scale after the invention of cloud and distributed technologies. Many argue that monolithicarchitecture could also serve a similar purpose and be aligned with Agile methodologies, butmicroservices 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 arestaurant 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 withservices, and microservices design.

Traditional monolithic designThe following diagram explains the traditional monolithic application design. This design was widelyused before SOA became popular:Traditional monolithic application designIn 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 thedatabase files or another source.

Monolithic design with servicesAfter SOA, applications started being developed based on services, where each component provides theservices to other components or external entities. The following diagram depicts the monolithicapplication with different services; here services are being used with a Presentation component. Allservices, the Presentation component, or any other components are bundled together:

Services designThe following third design depicts the microservices. Here, each component represents autonomy. Eachcomponent could be developed, built, tested, and deployed independently. Here, even the applicationUser Interface (UI) component could also be a client and consume the microservices. For the purposeof our example, the layer designed is used within µService.The API Gateway provides the interface where different clients can access the individual services andsolve the following problems:What do you do when you want to send different responses to different clients for the same service? Forexample, a booking service could send different responses to a mobile client (minimal information) anda desktop client (detailed information) providing different details, and something different again to athird-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 outthat 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 variantof the first figure where all services could have their own layers and form different APIs, but, as shownin 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 deployedservices provide their specific APIs such as Customers, Bookings, or Customer. These APIs are ready toconsume. Even the UI is also deployed separately and designed using µService. For this reason, itprovides various advantages over its monolithic counterpart. I would still remind you that there aresome 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 scalabilityMonolithic applications that are large when scaled, scale everything as all the components are bundledtogether. For example, in the case of a restaurant table reservation application, even if you would like toscale the table-booking service, it would scale the whole application; it cannot scale the table-bookingservice separately. It does not utilize the resources optimally.In addition, this scaling is one-dimensional. Running more copies of the application provides the scalewith increasing transaction volume. An operation team could adjust the number of application copiesthat were using a load-balancer based on the load in a server farm or a cloud. Each of these copieswould access the same data source, therefore increasing the memory consumption, and the resulting I/Ooperations make caching less effective.Microservices gives the flexibility to scale only those services where scale is required and it allowsoptimal utilization of the resources. As we mentioned previously, when it is needed, you can scale justthe table-booking service without affecting any of the other components. It also allows two-dimensionalscaling; 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 worryingabout the scaling issues (Product scale).Microservices could help you scale platform, people, and product dimensions as we have seenpreviously. People scaling here refers to an increase or decrease in team size depending onmicroservices' specific development and focus needs.Microservice development using RESTful web-service development makes it scalable in the sense thatthe 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 failureSince monolithic applications are either bundled in the same archive or contained in a sin

Building Docker images with Maven Running Docker using Maven Integration testing with Docker Pushing the image to a registry Managing Docker containers References Summary 6. Reactive Microservices An overview of the reactive microservice architecture Responsive Resilient Elastic Message driven Implementing reactive microservices Producing an event