Log to stdout. Have something like filebeat spool the logs and send to a log aggregator. Completely separates your logging architecture from everything else.
I think you have a few misconceptions. Don't worry, you're not the only one. Most other folks have these same misconceptions. I'll try to help:
Myth #1: "Microservices are useful when your project needs to be highly scalable." This is not true. Microservices can make the problem worse in many cases where you need to communicate with other microservices. This introduces more latency. Scalability is unrelated to microservices architecture.
Myth #2: "Companies that use microservices are cool. " Most likely not. It's just that they think they're Netflix when they aren't. It's a cargo cult. If they're doing microservices and don't have at least a 200+ developers on that same project with multiple data repositories, then they're just doing it for the helluvit and probably making a mess along the way. I've interviewed/been recruited to several companies like that, and I run as fast as possible. Most recent one was 3 guys writing dozens of microservices all hitting the same database and running from the same VM because "it's like, microservices dude. It's gnarly fast!". I've talked to name-brand Silicon Valley companies with 1000s of developers from India and think microservices can make their systems scale better, but still want to use a monolithic relational database.
Yes, you always build your own home project using microservices. Just come up with your own scenario (ex: a fictional banking system). Microservices are really useful when you want to enable developer agility and have a large number of developers working on one large project. Or, if you want to individually update functionality faster than the other features that other teams are working on. If you're a one-man-band, it's going to be hard to see the benefits of microservices.
Well, you'll definitely want to check Sam Newman's newer Monolith to Microservices then.
Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith https://www.amazon.com/dp/B08X7DX23V/ref=cm_sw_r_apan_RT8PNX9JNG8224FNYVGD
Using JWTs and PKC could solve this.
Here's how I'd play this out:
An auxiliary benefit of this approach is that you won't incur additional internal latency in doing intra-service auth checks: your load balancer can pass through the JWT from the client as a request header to the destination microservice.
To verify the incoming JWTs, your services can make a request to a well-known internal URL (or have a rotating keyring of secrets) to verify the incoming JWTs - see [JWKS](https://auth0.com/docs/security/tokens/json-web-tokens/json-web-key-sets).
For a complete implementation you will need to handle refresh tokens. In this instance, the common libraries will need to handle making some request back to the OAuth service to do the refresh and reissue the token, however this is still very achieveable.
Reading back over this, if I'm right and you have groups of agents based upon job type then possibly use State functions? https://aws.amazon.com/blogs/aws/new-aws-step-functions-build-distributed-applications-using-visual-workflows/ When it hits a state and a new Lambda function is called based upon its state then its fully distributed, AWS takes care of this. All the initial microservice needs to do is to start the correct step function for the job type. Then let AWS spin up and process all of the required functions itself. One thing. All of the functions MUST be stateless, if you hold state or share a DB, you're gonna have a bad time
I could be wrong but if you are in .NET ecosystem, I think Tye(https://github.com/dotnet/tye) does the samething like you mentioned in first point.
There is also a package(https://www.nuget.org/packages/Microsoft.AspNetCore.Mvc.Testing) in .NET to help with testing.
You can try ngrok.com, no-ip or dyndns on the server to have a stable domain.
If you can configure stuff on AWS you could give it an Elastic IP that does not change.. You can also setup a domain on route53 to point to this IP.
Hello,
I started developing micro-services using go-micro, but I couldn't figure out how to connect go-micro services from to localhost
to local-docker-compose
.
My local development work flow:
https://cacoo.com/diagrams/kqYosxrpfAQrIWlq/63AFC When I develop one of the service, I stop the service from docker-compose, and start it locally by using go run
.
If run all of services in docker or locally, it works properly, but can't find a way to make it communicate between local and docker. micro services list
can only find service that I run locally, but not in the docker.
Perhaps I need to do some docker-compose configuration, but I can't find document related to this work flow.
Thanks!
Implementing DDD from Vernon is a must-read after Evans:
https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577
It is not exactly focused on microservices. However, the DDD conception "Bounded context" is the key point for microservices.