I would like to get some clarity on terminology of microservices.
Reference to the diagram mentioned below.
All Represents the Microservice Architecture
Microservice - Does it refer the service which are exposed as API to channel [ Be it browser / Native app / Host ] or even the service which not exposed [ Underlying
Generic
Orchestrated
Atomic
As per the diagram, Links from orchestrated to atomic were mentioned.
Does it have to be always a [REST/ HTTP over call] or is it can be normal Java library method call packaged in the same runnable package.
All tutorials says / goes 1 Microservice = 1 Rest based service or anything exposed as controller to be called from
Can we call library or DAO Generic Service also a microservice?
Microservice Architecture ViewPoint
Microservice ViewPoint 2
Comparison
Does it refer the service which are exposed as API to channel or even the service which not exposed
A microservice is a service that serve a business need - they are "Componentization via Services" - componentes of a bigger system, so they don't necessary need to be exposed to external world, but they can be.
Does it have to be always a REST/ HTTP over call, or is it can be normal Java library method call packaged in the same runnable package.
Microservices communicate over network, but it does not have to be HTTP / REST, it can also be a Kafka topic or gRPC or something else. The important part is that they must be independently deployable e.g. you can upgrade a single microservice without needing to change another service at the same time.
See Martin Fowler - Microservices - 9 characteristics for the most commonly accepted definition.
Related
I have an application separated in various OSGI bundles which run on a single Apache Karaf instance. However, I want to migrate to a microservice framework because
Apache Karaf is pretty tough to set up due its dependency mechanism and
I want to be able to bring the application later to the cloud (AWS, GCloud, whatever)
I did some research, had a look at various frameworks and concluded that Quarkus might be the right choice due to its container-based approach, the performance and possible cloud integration opportunities.
Now, I am struggeling at one point and I didn't find a solution so far, but maybe I also might have a misunderstanding here: my plan is to migrate almost every OSGI bundle of my application into a separate microservice. In that way, I would be able to scale horizontally only the services for which this is necessary and I could also update/deploy them separately without having to restart the whole application. Thus, I assume that every service needs to run in a separate Quarkus instance. However, Quarkus does not not seem to support this out of the box?!? Instead I would need to create a separate configuration for each Quarkus instance.
Is this really the way to go? How can the services discover each other? And is there a way that a service A can communicate with a service B not only via REST calls but also use objects of classes and methods of service B incorporating a dependency to service B for service A?
Thanks a lot for any ideas on this!
I think you are mixing some points between microservices and osgi-based applications. With microservices you usually have a independent process running each microservice which can be deployed in the same o other machines. Because of that you can scale as you said and gain benefits. But the communication model is not process to process. It has to use a different approach and its highly recommended that you use a standard integration mechanism, you can use REST, you can use Json RPC, SOAP, or queues or topics to use a event-driven communication. By this mechanisms you invoke the 'other' service operations as you do in osgi, but you are just using a different interface, instead of a local invocation you do a remote invocation.
Service discovery is something that you can do with just Virtual IP's accessing other services through a common dns name and a load balancer, or using kubernetes DNS, if you go for kubernetes as platform. You could use also a central configuration service or let each service register itself in a central registry. There are already plenty different flavours of solutions to tackle this complexity.
Also more importantly, you will have to be aware of your new complexities, but some you already have.
Contract versioning and design
Synchronous or asynchronous communication between services.
How to deal with security in the boundary of the services / Do i even need security in most of my services or i just need information about the user identity.
Increased maintenance cost and redundant side code for common features (here quarkus helps you a lot with its extensions and also you have microprofile compatibility).
...
Deciding to go with microservices is not an easy decision and not one that should be taken in a single step. My recommendation is that you analyse your application domain and try to check if your design is ok to go with microservices (in terms of separation of concenrs and model cohesion) and extract small parts of your osgi platform into microservices, otherwise you mostly will be force to make changes in your service interfaces which would be more difficult to do due to the service to service contract dependency than change a method and some invocations.
I've been reading through the nameko docs, and it is all good and clear, except for one part.
How do you actually deploy your nameko microservice?
I mean, it is clear how we deploy RESTful APIs in flask_restful, for instance. But with nameko?
If two microservices should communicate, how do we move them into the "listening" state?
I am not sure I understand your problem.
For each nameko service you define AMQP_URI constant that point to your RabbitMQ instance.
If each of your services have the same AMQP_URI, it make possible communication through sending rpc calls (where you have a queue per service endpoint) or using pub/sub messaging because service use the same RabbitMQ instance.
You can also have HTTP REST API. You must define endpoint in nameko service with http decorator (see example here: https://nameko.readthedocs.io/en/stable/built_in_extensions.html). In your confguration you have to define PORT for you web server, e.g. port 8000: WEB_SERVER_ADDRESS: 0.0.0.0:8000. And make this port accessible for the World.
Scenario:
Currently, we have multi-tier architecture in this pattern
DBLayer => Tasks to DB
SouthBound => Talks to other devices like router/controller
SrvcLayer => Talks to both SouthBound and DBLayer
UILayer => Talks to UI and SrvcLayer
The application is built on Spring 4.2, Java 8, MongoDB.
Requirement:
We need to decouple SouthBound as a separate App or can say Micro Service.
Issue:
We are thinking of 2 ways
Exposing services in SouthBound as REST API and use them in SrvcLayer.
It will add some latency issue and need to figure out the security part as well.
Use Message queue like RabbitMQ. But these calls have to be synchronous. So I am not sure RabbitMQ will help us.
Which approach will be suitable.
Any other suggestion on how to build this usecase.
In our application we have REST API to communicate UI <-> Backend parts of which are in its own turn connected via AMQP.
Btw RabbitMQ seems to have async supoport RabbitMQ asynchronous support so this may be enough.
Sync work of RabbitMQ is still possible (Is it appropriate to use message queues for synchronous rpc calls via ajax, https://www.rabbitmq.com/tutorials/tutorial-six-java.html) but anyway if you're using AMQP synchronously this will end with having latency so I'd say better use REST
There are a lot of tutorials and articles (including official site) promoting spring boot as a good tool for building microservices.
Let's say we have some rest api endpoint (User profile) which aggregates data from multiple services (User service, Stat service, Friends service).
To achieve this, user profile endpoint makes 3 http calls to those services.
But in Spring, requests are blocking and as I see, the server will quickly run out of available resources (threads) to serve request in such system.
So to me, it as quite inefficient way to build such systems (compared to non-blocking frameworks, like play! framework or node.js)
Do I miss something?
P.S.: I do not mean here spring 5 with its new webflux framework.
No one prevents you from building an asynchronous microservice architecture with Spring Boot :).
Something along these lines:
Instead of one service calling another synchronously, a service can put events to a queue (e.g. RabbitMQ). The events are delivered to services that subscribe to those events.
Using RabbitMQ and its "exchange" concept, the event producing service doesn't even need to the consumers of its events.
A blog post detailing this with Spring Boot code can be found here: https://reflectoring.io/event-messaging-with-spring-boot-and-rabbitmq/
This is not a limitation of Spring rather it is more to do with the Application Architecture.
For instance, the scenario that you have is commonly solved using Aggregate Design Pattern
While this solution is quite prevalent,it has the limitation of being synchronous, and thus blocking. Asynchronous behaviour in such scenarios should be implemented in an application specific way.
Having said that if you have to call other services in order to be able to serve a response to a request from a client(outside), this is typically an architectural problem. It really doesn’t matter if you are using HTTP or asynchronous message passing (with a request-reply pattern), the overall response time for the outside client will be bad
Also, I have seen quite a few applications which uses synchronous REST calls for external clients, but when communication is needed between internal MicroServices, it should always be asynchronous. You can read an interesting paper on this topic here MicroServices Messaging Patterns
I have seen mixed examples of Microservices implemented as worker roles processing requests off a queue and/or as APIs (REST).
Supporting asynchronous scenarios, a queue can be utilized, with a simple dumb queue listener forwarding the request to a Microservice REST API, where as synchronous scenarios would call the REST API directly.
The term Microservice is vaguely defined I think; do people consider them APIs (e.g. RESTful services) or as any abstract service processing requests, however that request was provided ?
Your microservices can be a small application that exposes a few RESTful endpoints, or it can be a background worker that reaps a queue. It can even be an AWS Lambda function that's invoked on some event.
The point is that your application is composed of several smaller applications, thus allowing you a greater amount of agility when it comes to deploying code, programming languages, frameworks, etc.