Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Microservices for new J2EE applications

 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sam,

I recently watched a talk on micro services by Redhat. The speaker was telling that it would be sort of inappropriate to start the design of new apps with micro services. The idea is that building micro services requires in depth analysis of the business goals, business context etc. This analysis usually sheds light on "services" required at a granular scale, which aids in developing micro services. Usually such a comprehensive requirements is seldom available when the project kicks off. So, one may be better of building traditional WAR/EAR to begin with and then breakdown the EAR/WAR to microservices at a later stage when more insight is acquired during the course of the project.

What are your thoughts on the above? Would you rather go with micro services approach from day one for new projects?
 
Author
Posts: 25
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sunderam,

In general, it's not bad advice. One of the biggest things that can go wrong is getting service boundaries wrong - it leads to higher cost of change, can lead to operation issues etc. We've found that an excellent way to find more stable, reusable/composable boundaries is to model them around the business domain. If your understanding of the business domain is poor (perhaps because you are new to it) the chances of you finding good boundaries early on is reduced.

I explore that a bit in a recent post Microservices For Greenfield, which in part inspired Martin Fowler to write a related article MonolithFirst - you might also want to look at Stefan Tilkov's rebuttal too though to get a different view.

My general advice therefore is to be more cautious early on in a new project about spinning up lots of services. Some obvious boundaries may present themselves early on, but others might be less clear. So be more monolithic early. I do though think that even within the monolith, you should strive to keep your code decomposed into modules oriented around business domains too (NOT arbitary technical domains). So rather than model, view controller packages, think Invoicing, Finance, Sales packages (inside which you may or may not then have technical groupings). Parnas FTW! This will help you if you decide to spin stuff out later. I explore that a bit in the book (chapter 5) and also in my talk Macro To Micro.

One last thought. Even when starting with a monolith, really question why you're using an application container. Why not bundle everything as an executable JAR file with an embedded servlet container?
 
"I know this defies the law of gravity... but I never studied law." -B. Bunny Defiant tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth
https://coderanch.com/t/751654/free-earth-friendly-heat-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic