I'm interesed in design microservices in two different environments, Spring and NodeJs.
While in Spring it's easy to find plenty of resources about Netflix Eureka (it's probably the number one with Consul), in NodeJs I found more opportunities to allow microservices to communicate themselves and there isn't a way to go.
These are some methods to design a microservice architecture:
static ip/port map in code or config file
through DNS
Service Discovery (Eureka/Consul)
P2P (like blockchain?) [also seneca?]
Regarding NodeJs on youtube you can find many videos, one that got my attention is the video of the seneca's father Richard Rodger titled "NodeJs microservices without a registry".
The problem with seneca is that to make it work you need a base/main microservice that to me it looks like service discovery since all the other microservices must know its ip and port.
From author website
At the moment, our implementation still depends on “well-known” entry
points. You have to run a few base nodes at predetermined locations,
so that microservices know where to look to join the network – Peter
is fixing that one for us, and soon the network will be completely
self-managing.
Maybe after Peter will finish it should look like a P2P microservices architecture, where the knowledge of microservices will be spread with SWIM protocol, it is right?
The other difference is that Seneca use pattern matching to forward the message between microservices, but it always travel through the base/main microservice.
Seneca without service registry, isn't it a service registry itself (know TAGS and where they are instead of IPs)?
Sorry for no code, but I still be in a theorical env at the moment.
Related
Micro-frontend is a microservice approach to frontend web development.
Microservice is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.
But
What are the main differences beetween micro-frontend and microservices?.
Microservices are related to back-end side functionalities while
Microfrontends is related to the frontend & the idea is to divide your application on the client side.
This division is especially helpful when you have a group of many developers working over the same product/codebase.
Take a look at the below links for understanding the difference, the idea of micro-frontends & their pros and cons.
https://www.youtube.com/watch?v=BuRB3djraeM
https://www.youtube.com/watch?v=Bnmy5zMY14s
https://www.youtube.com/watch?v=asqgKaUMXq0
Just naming. Microfrontend is client version of microservices. You can implement your frontend as multiple applications (microfrontends). On backend side you create multiple deployables (microservices) to build an application. Of course, there are some patterns and best practices (API Gateway, Service Discovery etc.) for microservices and microfrontends which may not be applicable to one or differ between each other. However the main idea is same.
I need your help in Loopback Framework.
Actually, my need is how we can achieve Microservices related functionality with Loopback Framework.
Please share any links/tutorials/knowledge if you have any.
I have gone through below links,
https://strongloop.com/strongblog/creating-a-multi-tenant-connector-microservice-using-loopback/
I have downloaded the related demo from below links but doesn't work it.
https://github.com/strongloop/loopback4-example-microservices
https://github.com/strongloop/loopback-example-facade
Thanks,
Basically it depends on your budget and size of your system. You can make some robust and complex implementations using tools like Spring Cloud or KrakenD. As a matter of fact, your question is too broad. I've some microservices architecture knowledge and I can recommend just splitting your functionality into containerized solutions, probably orchestrated by Kubernetes. In that way, you can expose for example, the User microservice with loopback, and another Authentication microservice with loopback and/or any other language/framework.
You could (but shouldn't) add communication between those microservices (as you should expose some REST functionality) with something like gRPC.
The biggest cloud providers have some already made solutions, eg AWS has ECS or Fargate. For GCP you have Kubernetes.
We have created an open source catalog of microservices which can be used in any microservice project using LB4. Also, you can get an idea of how to create microservices using LB4. https://github.com/sourcefuse/loopback4-microservice-catalog
In theory I understand how Microservices work and why they can be helpful in various cases but I still don´t get how it works in practice.
Let´s say there´s an online shop based on a CMS as a monolith application.
And there´s now the need to run the online shop in a MIcroservices architecture.
How would this Microservices architecture differ technically from the current, monolith, architecture?
For example, I pick out the productsearch.php. If i want to scale this function, normally I had to set up a new server and copy the whole CMS ressources folder to it for loadbalancing.
And with Microservices, productsearch.php would be a single Microservice I guess, and I would have to just copy this php file to scale without the need to copy other ressources?
I have tried to explain it using this diagram of a fictitious CMS. With micro services architecture, we can independently scale each micro service. Each micro service may be developed by a different team, they may be even developed using different technology. But we great flexibility comes great maintenance overhead, I believe it is worth it as most of it can be automated.
Put simply, each module in a molithic application is a potential candidate for microservice. Howerver, microservices can be more granular than a traditional module.
This provides a good job at explaining how to decompose your monolithic application. http://microservices.io/patterns/decomposition/decompose-by-business-capability.html
Technically and conceptually, a microservice is independent of other services (where in a monolith you'd have modules with inter-dependencies).
Technically, a microservice built on modern microservices platforms (such as Node.JS, Spring Boot or .NetCore) will be more easily able to take advantages of containerization systems (such as Docker), perhaps supported by service registry and configuration management technologies (such as Kubernetes, ZooKeeper, Eureka and so on).
The advantage of containerization is that it'll be easier to scale-out (add more containers). Going further, the whole microservice / containerization concepts, and related technologies, also help enable things like CI/CD.
I am new to Spring-Boot(Cloud) and going to work on one new project.
Our project architect have designed this new application like this:
One front end Spring boot application(which is also microservice) with Angular-2.
One Eureka server, to which other microservices will connect.
ZUUL proxy server, which will connect to Front end and mircoservices.
Now, followings are the things I am confuse about and I can't ask him as he too senior to me:
Do I need to have separate ZUUL proxy server ? I mean, what is the pro and cons of using same front end application as ZUUL server?
How MicorService-1 will communicate with Node's MicroService-1? Some blogs suggesting the Sidecar. But again, why ? because I can directly invoke ReST api of NodeJS-1 from the Microservice-1.
(I know, this is very tough to guess but still asking) NodeJS services(which are not legacy services) are suppose to call some third party api or retrieve data from DB.
Now, what I am not getting is why we need NodeJS code at all? Why can't we do the same in the microservices written in Java?
Can anyone who have worked with similar kind of scenario shed some light on my doubts?
I do not have the full context of the problem that you are trying to solve, therefore answers bellow are quite general, but still may be useful:
Do I need to have separate ZUUL proxy server? I mean, what is the pro and cons of using same front end application as ZUUL server?
Yes, you gonna need a separate API Gateway service, which may be Zuul (or other gateways, e.g tyk.io).
The main idea here is that you can have hundreds or even thousands of microservices (like Amazon, Netflix, etc.) and they can be scattered across different machines or data centres. It would be really silly to enforce your API consumers (in your case it's Angular 2) to memorise all the possible locations of each microservice. Better to have one API Gateway that knows about all the services under it, so your clients can call your gateway and have access to the underlying services through one single place. Also having one in your system will decouple your clients from your services, so it's possible to evolve them independently.
Another benefit is that you can have access control, logging, security, etc. in one single place. And, BTW, I think that you are missing one more thing in your architecture - it's Authorization Server. A common approach in building security for microservices is OAuth 2.0.
How MicorService-1 will communicate with Node's MicroService-1? Some blogs suggesting the Sidecar. But again, why? because I can directly invoke ReST API of NodeJS-1 from the Microservice-1.
I think you could use Sidecar, but I have never used it. I suppose that the question 'why' is related to the Discovery Service (Eureka in your architecture).
You can't call microservice NodeJS-1 directly because there may be several instances of NodeJS-1, which one to call? Furthermore, you can't know whether service is down or alive at any given point in time. That's why we use Discovery Services like Eureka - they handle all of these. When any given service has started, it must register itself in Eureka. So if you have started several instances of NodeJS-1 they all will be registered in Eureka and whenever Microservice-1 wants to call NodeJS-1 service it asks Eureka for locations of live instances of NodeJS-1. The service then chooses which one to call.
(I know, this is very tough to guess but still asking) NodeJS services(which are not legacy services) are suppose to call some third party api or retrieve data from DB.
Now, what I am not getting is why we need NodeJS code at all? Why can't we do the same in the microservices written in Java?
I can only assume that the NodeJS has been chosen because it has an outstanding performance for IO operations, including HTTP requests that may come in hand when calling 3-rd party services. I do not have any other rational explanations for this.
In general, microservices give you a possibility to have your microservices written in different languages and it's cool indeed since each language solves some problems better than the other. On the other hand, this decision should be made with caution and answer the question - "do we really need a new language in our stack to solve problem X?".
I'm new to microservices. I envision them as a set of processes running in two or more machines (I suppose for a given process two instances must be run in separate machines for reliability). In that setup, depending on the kind of clients I have there may be one process working as a TCP server serving on a specific high port and speaking a non-HTTP protocol.
However, for my low-bandwidth, testing purposes, I haven't found a free cloud service which provides that kind of environment (machines to run processes on – say, Java on Linux – while keeping a high port open).
Maybe the facilities I'm expecting are only available to paying customers, or maybe implementing a microservice architecture in the cloud goes beyond simply running processes in machines and sharing a database? Could someone clarify? (and if possible direct me to one such free service)
Yes, you are right when you say Microservices are more about independent service (processes) that can be deployed in one or more cloud machines. Each service can communicate to other using non-http protocol like Message brokers, Thrift, Remote Procedure call (RPC) etc.
As the architecture point of view, services should mostly be decoupled enough to handle complexity of distributed computing. see the image on Microservices Architecture link
There's a concept of API Gateway which could be used for authentication and service registration and discovery purpose.
Coming back to your question, you can test microservices on single cloud (by running each service on different port) and use API Gateway to discover the service path for references here are the links which are worth to look at these.
For concept see links: Microservices.io and stackoverflow question
For Implementation: zookeeper and Auth0 (this is what i'm using)
If you are java lover great to look at infoQ article
Some of the free source that might can help in building and testing microservices are: Google App Engine, hook.io