6 ms·

Not knocking the OP, or his/her effort, but I think the number of microservice frameworks exceeds the number of organizations that actually have the problems th

Not knocking the OP, or his/her effort, but I think the number of microservice frameworks exceeds the number of organizations that actually have the problems that microservice architecture was designed to solve. We're doing it for the project I'm working on at work, and it's my opinion a colossal waste of engineering time and effort. We're a big company, but we're not FAANG. Our user-base will never be even likely to be 100k users total. But hey we're doing this in the name of industry's current 'best-practice.' I can't wait for the microservice & scrum trends to die off.

alttab 7y ago
Micro services don't only provide horizontal scaling but also operational scaling, including risk of deployments, downtime, release coordination and contributions from multiple workstreams or teams. Sometimes applications with only 100s of users need microservices simply due to the complexity and range of the workloads. The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" to pull from a queue.
- allover 7y ago
  > Micro services don't only provide horizontal scaling but also operational scaling I think it's more accurate to say that they don't necessarily provide any horizontal scaling, but can provide operational scaling. This is only if there's some natural team divide, and the impact of the introduced complexity does not outweigh the benefits of the teams being able to test and deploy independently. Sadly in most cases I have come across, this is not the case -- the complexity introduced and/or problems caused by lack of ecosystem maturity outweigh any potential organisational benefit. > release coordination Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant. > The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" I agree queue-based background work is a case where services are a good fit (sadly this is not what a lot of people are doing with their codebases when they "go microservices"), ... but it can also be simpler to deploy the same exact same monolithic codebase to a worker, and only execute the part that is performing your async task. (If your worker is a lambda, sure, that isn't going to work.)
  - weberc2 7y ago
    > Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant. If you're operating a monolith, every release requires coordination from every team, no?
    - allover 7y ago
      I was referring to the act of deployment itself. A single deployment of a monolith, without needing to ensure a dependent service whose pipeline is owned by another team is "deployed first", can be a lot easier to organise. As I say it can depend a lot on other factors like repo organisation, pipeline maturity. I struggle to see how release coordination can be something microservices inherently improve upon, do you have an example comparison perhaps?
- weberc2 7y ago
  Right. I don't know what issues people are having specifically with microservices, but we're in a sort of hybrid place where we have about 30 engineers split into a few teams. We collectively build/operate ~7 microservices and a dozen lambda functions, queues, etc, all of which are deployed together about ten times per day. This has been working very well for us, and I would like to see us buy into the microservice model more with teams that each operate one or two services instead of each team committing a little bit to every service. In that model, each team would only need to worry about their own service(s) instead of interactions across every service (or rather, this would be less of a concern). The only piece that doesn't work so well for us is local development; we've tried Docker Compose and PM2 to run the whole fleet of services in either containerized and native-process configuration (respectively), but the former is slow due to terrible Docker for Mac filesystem performance and the latter introduces all sorts of environment sanitization/consistency issues.
- JustSomeNobody 7y ago
  >The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" to pull from a queue. That’s a multi process architecture. We’ve done that for ages. Multiple processes doing what the do and communication is via TCP or named pipes.
- lucidone 7y ago
  Why can't you spin up a new instance of the monolith and designate it as the "queue worker"? I've done this before with both Laravel and Rails and it worked well enough while keeping things simple.
glouwbug 7y ago
Similar. A place I worked at sharded it's SQL database into one microservice per database table. It ended up being something like 70 docker containers across 4 docker machines. Kicker was this was across 6 repositories. We had much less than 100k users. I'm all for microservices dying out. It's an awful fad. Making 6 pull requests to add a function argument should not be a thing.
- Ididntdothis 7y ago
  God be with the poor people who will have to maintain these systems in a few years when they are legacy and run on old tech. If you think maintains COBOL code is bad then this will be a lot of “fun”.
  - tonyedgecombe 7y ago
    They will just re-write them in the framework or pattern du jour.
- shantly 7y ago
  Jee. Sus. Why? What benefit did anyone think that would have? Better than half the point of using SQL goes out the window if you can’t query across tables.
  - sethammons 7y ago
    Wait until you have half a dozen teams or other services directly accessing your tables and now you need to update the schema or data container for scaling reasons, but you can't because they don't have the time to update their access patterns. Or the team that thoroughly misunderstood how the data was to be used and built their tables and workflows on your tables, forever linking their structure together. Far better to expose data through APIs if you have multiple teams doing their own things in different code bases.
    - shantly 7y ago
      I’m familiar with patterns for divvying up DBs along lines of responsibility and access needs, but the described situation was one per table.
Hitton 7y ago
You are right, that for most use cases using microservices isn't necessary, but it doesn't mean they can't be still useful. Although there is some added cost in the beginning, providing separation of concerns can be quite useful for security and in later phases it keeps the monolith from growing too big and difficult to maintain/extend. I see microsevices as return to the Unix philosophy: >Write programs that do one thing and do it well. >Write programs to work together.
- roganartu 7y ago
  I would argue that, unless you are supporting many developers working on the same project simultaneously (as in, hundreds if not thousands), that microservices will actually slow development without improving quality or robustness. Many things are significantly easier in a monolith. Integration testing, reasoning (and verifying with tests) about how components interact, refactoring of interfaces etc. As soon as you pull components out into microservices many assumptions developers may not even realise they make about developing in a monolith go out the window.
  - PopeDotNinja 7y ago
    Every microservice you carve out of a monolith gives you at least 2 public APIs you didn't have to worry about before, and makes local development that much more complicated. I had a situation where I needed spin up 20 microservices just to wire up an A/B test for marketing, and everyone kept asking me what was taking so long while refusing to listen to the trade-offs of their request. Good times. I vote for punting in microservices until the value proposition is clear. Otherwise you just end up with a macrolith that makes you dream of monolithic good old days
    - cle 7y ago
      Of course, this should have been the approach from the beginning, and it boggles my mind why people pick technologies or paradigms without considering their requirements and the tradeoffs of their technical decisions. I think part of it is because of the hype machine, where people only talk about how awesome things are that they invented, instead of talking about what problems it solves, what it doesn’t solve, and what its tradeoffs are. If you are reading something to evaluate a technology and it doesn’t talk about all three of those things, discard what you’re reading, because it will mislead you.
grepthisab 7y ago
We're small and early, but I've really enjoyed starting with microservices from the beginning. Each team simply exposes a grpc endpoint to everyone else and can otherwise be off sprint schedule from other teams, make generally whatever tech decisions make sense etc. Deployment velocity has been higher that other companies I've worked with.
diamondo25 7y ago
The only reason we have standalone components in our setup, is due to they really pick stuff to do and process it. Additionally, they can work on their own and can be updated independently. This of course requires the protocol between the systems to be backwards compatible.
chuhnk 7y ago
OP here. I agree with you completely. People shouldn't be building these frameworks. Let's rally around one or two frameworks per language where appropriate and drive that as the common development method, as we do for infrastructure. I'll also mention that yes, I agree, in most cases microservices are not the answer. This really comes down to the natural evolution of companies that scale to 50+ engineers split across multiple teams and continuing to grow. The software architecture should model after the org and allow teams to execute independently. If this is possible with monolithic architectures or anything else then that should be the approach taken. In my case, I came from Google and Hailo, environments in which scale mattered on all levels and I didn't see the tools out there (back in 2015) to solve these problems for everyone else. Rails is for Ruby. Spring is for Java. Micro is for Go I see a world in which Micro can be used to write even a single service with a model that can scale to dozens. But more importantly I want to help unlock the reuse of services and the power of what microservices enabled for me at Hailo and what I've seen it do for others.
alexellisuk 7y ago
Curious if you use Kubernetes?
jrockway 7y ago
People have been using microservices for decades. Think about the UNIX filesystem. Applications don't know anything about writing to disk blocks, the filesystem service handles that. And the tools that interact with the filesystems can stay very focused to the task at hand. cp only knows how to copy files; ls only knows how to list directories. If you want to add a new feature to ls, you need not worry about breaking cp. On the "web application" side, we've also been doing the same thing since the LAMP days. Your web app has no understanding of how to efficiently store records; the database service handles that. Your web app has no idea how to efficiently maintain TCP connections from a variety of web browsers all using slightly different APIs; your frontend proxy / load balancer / web server handles that. All your app has to do is produce HTML. It's popular because it works great. You can change how the database is implemented and not break the TCP connection handling of the web server. And people are doing that all the time. All "microservices" is is doing this to your own code. You can write something and be done with it, then move on to the next thing. This is the value -- loose coupling. Well-defined APIs and focused tests mean that you spend all your time and effort on one thing at a time, and then it's done. And it scales to larger organizations; while "service A" may not be done, it can be worked on in parallel with "service B". That said, I certainly wouldn't take a single team of 4 and have them write 4 services that interact with each other concurrently. That isn't efficient because not enough exists for anyone to make progress on their individual task, unless it's very simple. But if you do them one at a time, you gradually build a very reliable and maintainable empire, getting more and more functionality with very little breakage. The problem that people run into is that they act as the developers of these services without investing in the tooling needed to make this work. You need to have easy-to-use fakes for each service; so you don't have to start up the entire stack to test and play with a change in one service. You need to collect all the logs and store them where you can see all of them at once. You need monitoring so you can see what components aren't interacting correctly (though monoliths need this too). You need distributed tracing so you can get an idea of why a particular high-level request went wrong. All these things are available off the shelf for free and can be configured in a day or two (ELK, Jaeger, Prometheus, Grafana). (The other problem that people run into is bad API design. There is no hack that works around bad API design in microservices; your "// XXX: this is global for horrible reasons" simply isn't possible. You have to know what you want the API surface to look like, or it's going to be a disaster. It's just as much of a disaster in monoliths, though; this is how you get those untestable monstrosities that break randomly every release. Microservices make you fail now, monoliths make you fail later.)

alttab 7y ago

Micro services don't only provide horizontal scaling but also operational scaling, including risk of deployments, downtime, release coordination and contributions from multiple workstreams or teams. Sometimes applications with only 100s of users need microservices simply due to the complexity and range of the workloads. The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" to pull from a queue.

allover 7y ago
> Micro services don't only provide horizontal scaling but also operational scaling I think it's more accurate to say that they don't necessarily provide any horizontal scaling, but can provide operational scaling. This is only if there's some natural team divide, and the impact of the introduced complexity does not outweigh the benefits of the teams being able to test and deploy independently. Sadly in most cases I have come across, this is not the case -- the complexity introduced and/or problems caused by lack of ecosystem maturity outweigh any potential organisational benefit. > release coordination Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant. > The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" I agree queue-based background work is a case where services are a good fit (sadly this is not what a lot of people are doing with their codebases when they "go microservices"), ... but it can also be simpler to deploy the same exact same monolithic codebase to a worker, and only execute the part that is performing your async task. (If your worker is a lambda, sure, that isn't going to work.)
- weberc2 7y ago
  > Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant. If you're operating a monolith, every release requires coordination from every team, no?
  - allover 7y ago
    I was referring to the act of deployment itself. A single deployment of a monolith, without needing to ensure a dependent service whose pipeline is owned by another team is "deployed first", can be a lot easier to organise. As I say it can depend a lot on other factors like repo organisation, pipeline maturity. I struggle to see how release coordination can be something microservices inherently improve upon, do you have an example comparison perhaps?
weberc2 7y ago
Right. I don't know what issues people are having specifically with microservices, but we're in a sort of hybrid place where we have about 30 engineers split into a few teams. We collectively build/operate ~7 microservices and a dozen lambda functions, queues, etc, all of which are deployed together about ten times per day. This has been working very well for us, and I would like to see us buy into the microservice model more with teams that each operate one or two services instead of each team committing a little bit to every service. In that model, each team would only need to worry about their own service(s) instead of interactions across every service (or rather, this would be less of a concern). The only piece that doesn't work so well for us is local development; we've tried Docker Compose and PM2 to run the whole fleet of services in either containerized and native-process configuration (respectively), but the former is slow due to terrible Docker for Mac filesystem performance and the latter introduces all sorts of environment sanitization/consistency issues.
JustSomeNobody 7y ago
>The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice" to pull from a queue. That’s a multi process architecture. We’ve done that for ages. Multiple processes doing what the do and communication is via TCP or named pipes.
lucidone 7y ago
Why can't you spin up a new instance of the monolith and designate it as the "queue worker"? I've done this before with both Laravel and Rails and it worked well enough while keeping things simple.

glouwbug 7y ago

Similar. A place I worked at sharded it's SQL database into one microservice per database table. It ended up being something like 70 docker containers across 4 docker machines. Kicker was this was across 6 repositories. We had much less than 100k users. I'm all for microservices dying out. It's an awful fad. Making 6 pull requests to add a function argument should not be a thing.

Ididntdothis 7y ago
God be with the poor people who will have to maintain these systems in a few years when they are legacy and run on old tech. If you think maintains COBOL code is bad then this will be a lot of “fun”.
- tonyedgecombe 7y ago
  They will just re-write them in the framework or pattern du jour.
shantly 7y ago
Jee. Sus. Why? What benefit did anyone think that would have? Better than half the point of using SQL goes out the window if you can’t query across tables.
- sethammons 7y ago
  Wait until you have half a dozen teams or other services directly accessing your tables and now you need to update the schema or data container for scaling reasons, but you can't because they don't have the time to update their access patterns. Or the team that thoroughly misunderstood how the data was to be used and built their tables and workflows on your tables, forever linking their structure together. Far better to expose data through APIs if you have multiple teams doing their own things in different code bases.
  - shantly 7y ago
    I’m familiar with patterns for divvying up DBs along lines of responsibility and access needs, but the described situation was one per table.

Hitton 7y ago

You are right, that for most use cases using microservices isn't necessary, but it doesn't mean they can't be still useful. Although there is some added cost in the beginning, providing separation of concerns can be quite useful for security and in later phases it keeps the monolith from growing too big and difficult to maintain/extend. I see microsevices as return to the Unix philosophy: >Write programs that do one thing and do it well. >Write programs to work together.

roganartu 7y ago
I would argue that, unless you are supporting many developers working on the same project simultaneously (as in, hundreds if not thousands), that microservices will actually slow development without improving quality or robustness. Many things are significantly easier in a monolith. Integration testing, reasoning (and verifying with tests) about how components interact, refactoring of interfaces etc. As soon as you pull components out into microservices many assumptions developers may not even realise they make about developing in a monolith go out the window.
- PopeDotNinja 7y ago
  Every microservice you carve out of a monolith gives you at least 2 public APIs you didn't have to worry about before, and makes local development that much more complicated. I had a situation where I needed spin up 20 microservices just to wire up an A/B test for marketing, and everyone kept asking me what was taking so long while refusing to listen to the trade-offs of their request. Good times. I vote for punting in microservices until the value proposition is clear. Otherwise you just end up with a macrolith that makes you dream of monolithic good old days
  - cle 7y ago
    Of course, this should have been the approach from the beginning, and it boggles my mind why people pick technologies or paradigms without considering their requirements and the tradeoffs of their technical decisions. I think part of it is because of the hype machine, where people only talk about how awesome things are that they invented, instead of talking about what problems it solves, what it doesn’t solve, and what its tradeoffs are. If you are reading something to evaluate a technology and it doesn’t talk about all three of those things, discard what you’re reading, because it will mislead you.

grepthisab 7y ago

We're small and early, but I've really enjoyed starting with microservices from the beginning. Each team simply exposes a grpc endpoint to everyone else and can otherwise be off sprint schedule from other teams, make generally whatever tech decisions make sense etc. Deployment velocity has been higher that other companies I've worked with.

diamondo25 7y ago

The only reason we have standalone components in our setup, is due to they really pick stuff to do and process it. Additionally, they can work on their own and can be updated independently. This of course requires the protocol between the systems to be backwards compatible.

chuhnk 7y ago

OP here. I agree with you completely. People shouldn't be building these frameworks. Let's rally around one or two frameworks per language where appropriate and drive that as the common development method, as we do for infrastructure. I'll also mention that yes, I agree, in most cases microservices are not the answer. This really comes down to the natural evolution of companies that scale to 50+ engineers split across multiple teams and continuing to grow. The software architecture should model after the org and allow teams to execute independently. If this is possible with monolithic architectures or anything else then that should be the approach taken. In my case, I came from Google and Hailo, environments in which scale mattered on all levels and I didn't see the tools out there (back in 2015) to solve these problems for everyone else. Rails is for Ruby. Spring is for Java. Micro is for Go I see a world in which Micro can be used to write even a single service with a model that can scale to dozens. But more importantly I want to help unlock the reuse of services and the power of what microservices enabled for me at Hailo and what I've seen it do for others.

alexellisuk 7y ago

Curious if you use Kubernetes?

jrockway 7y ago

People have been using microservices for decades. Think about the UNIX filesystem. Applications don't know anything about writing to disk blocks, the filesystem service handles that. And the tools that interact with the filesystems can stay very focused to the task at hand. cp only knows how to copy files; ls only knows how to list directories. If you want to add a new feature to ls, you need not worry about breaking cp. On the "web application" side, we've also been doing the same thing since the LAMP days. Your web app has no understanding of how to efficiently store records; the database service handles that. Your web app has no idea how to efficiently maintain TCP connections from a variety of web browsers all using slightly different APIs; your frontend proxy / load balancer / web server handles that. All your app has to do is produce HTML. It's popular because it works great. You can change how the database is implemented and not break the TCP connection handling of the web server. And people are doing that all the time. All "microservices" is is doing this to your own code. You can write something and be done with it, then move on to the next thing. This is the value -- loose coupling. Well-defined APIs and focused tests mean that you spend all your time and effort on one thing at a time, and then it's done. And it scales to larger organizations; while "service A" may not be done, it can be worked on in parallel with "service B". That said, I certainly wouldn't take a single team of 4 and have them write 4 services that interact with each other concurrently. That isn't efficient because not enough exists for anyone to make progress on their individual task, unless it's very simple. But if you do them one at a time, you gradually build a very reliable and maintainable empire, getting more and more functionality with very little breakage. The problem that people run into is that they act as the developers of these services without investing in the tooling needed to make this work. You need to have easy-to-use fakes for each service; so you don't have to start up the entire stack to test and play with a change in one service. You need to collect all the logs and store them where you can see all of them at once. You need monitoring so you can see what components aren't interacting correctly (though monoliths need this too). You need distributed tracing so you can get an idea of why a particular high-level request went wrong. All these things are available off the shelf for free and can be configured in a day or two (ELK, Jaeger, Prometheus, Grafana). (The other problem that people run into is bad API design. There is no hack that works around bad API design in microservices; your "// XXX: this is global for horrible reasons" simply isn't possible. You have to know what you want the API surface to look like, or it's going to be a disaster. It's just as much of a disaster in monoliths, though; this is how you get those untestable monstrosities that break randomly every release. Microservices make you fail now, monoliths make you fail later.)