in my humble opinion, two of the most tough aspects to deal with in a microservices based architectures are intra-services communications and developing GUIs.
With respect to first topic, communication, most of documentation I've read is about using REST everywhere. But handling JSON objects isn't so easy with standard Java classes - Json isn't a first class citizen in Java world.
Does Spring offer any out-of-the box facility to helping developer managing JSON object effectively ? What about discover and consuming other microservices API ? And using MTOM as a service bus ?
The second aspect is about exposing GUI Interfaces. Let's suppose we have a complex application build upon several microservices. Should be the GUI (probabily, a web gui) exposed as a separated microservice ?
Are there any best - practice ?
Are these arguments covered in your book ?
Thanks for posting. Let me see if I can answer your questions in order.
1. Spring supports JSON serialization/deserialization through the Jackson serializer. Spring will automatically serialize all incoming and outgoing requests from a POJO if you use the@RestController annotation while defining your service routes. For most of my interfaces, I never have to go beyond using out of the box serialization. I agree with you that Java JSON manipulation can be pain, especially since dynamic languages like Groovy and Clojure make it so easy.
2. In a microservice application, the GUI application is usually deployed as a completely separate application in a separate set of containers. The GUI should be communicating with the services only through their JSON/REST interfaces. One of the questions I often encounter is whether or not the GUI should handle orchestration across multiple services. I usually like to keep my microservice invocations from simple from the GUI. Thus, if I have to invoke multiple services to complete a transaction, I will wrap the entire process with another microservice so that the GUI only has one service to call.
3. Service discovery - Microservices do not have the concept of a service discovery like a SOAP-style catalog. Instead, services like Eureka allow for service discovery by allowing individual service instances to register themselves with a service discovery engine. Then API libraries like Feign and Ribbon allow you to query the service discovery engine using the a service name key. Service discovery allows you to discover the location of a service, but they tend not to provide the "cataloging" features advertised in SOAP UUID service discovery engines.
4. MTOM- We use messages quite a bit in our microservices application. We use Kafka as a backbone for the messages. Usually we use messages to notify of of important system events and data state changes. Messaging is an important part of a microservice architecture because it allows us to do complex process independently of on another. For example, one of the major pieces of functionality that I am working on right now is our upgrade functionality for our customers. We use messaging heavily to convey the state of the upgrades for the customer and use Kafka, AWS SQS and AWS SWF as the process choregrapher.
My books covers most of this topics and provides hands on examples. Chapter 2 deals with microservice developement, Chapter 4 service discovery and Chapter 8 on messaging.
I hope thats answers your question.
John Carnell - Senior Engineer, Genesys PureCloud Division
Author of Spring Microservices in Action
John, thanks a lot for your reply. Let me say that yours is one of the most clarifying post about microservices I've read so far !
I've another doubt about GUI developing. Would it be OK to have the whole GUI in a single microservices ? The problem is that, of course, you have to expose your GUI on a standard HTTP(s) port; if any service provides its own GUI, I wonder what's the best practice to build various pieces together.
Another question is about service discovery. Ok, with Feign (or similar frameworks) I would be able to discover where a service is; but with respect to a client service perspective, is there any mechanism to build up a service interface stub ?