11 ms·

I have yet to see a good technical implementation of microservices. It always seem to get messy, inefficient and hard to organize. Everything seems so hard. To

I have yet to see a good technical implementation of microservices. It always seem to get messy, inefficient and hard to organize. Everything seems so hard. To follow and debug requests for example. How do you do that in a good way? Running a local microservice application is another. Maybe microservices is good for very large corporations, but even then I am not really convinced since it seems easier just to learn one bigger codebase that is structured well rather than digging in to many different ones that may be writter in different languages etc. The hype is so big and the benefits are very unclear. At least to me it seems like there are only negative aspects of doing microservices.

zimpenfish 9y ago
> To follow and debug requests for example. How do you do that in a good way? I'm assuming you mean "requests that involve multiple microservices"? And the answer there is simple for following - the first one involved tags the request and passes that tag on to all the subrequests. Easy to correlate across your logs. Debugging can be done in a similar way with a header saying "dump debug for this request" that's passed between services.
- tyingq 9y ago
  "correlation ID" is the common term. Has value outside of microservices as well. Monoliths don't always have a single log file.
  - zimpenfish 9y ago
    Excellent point - and that's where I've always used it to date, as well (monoliths).
- staticelf 9y ago
  Well yes, but when I use a debugger for example that would require me to first debug application 1, then 2, then 3 in order to fully go through the cycle. This seems quite... time consuming.
  - qyv 9y ago
    You should not need to do this with microservices. Part of creating them is implementing well-defined API's, which create concrete borders between your services. It is extremely easy to capture/log all traffic passing between your services, which you should be able to use to determine which service is misbehaving, and them aim your debugger there. If you cannot do this, then your API's are not doing what they are supposed to be doing.
    - joshribakoff 9y ago
      > It is extremely easy to capture/log all traffic passing between your services But you would have to create a development environment running the complete micro-services environment on a single machine. Or setup distributed/cloud logging & debug against production. Which is generally easier to do if you use a monolith. Admittedly tools like docker compose and vagrant can help with this.
  - dozzie 9y ago
    If you rely on a stepping debugger, you're fscked anyway when you step outside of desktop applications and websites. Logs and trace dumps (tcpdump/strace like) are what works almost everywhere.
_pmf_ 9y ago
> The hype is so big and the benefits are very unclear. At least to me it seems like there are only negative aspects of doing microservices. I think there are two groups or organizations that benefit from microservices: - actual scaling is required - "we are too stupid or politically entrenched to maintain a modular code base without them, so we try (and most likely fail) to enforce modularity with microservices" Of course, group 2 will only further entrench themselves.
- tyingq 9y ago
  There's a group 3 also that's roughly "clearly I need microservices on my resume, so we're using it".
  - scaryclam 9y ago
    In my experience, this is by far the largest group. Then they build a distributed monolith and cause a giant mess, like the OP was describing. I really wish people would jump off of the microservices bandwagon, because so very few on it actually understand microservices at all, or have the skill set to make them work.
    - staticelf 9y ago
      Well, one issue is that everyone seems to have a different picture about what a microservice is and everyone also thinks they have the correct understanding. Your comment reflects that perfectly.
  - PaulKeeble 9y ago
    And the fourth which is haphazardly ending up on them due to the way the organisation is laid out and not invented here syndrome. Its mostly an organisation pattern not a technical one.
  - maxxxxx 9y ago
    The funny thing is that this is probably the best strategy for the devs. The people who have chosen to stick with monolith for good reasons will get no respect from the next employer. Whereas the Microservices guys will be hotshots. Same for Hadoop over SQL or node over Java.
kennu 9y ago
I think AWS X-Ray deserves to be mentioned here - it tracks requests through different services using tagging and provides visualization. AWS also has other useful tools like SNS and SQS for building loosely coupled microservice systems. In the AWS case microservices are combined with other paradigms like Serverless and event driven computing. I would judge all these together and consider the overall benefits you gain from fully managed services, built-in autoscaling, independent parallel development and deployment of microservices, etc. Personally I would not go back to the old ways.
erik14th 9y ago
Have you got a look on Elixir/Erlang/OTP?
base698 9y ago
We had to do it, but it had nothing to do performance. Massive team dysfunction and differing skill sets made it so 3 or 4 people were working on our monolith and not very effective in getting things done. We had another 5 that were very effective on other projects that didn't know the monolith stack. After some discussion we built up a design that broke the monolith into 4 parts. This let the teams work more effectively, even if it's not as efficient. Docker compose running some integration tests with the builds helps some of the integration burden.
gaius 9y ago
I have yet to see a good technical implementation of microservices. It always seem to get messy, inefficient and hard to organize. One word: CORBA Those who forget history are doomed to repeat it
- marcosdumay 9y ago
  Yes, CORBA is better than the HTTP services we see everywhere. Yet, it does not fix the problems the GP was talking about. In fact, SOAP is almost as good (it's just harder to use, more ambiguous and less standardized, but not by much), and people still easily create messy APIs on SOAP. It's more a problem that developers that try to scale orders of magnitude too early normally not knowing what they are doing; and developers that do not know what they are doing normally do not design clean interfaces.
jdmichal 9y ago
I always tell people: Microservices sacrifice everything at the alter of scalability. Everything but scalability gets harder, not easier. You point out some good examples of places where this is true. You should not be doing microservices unless you need that scalability. If you don't, regular SOA or even modular monoliths work fine. Microservices live in the place where those break down in scaling. That's a very extreme place, and so microservices are an extreme response. As an example, let's take scaling services over a hybrid cloud. You have your own metal for the baseline request volume, with the capability to provision more capacity from a public cloud. A modular monolith is obviously out of the picture at this point. You would have two separate monolith instances, and would have to consider how and when to pass work between them... Possible, but at that point you're basically inventing a service architecture within a monolith, so why not just move to SOA? If you already have a SOA system, you still have work: Which services to deploy to the cloud, when to deploy them, how to recover and load balance to them, etc. Specific answers to these decisions are what led to what we consider modern microservices: What to deploy is the smallest unit possible, so that you can keep scaling as fine-grained as possible. Every request is routed through a discovery and load-balancer to any and all available instances.
- jules 9y ago
  What do you mean by scalability?
  - jdmichal 9y ago
    That's a great question. I mean ability to serve concurrent requests, or throughput. Microservices will typically worsen other metrics like individual response time.
    - jules 9y ago
      I am not sure microservices are good for scalability in that sense. Microservices divide your application vertically, but for scalability you want to divide it horizontally. You don't want a separate service for each feature of your app, you want an application server that you can replicate as many times as necessary.
falcolas 9y ago
> At least to me it seems like there are only negative aspects of doing microservices You (and others) have cleanly expressed the downsides, so here's my version of why microservices are valuable: - Code is forced to have well defined APIs; you can't reach into a library's internals and rip out what you need when that library is implemented as a separate process. - You can scale only the parts that need to be scaled, when they need to be scaled. - You aren't tied to any single language for your application. - Horizontal scaling is easier than vertical scaling, beyond a certain point. - You gain a lot of extra fault tolerance. Of course, all of these benefits only come when the microservices are implemented well; however when they are done well, scaling and reliability are easy. Since both scaling and reliability directly impact the end user experience, they will be given more weight than the microservice tech debt.
- joshribakoff 9y ago
  > Code is forced to have well defined APIs That is incorrect. Microservices do not force you to write good code. I have seen microservices done poorly where each microservice duplicates code from the others, and APIs are not well defined. For example project A has folders "api" "api2", project B has folder called "api", there's another project just called "api" which also has logic mixed in unrelated to APIs. Files named "server" that actually implement a client, etc. It doesn't matter if your API is an http endpoint or a local function call, if you suck at naming things, your API will suck. > You gain a lot of extra fault tolerance. Also not true as a "fact of matter". You have to account for API requests between your own infrastructure failing. Adding more system boundaries reduces fault tolerance. > Since both scaling and reliability directly impact the end user experience, they will be given more weight than the microservice tech debt. But your competitor's monolith might run on one server. They might implement reliability with a passive failover server, and they might forgo the tech debt & focus on adding new features, which also directly impact the end user experience. Those features will be harder to shoe-horn into your micro-services if you get the boundaries wrong. All of the sudden you have a scalable "reliable" system no one uses, because your competitor has more features. > all of these benefits only come when the microservices are implemented well All of those benefits apply to writing good code in general (microservices or not). The only valid benefit you listed specific to microservices is scaling is easier. But you can still scale a monolith. Just deploy all code to all servers, but only run certain things on each tier of services. So again, you don't really need microservices to do that.
msangi 9y ago
Maintaining structure as the codebase grows is a challenge on it's own, especially when it's so big that you have multiple teams and way too many developers working on it. At work we have a huge monolith and several smaller services. Working on the former it's never nice and my productivity is a fraction of what I can do when working on the smaller and saner projects. I wouldn't always use a microseconds architecture. I think the best approach is to start with a modular monolith till it reaches a critical size.
dmux 9y ago
> ... that is structured well ... Is there a way to organize a large program (let's say in Java) that allows one to easily extract specific components and move them to their own service as needed? I'm thinking along the lines of local message passing between Java "components" (not packages). With a message system in place, you could easily move a service wherever so long as it's able to communicate.

zimpenfish 9y ago

> To follow and debug requests for example. How do you do that in a good way? I'm assuming you mean "requests that involve multiple microservices"? And the answer there is simple for following - the first one involved tags the request and passes that tag on to all the subrequests. Easy to correlate across your logs. Debugging can be done in a similar way with a header saying "dump debug for this request" that's passed between services.

tyingq 9y ago
"correlation ID" is the common term. Has value outside of microservices as well. Monoliths don't always have a single log file.
- zimpenfish 9y ago
  Excellent point - and that's where I've always used it to date, as well (monoliths).
staticelf 9y ago
Well yes, but when I use a debugger for example that would require me to first debug application 1, then 2, then 3 in order to fully go through the cycle. This seems quite... time consuming.
- qyv 9y ago
  You should not need to do this with microservices. Part of creating them is implementing well-defined API's, which create concrete borders between your services. It is extremely easy to capture/log all traffic passing between your services, which you should be able to use to determine which service is misbehaving, and them aim your debugger there. If you cannot do this, then your API's are not doing what they are supposed to be doing.
  - joshribakoff 9y ago
    > It is extremely easy to capture/log all traffic passing between your services But you would have to create a development environment running the complete micro-services environment on a single machine. Or setup distributed/cloud logging & debug against production. Which is generally easier to do if you use a monolith. Admittedly tools like docker compose and vagrant can help with this.
- dozzie 9y ago
  If you rely on a stepping debugger, you're fscked anyway when you step outside of desktop applications and websites. Logs and trace dumps (tcpdump/strace like) are what works almost everywhere.

_pmf_ 9y ago

> The hype is so big and the benefits are very unclear. At least to me it seems like there are only negative aspects of doing microservices. I think there are two groups or organizations that benefit from microservices: - actual scaling is required - "we are too stupid or politically entrenched to maintain a modular code base without them, so we try (and most likely fail) to enforce modularity with microservices" Of course, group 2 will only further entrench themselves.

tyingq 9y ago
There's a group 3 also that's roughly "clearly I need microservices on my resume, so we're using it".
- scaryclam 9y ago
  In my experience, this is by far the largest group. Then they build a distributed monolith and cause a giant mess, like the OP was describing. I really wish people would jump off of the microservices bandwagon, because so very few on it actually understand microservices at all, or have the skill set to make them work.
  - staticelf 9y ago
    Well, one issue is that everyone seems to have a different picture about what a microservice is and everyone also thinks they have the correct understanding. Your comment reflects that perfectly.
- PaulKeeble 9y ago
  And the fourth which is haphazardly ending up on them due to the way the organisation is laid out and not invented here syndrome. Its mostly an organisation pattern not a technical one.
- maxxxxx 9y ago
  The funny thing is that this is probably the best strategy for the devs. The people who have chosen to stick with monolith for good reasons will get no respect from the next employer. Whereas the Microservices guys will be hotshots. Same for Hadoop over SQL or node over Java.

kennu 9y ago

I think AWS X-Ray deserves to be mentioned here - it tracks requests through different services using tagging and provides visualization. AWS also has other useful tools like SNS and SQS for building loosely coupled microservice systems. In the AWS case microservices are combined with other paradigms like Serverless and event driven computing. I would judge all these together and consider the overall benefits you gain from fully managed services, built-in autoscaling, independent parallel development and deployment of microservices, etc. Personally I would not go back to the old ways.

erik14th 9y ago

Have you got a look on Elixir/Erlang/OTP?

base698 9y ago

We had to do it, but it had nothing to do performance. Massive team dysfunction and differing skill sets made it so 3 or 4 people were working on our monolith and not very effective in getting things done. We had another 5 that were very effective on other projects that didn't know the monolith stack. After some discussion we built up a design that broke the monolith into 4 parts. This let the teams work more effectively, even if it's not as efficient. Docker compose running some integration tests with the builds helps some of the integration burden.

gaius 9y ago

I have yet to see a good technical implementation of microservices. It always seem to get messy, inefficient and hard to organize. One word: CORBA Those who forget history are doomed to repeat it

marcosdumay 9y ago
Yes, CORBA is better than the HTTP services we see everywhere. Yet, it does not fix the problems the GP was talking about. In fact, SOAP is almost as good (it's just harder to use, more ambiguous and less standardized, but not by much), and people still easily create messy APIs on SOAP. It's more a problem that developers that try to scale orders of magnitude too early normally not knowing what they are doing; and developers that do not know what they are doing normally do not design clean interfaces.

jdmichal 9y ago

I always tell people: Microservices sacrifice everything at the alter of scalability. Everything but scalability gets harder, not easier. You point out some good examples of places where this is true. You should not be doing microservices unless you need that scalability. If you don't, regular SOA or even modular monoliths work fine. Microservices live in the place where those break down in scaling. That's a very extreme place, and so microservices are an extreme response. As an example, let's take scaling services over a hybrid cloud. You have your own metal for the baseline request volume, with the capability to provision more capacity from a public cloud. A modular monolith is obviously out of the picture at this point. You would have two separate monolith instances, and would have to consider how and when to pass work between them... Possible, but at that point you're basically inventing a service architecture within a monolith, so why not just move to SOA? If you already have a SOA system, you still have work: Which services to deploy to the cloud, when to deploy them, how to recover and load balance to them, etc. Specific answers to these decisions are what led to what we consider modern microservices: What to deploy is the smallest unit possible, so that you can keep scaling as fine-grained as possible. Every request is routed through a discovery and load-balancer to any and all available instances.

jules 9y ago
What do you mean by scalability?
- jdmichal 9y ago
  That's a great question. I mean ability to serve concurrent requests, or throughput. Microservices will typically worsen other metrics like individual response time.
  - jules 9y ago
    I am not sure microservices are good for scalability in that sense. Microservices divide your application vertically, but for scalability you want to divide it horizontally. You don't want a separate service for each feature of your app, you want an application server that you can replicate as many times as necessary.

falcolas 9y ago

> At least to me it seems like there are only negative aspects of doing microservices You (and others) have cleanly expressed the downsides, so here's my version of why microservices are valuable: - Code is forced to have well defined APIs; you can't reach into a library's internals and rip out what you need when that library is implemented as a separate process. - You can scale only the parts that need to be scaled, when they need to be scaled. - You aren't tied to any single language for your application. - Horizontal scaling is easier than vertical scaling, beyond a certain point. - You gain a lot of extra fault tolerance. Of course, all of these benefits only come when the microservices are implemented well; however when they are done well, scaling and reliability are easy. Since both scaling and reliability directly impact the end user experience, they will be given more weight than the microservice tech debt.

joshribakoff 9y ago
> Code is forced to have well defined APIs That is incorrect. Microservices do not force you to write good code. I have seen microservices done poorly where each microservice duplicates code from the others, and APIs are not well defined. For example project A has folders "api" "api2", project B has folder called "api", there's another project just called "api" which also has logic mixed in unrelated to APIs. Files named "server" that actually implement a client, etc. It doesn't matter if your API is an http endpoint or a local function call, if you suck at naming things, your API will suck. > You gain a lot of extra fault tolerance. Also not true as a "fact of matter". You have to account for API requests between your own infrastructure failing. Adding more system boundaries reduces fault tolerance. > Since both scaling and reliability directly impact the end user experience, they will be given more weight than the microservice tech debt. But your competitor's monolith might run on one server. They might implement reliability with a passive failover server, and they might forgo the tech debt & focus on adding new features, which also directly impact the end user experience. Those features will be harder to shoe-horn into your micro-services if you get the boundaries wrong. All of the sudden you have a scalable "reliable" system no one uses, because your competitor has more features. > all of these benefits only come when the microservices are implemented well All of those benefits apply to writing good code in general (microservices or not). The only valid benefit you listed specific to microservices is scaling is easier. But you can still scale a monolith. Just deploy all code to all servers, but only run certain things on each tier of services. So again, you don't really need microservices to do that.

msangi 9y ago

Maintaining structure as the codebase grows is a challenge on it's own, especially when it's so big that you have multiple teams and way too many developers working on it. At work we have a huge monolith and several smaller services. Working on the former it's never nice and my productivity is a fraction of what I can do when working on the smaller and saner projects. I wouldn't always use a microseconds architecture. I think the best approach is to start with a modular monolith till it reaches a critical size.

dmux 9y ago

> ... that is structured well ... Is there a way to organize a large program (let's say in Java) that allows one to easily extract specific components and move them to their own service as needed? I'm thinking along the lines of local message passing between Java "components" (not packages). With a message system in place, you could easily move a service wherever so long as it's able to communicate.