The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

akuma8 (15) [Avatar] Offline
#1
Hi Mr Carnell,

Thank you for this book, I've just finished it today and many questions still remain that's why I am posting this message.
First, sorry for my bad english I am living in France.

I bought the book because I am developping a multi-users web application (which is almost finished with a monolithic architecture) using Spring and I would like to segregate it in different microservices.

I am here to ask some advises about the general architecure.

My questions are :

1- How to design a microservices application including a Web UI client? (It's a pity that you didn't addressed the subject with more details in the book)
Should I dedicated a microservice only for this task i-e which its goal is displaying the GUI part (I have about 40 JSP files)?

2- As the GUI part is the application's entry point, should I make it the application's gateway? I mean, can I mix routing and MVC part in the same service or is there an altertnative? In page 225, fig. 7.13 seems to correspond to a beginning of architecture.

3- Regarding the code in the book, are the 4 classes (UserContext, UserContextFilter, UserContextHolder, UserContextInterceptor) still usefull even using Spring Cloud Sleuth?

4- Is there a way to avoid duplicating the code, above all POJOs? Here we have the same POJO (Organization) in licensing and organization services. In an application with many microservices it could be really useful if we could avoid this.

5- How to deploy many instances of the same service? You didn't address the issue, should we deploy them in the same container as the "mother" service or in different containers?

I am still in the phase of the "Architect's Story: designing the mcroservices architecture" that's why I am back here to get some advises. I found really interesting the sharing of your experience in different situations.

Many thanks again.
John C Carnell (44) [Avatar] Offline
#2
Hi,

First of all, thank you for buying the book. I am glad you enjoyed it. Let me see if I can answer your questions below. Please do not hesitate to drop me an email or post to this forum if you have further questions.

Also, please excuse any grammar problems in my responses. I am writing this before work and do not have crack editing team reviewing my work and making sure I sound coherent .

Thanks,
John



Hi Mr Carnell, 

Thank you for this book, I've just finished it today and many questions still remain that's why I am posting this message. 
First, sorry for my bad english I am living in France. 

I bought the book because I am developping a multi-users web application (which is almost finished with a monolithic architecture) using Spring and I would like to segregate it in different microservices. 

I am here to ask some advises about the general architecure. 

My questions are : 

1- How to design a microservices application including a Web UI client? (It's a pity that you didn't addressed the subject with more details in the book) 
Should I dedicated a microservice only for this task i-e which its goal is displaying the GUI part (I have about 40 JSP files)? 

I always answer questions around GUI and microservices really around what the screen is suppose to accomplish. If the screen is a simple data entry screen, then having a 1-1 correspondence between the screen and microservice is feasible. If your screen represents a complex business process that might have to coordinate across multiple microservices, I usually look at building a “wrapper” service that will act as the entry point for the screen and allow the screen to have a simplified interface. I personally would keep multi-service orchestration out of the user interface and let the screens focused purely on the UI.

2- As the GUI part is the application's entry point, should I make it the application's gateway? I mean, can I mix routing and MVC part in the same service or is there an altertnative? In page 225, fig. 7.13 seems to correspond to a beginning of architecture. 

Great question. Personally I would keep service routing out of the UI. I usually start microservice application development behind a service gateway. That way all of the routing logic is abstracted behind the gateway and I have a single access point if I want to enforce a policy across all of my services. I like to start with a service gateway first because it is extremely painful to refactor and existing application over to using a service gateway.

3- Regarding the code in the book, are the 4 classes (UserContext, UserContextFilter, UserContextHolder, UserContextInterceptor) still usefull even using Spring Cloud Sleuth? 

No. I think I might have mentioned this a couple of times in the book. The code in Chapter 6 around Zuul where I introduce the UserContext, UserContextFilter etc, was really mean to be a teaching tool on how to write Pre and Post response filters. The correlation id concept is an easy one to understand and communicate. Personally, Spring Cloud Sleuth replaces all of the functionality for inserting correlation ids. The UserContext* classes really are not needed once you get Spring Cloud Sleuth in place.

That is one of the reasons why I love Spring Cloud Sleuth. As you can tell from the earlier chapters, doing a task like injecting a correlation id into every service call results in a lot of code. If I can replace it with code written by people who are smarter then me, then I am definitely going to do it.


4- Is there a way to avoid duplicating the code, above all POJOs? Here we have the same POJO (Organization) in licensing and organization services. In an application with many microservices it could be really useful if we could avoid this. 

I make mention at some point about this in the book. Most organizations (mine included) will get into a debate about what should be shared across microservices. The purists will argues that nothing should be shared including any kind of common domain model (e.g. what you are referring to with the POJOS). Others will argues that is ok to share common libraries.

I sit some where in the middle. The challenge with common libraries is that if the libraries change you have to redeploy them to all the microservices that use them. This can be very painful in a large microservice environment.

I think some share libraries are needed in a microservice environment. POJOs and data classes used to represent events are usually fine to share.

Now, the reason why I have all the POJO code duplicated in the book was more to keep the code examples in the book self contained. I wanted to make sure every chapter in the book could be built in a self-contained fashion without having to worry about a bunch of “custom” dependencies built in a third-party library. That way you could be confident that everything you needed to run the code in the chapter would work. I have been the consumer of multiple books where code introduced earlier in a chapter was not explicitly included in the later chapter, so I wanted to keep everything together.


5- How to deploy many instances of the same service? You didn't address the issue, should we deploy them in the same container as the "mother" service or in different containers? 

I always lean towards the rule of once service instance per container. If need multiple instances of a service I deployed multiple containers each with the own copy of the service. Part of the reason for this is that you want isolation between not only other services, but also other instances of another service. I have been in many a critical situation call where because services shared the same box a misbehaving service would crash everything.

Also, when deploying service containers I would make sure I spread the deployed instances out across multiple services. In the last chapter, I use a single ECS service because it was example. In a production application, my ECS environment would have multiple servers hosting Docker instances.

I am still in the phase of the "Architect's Story: designing the mcroservices architecture" that's why I am back here to get some advises. I found really interesting the sharing of your experience in different situations. 

Many thanks again. 

akuma8 (15) [Avatar] Offline
#3
Hi,
Thanks again for replying.
About the GUI part I've decided to devide it in 2 parts (microservices) :
1st one for public access (home page, etc...) and 2nd one for authenticated users (user account, etc...).

Regarding the 5th question about deploying several instances, what should be the URL of the other instances?
I mean, since thoses instances have the same application name how are they discovered? How Eureka decides which instance to call? As a developper should I care about that (and setting URL for each instance) or Eureka is capable to decide itself?

Thanks for your clarifications.
John C Carnell (44) [Avatar] Offline
#4
Hi,

My answers are in bold.

Regarding the 5th question about deploying several instances, what should be the URL of the other instances?
I mean, since thoses instances have the same application name how are they discovered? How Eureka decides which instance to call? As a developper should I care about that (and setting URL for each instance) or Eureka is capable to decide itself?

Each service instance will register itself with a service discovery engine (e.g. Eureka). The service instances will use an application id that is the same across all instances of that service instances type. If you use the enhanced RestTemplate classes via Ribbon, you are going to use the application id in the URL you are calling. The Ribbon libraries do the heavy lifting of talking to Eureka. I believe Eureka will uses a round-robin algorithm to select the specific service instance that is being looked up. You as the developer, if you are using the Ribbon-enhanced RestTemplate, will not care about the particular instance you are trying to call. This is abstracted away from you via the application id of the service. If you want to see this in action, you can modify the docker file in the chapter 4 source code and cut and past another instance of either the organization or licensing service. Give both the second copy a different port number then the first. Then if you launch the code via docker-compose, you can hit the http://localhost:8761/eurka/apps/APPLICATIONID (page 110 in the text) endpoint and you should see two services of that particular type being returned. Make sure you give a little time for both services to register with Eureka. I hope that answers your question.

Thanks for your clarifications.