5 ms·

Others already pointed a lot of things out. I will throw in my 2 cents. Micro services should not be directly talking to each other. This couples them in a way

Others already pointed a lot of things out. I will throw in my 2 cents. Micro services should not be directly talking to each other. This couples them in a way that a small API change can be breaking. Instead use a messaging solution so that each service is passing messages and grabbing messages off a queue to do work. This is the easiest way to prevent coupling. It also allows you to version messages if need be and you can deploy a new service to consume those messages. We use JSON, so we can add to a message with no ill effect, and we are careful about removing any required attributes. So we haven't had a need to version messages, but the ability is there if we find it is needed at some point. Adding messaging does increase complexity in some ways, but once you pass having a handful of services this is the easiest way to manage it. As a side note. In our solution we have an API that the website and soon to come mobile app tie to. That API interfaces directly with some data schemas but in many places it simply adds messages to a queue for processing.

mattmanser 11y ago
I don't get it, that's still an API. All that will happen is that it won't be able to process the message, instead of not being able to serve the request. This thread seems to be full of mad people determined to make simple concepts incredibly complex.
- wumbernang 11y ago
  This. We use microservices but we do allow services to call services. All endpoint and data contracts exist separately to services and are used by both the service provider (server) and a consumer so all internal contracts are enforced. That and a fuck ton of integration testing make it work. And to be honest I really don't like the architecture. It's much much much better to serve hundreds to thousands of smaller instances of your application than one massive thing divided into lots of services. This is a ghetto I wish we weren't in to be honest.
  - davismwfl 11y ago
    I have seen places where it makes sense to call directly to another service, and we violate the message rule sometimes ourselves. But in general I really try to avoid it as when we started we had a lot of it and the interdependencies. With that solution build and deployment became worse then just having a monolithic application, and we were ready to kill each other. I'd also say, microservices are not for every problem, too many people are applying them to the wrong problems (but that is how we all generally learn limits). And a web/app API is generally not where I'd say deploy microservices, but the backend services for that API would make sense. That is exactly what we built now that we are on version 3 of this architecture. API for us is now a totally different beast than the microservices and the whole solution has become a much more manageable with way less churn and confusion. Not to mention deployments are way easier.
- speedkills 11y ago
  I also wonder about the real need to deploy mix and match versions. I like using a mono-repo, actually continuously integrating and then blue-green deploying any set of services that has passed my acceptance criteria. Roll the full set forward, or roll them all back, but I don't want to get into a situation where due to keeping some changes and rolling back others I end up with an untested combination of services deployed. If I had to do that then I would definitely be looking at versions message schemas, or contracts like Pact/Pacto but it seems much simpler to just deploy a full set of tested and known to work together services at once than to version each one. Someone else referred to this pattern as a distributed monolith but I disagree. I still gain the benefits of scaling the size and number of instances of my micro services independently, but remove a lot of the burden of independent versioning and keeping track of the version compatibility matrix. For anyone interested in a simpler path I think there is a lot of useful information in the book Continuous Delivery by Jez Humble and Paul Hammond.
- baq 11y ago
  > This thread seems to be full of mad people determined to make simple concepts incredibly complex. all microservice architectures look like that sometimes after a day of fighting them. source: have ~30 microservices in a project at $WORK
- davismwfl 11y ago
  To me there is a distinct difference between an API and a microservice. A microservice should be self contained and have all the data it needs to do its job either passed to it or within its own data context (database/cache etc). This is what makes it simple to scale, manage and keep isolated. The easiest example of a microservice is an email service that all it does it pick up an email off a queue and send it out the door and then send a message that it is complete, with possibly a return from the ESP or SMTP communication. So keeping it super small, limited functionality makes it easy to debug and simple to scale and manage. An API might have dozens of endpoints to serve its client(s) and many times cannot be async in nature as a client needs a response now. For example, logging into a website or application, I need to know if the user is authenticated now, not wait for a message to make its way through a series of services. So I don't consider and API and microservices to be the same, although I agree some functionality could be used in either one sometimes so it can be a little confusing. The only thing that I do agree they share is a contract, in the case of the API it is the endpoint and data, in the case of the service/message it is the message itself.
  - mattmanser 11y ago
    Email is one of the few parts of any system that always needs to use a queue, because of the need to be asynchronous and to occasionally delay/retry. It's not a great example. Your distinction might make sense to you, but it's technically wrong. An API means a specific thing. You're almost saying that a car door and a house door aren't both doors. A library has an API and a directly called microservice has an API and a message based microservice has an API. A 'contract', as you call it, is an API.

mattmanser 11y ago

I don't get it, that's still an API. All that will happen is that it won't be able to process the message, instead of not being able to serve the request. This thread seems to be full of mad people determined to make simple concepts incredibly complex.

wumbernang 11y ago
This. We use microservices but we do allow services to call services. All endpoint and data contracts exist separately to services and are used by both the service provider (server) and a consumer so all internal contracts are enforced. That and a fuck ton of integration testing make it work. And to be honest I really don't like the architecture. It's much much much better to serve hundreds to thousands of smaller instances of your application than one massive thing divided into lots of services. This is a ghetto I wish we weren't in to be honest.
- davismwfl 11y ago
  I have seen places where it makes sense to call directly to another service, and we violate the message rule sometimes ourselves. But in general I really try to avoid it as when we started we had a lot of it and the interdependencies. With that solution build and deployment became worse then just having a monolithic application, and we were ready to kill each other. I'd also say, microservices are not for every problem, too many people are applying them to the wrong problems (but that is how we all generally learn limits). And a web/app API is generally not where I'd say deploy microservices, but the backend services for that API would make sense. That is exactly what we built now that we are on version 3 of this architecture. API for us is now a totally different beast than the microservices and the whole solution has become a much more manageable with way less churn and confusion. Not to mention deployments are way easier.
speedkills 11y ago
I also wonder about the real need to deploy mix and match versions. I like using a mono-repo, actually continuously integrating and then blue-green deploying any set of services that has passed my acceptance criteria. Roll the full set forward, or roll them all back, but I don't want to get into a situation where due to keeping some changes and rolling back others I end up with an untested combination of services deployed. If I had to do that then I would definitely be looking at versions message schemas, or contracts like Pact/Pacto but it seems much simpler to just deploy a full set of tested and known to work together services at once than to version each one. Someone else referred to this pattern as a distributed monolith but I disagree. I still gain the benefits of scaling the size and number of instances of my micro services independently, but remove a lot of the burden of independent versioning and keeping track of the version compatibility matrix. For anyone interested in a simpler path I think there is a lot of useful information in the book Continuous Delivery by Jez Humble and Paul Hammond.
baq 11y ago
> This thread seems to be full of mad people determined to make simple concepts incredibly complex. all microservice architectures look like that sometimes after a day of fighting them. source: have ~30 microservices in a project at $WORK
davismwfl 11y ago
To me there is a distinct difference between an API and a microservice. A microservice should be self contained and have all the data it needs to do its job either passed to it or within its own data context (database/cache etc). This is what makes it simple to scale, manage and keep isolated. The easiest example of a microservice is an email service that all it does it pick up an email off a queue and send it out the door and then send a message that it is complete, with possibly a return from the ESP or SMTP communication. So keeping it super small, limited functionality makes it easy to debug and simple to scale and manage. An API might have dozens of endpoints to serve its client(s) and many times cannot be async in nature as a client needs a response now. For example, logging into a website or application, I need to know if the user is authenticated now, not wait for a message to make its way through a series of services. So I don't consider and API and microservices to be the same, although I agree some functionality could be used in either one sometimes so it can be a little confusing. The only thing that I do agree they share is a contract, in the case of the API it is the endpoint and data, in the case of the service/message it is the message itself.
- mattmanser 11y ago
  Email is one of the few parts of any system that always needs to use a queue, because of the need to be asynchronous and to occasionally delay/retry. It's not a great example. Your distinction might make sense to you, but it's technically wrong. An API means a specific thing. You're almost saying that a car door and a house door aren't both doors. A library has an API and a directly called microservice has an API and a message based microservice has an API. A 'contract', as you call it, is an API.