0

I was watching a webinar made by lightbend talking about refactoring monoliths into microservices and a question came to me. The framework's main target seems to be refactoring monoliths, but lagom seems to run on its own container and set of technologies. When I think about monoliths and legacy Java apps, the main technology that came to my mind is Java EE. I think most of the applications in productions today rely on some Java EE technologies. The one I work in is based on EJB's mostly. So my question is: how Lagom solves this issue? I imagine refactoring this kind of application involves convert the remote EJB lookup into rest calls. But how would I keep the local EJB's of my application if lagom does not run in a Java EE container? Is it possible to use both?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Augusto
  • 1,234
  • 1
  • 16
  • 35

3 Answers3

1

I don't have a deep knowledge about Lagom, however, the market that is using architectures based on Microservices are heavily relying on spring boot/cloud. Currently, I'm working on a really large project using Microservices and it seems that the spring guys provide a lot of frameworks/tools for each microservices pattern that you should have in mind when you're thinking in microservices. By other hand, Netflix (the biggest microservices user) rely on Spring, I think that Spring Boot/Cloud is a good way to refactor your Java EE monolithic app to microservices

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Rene Enriquez
  • 1,418
  • 1
  • 13
  • 33
  • I agree with you that it would be a lot better to rely on Spring Boot than on JEE, but the thing is that I would have to do a lot more refactor to replace the local EJB's (wich the app I work use for dependency injection) to use the Spring equivalent. – Augusto Apr 12 '16 at 14:17
  • This is not an answer, this is just promoting alternative frameworks to the one in question. – Jon Feb 12 '17 at 09:28
0

I suggest watching https://vimeo.com/163760711. The answer is that you shouldn't just be taking your EJBs and turning them into services, if you do that, you'll just introduce all the complexity and performance pain of having many services, and get none of the benefits of microservices. You need to rethink your architecture if you want to benefit from microservices.

James Roper
  • 12,695
  • 46
  • 45
  • I agree with you. The big problem is that I cannot remake a 10 year's application from scratch to do that. I can refactor the calls from module to module, but removing the JEE container would implicate to remake the application. – Augusto May 06 '16 at 13:14
  • Of course not, it has to be done incrementally. Work out what the eventual architecture will look like, then decide what the highest value changes are to make first, then start decomposing. It may take years, but that's OK, the apps being around for 10 years already, an incremental approach to improving it will make it last another 10. – James Roper May 08 '16 at 22:33
0

You can start with representing your existing EJB services with a set of REST web-services, which in turn will be consumed by your new Lagom-based microservices, like this:

[EJB services] <- [EJB based REST services gateway] <- [Lagom based microservices]

or as deployment modules:

[your EJB app .EAR] <- [EJB-REST gateway .WAR] <- [Lagom based app]

Since your EJB app will run in a container (e.g. Wildfly), your Lagom app will be deployed independently (possibly on different host). Introducing the REST Services layer will allow you to develop each of the modules independently, which is the key to success in this case.

Next, gradually you would implement new functions and possibly reimplement some of the legacy functions in the new Lagom based app.

This is exactly what I did, and it works like a charm.

monad
  • 125
  • 1
  • 7