3

I'm migrating my monolithic web application to a microservice based one. I'm going to use Spring cloud and I've got a discovery service where all the rest of the services are registered. A simplified schema of the architecture is drawn here:

enter image description here

Both Equipment and Task services have their own RESTful HTTP API. They take care of which operations user can perform based in roles, which are stored in a OAuth2 token, which is delivered by a proper OAuth2 Authorization server.

Now let's talk about the clients. For the mobile native app, it will grab a token from the Authorization Server for the user. Then, core services are accessed directly with that token. If the end user tries to perform an operation which has not been granted for, it will be rejected, as security is implemented at API method level.

For browser access, we could have gone with AngularJS and access the core REST API directly, but we're a bit inexperienced on it and we've chosen to implement a third service which houses the JSF framework. The views will be rendered by JSF, so the UI-Service has to talk with core services in JSON language and parse it to java (that's a breeze using Jackson library).

The decision to make the UI service monolithic is that if we want to store some data in server session, we won't need session clustering to share it amongst more UI-Services. If we want to do horizontal scaling, we might always stick to session-in-one-instance pattern.

I've even been told not to implement the UI-service as separated at all, but to integrate it in the core services. As everything is implemented in Java, that way I should not take care of JSON parsing, but it might be coupling the UI and core part tightly.

Any suggestions about it?

0
+100

You seem to already have a monolithic UI - the native mobile app is the UI client, and its standalone. Why then would you want to incorporate a webserver-based UI inside the core services?

The webserver UI should be considered to be another client, just like your native app, then the core services can be implemented without any consideration for any UI, they simply exist to serve whichever UI calls them, and all the UI-specific bits are nicely decoupled.

  • Your point sounds nice. After all, the JSF service is located at the same level than the Android app, as you said. – Xtreme Biker Feb 9 '16 at 11:40
0

As defined, your 'UI Service' will have to change every time either any of the other two services changes. That's the opposite of encapsulated, and won't scale as you add more services.

And if you don't plan to scale to another few tens to hundreds of services, then you likely picked an inappropriate architecture for your system.

On that point, it is particularly worrying that you regard putting things in the same process as 'coupling'; that is one of those subtly wrong ideas that risks ending up with an un-manageable distributed monolith. Sometimes, the best way two decouple two interacting things is to put them in the same process; then they can use the native language's superior API and dependency management tools instead of relying on a simplistic REST approach.

  • So you're encouraging to divide the UI service and integrate each core related UI part in its core service. Then I assume they're supposed to access the same interface exposed as REST, but the advantage over it is they would be performing in the same language and same process. – Xtreme Biker Feb 9 '16 at 11:59
  • For the example, given, there is no real justification for not putting everything in a single process: processes are not design tools. Maybe your real example is more complicated; what is your team structure? 99% of the time once you know that, you know what your services should be. – soru Feb 9 '16 at 12:46
  • True, my real example is a bit more complicated, not much more, I've got just of 5 of 6 core services right now. You seem to be right in the first statement of your answer, however, the REST API should provide backward compatibility so if I add some operations to it for one specific UI it shouldn't affect the rest of them. – Xtreme Biker Feb 9 '16 at 12:55
  • 2
    Problem is still that virtually any change is going to ripple out through interacting services to the whole system. Which is what makes it a distributed monolith - you can't confidently release changes to service A without retesting services B-F. i suspect you need to either commit to the microservices approach (which means not caring a whit about code duplication or redundancy) or recognize you actually have a single application, so it needs to be a single deployment bundle, so anything other than a single process is pointless overhead. – soru Feb 9 '16 at 13:30
  • agree with You. Is Your sentence "un-manageable distributed monolith" copyrighted? – Jacek Cz May 25 '18 at 9:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.