5 ms·

The primary offering of microservices is decoupling and simplicity. They are language agnostic, communicating via HTTP /messaging/pattern matching. It's the opp

The primary offering of microservices is decoupling and simplicity. They are language agnostic, communicating via HTTP /messaging/pattern matching. It's the opposite of verbose and traditional monolithic architectures that relied on a rich domain model. Microservices should be small enough to be owned by a single developer. With pattern matching, you can extend functionality by creating new microservices instead of modifying existing ones. It boils down to change management. For complex systems, the benefits microservices bring to the table make the overhead cost of maintaining these services worth it.

0xfaded 10y ago
> Microservices should be small enough to be owned by a single developer This seems bad for code review, and disastrous with turnover. Whoops, now we need to find a scheme engineer whose eccentricities are roughly equivalent to this last guy. There are also ways to achieve microservice-like architectures without requiring multiple code bases. See Actors (scala akka). Streams are an extension which give automatic load balancing. And if you need it to run over the network, akka-remote has you covered.
- hinkley 10y ago
  I've not been happy with this kind code ownership in the past. Those who want to misbehave have a nice comfortable place to hide out while appearing relevant because they have a monopoly on an idea that they don't have the skills to be responsible for. So then you have your coworker who wrote a wrapper around the code to sanitize all of the inputs and outputs and it's bigger than the actual code and once in a while it guesses wrong about ambiguous data.
- duaneb 10y ago
  This somewhat sidesteps an advantage of microservices that they are language agnostic.
  - 0xfaded 10y ago
    I've never been convinced this is an advantage. Ryanair (the discount carrier) has a fleet of 354 boeing-737s. This means they cannot fly some routes the bigger jets can, and other routes they burn more fuel than the smaller jets would. BUUUT ... maintenance and logistics are drastically cheaper and efficient. By analogy, I would argue that costs sunk either in training or hiring for specific skills will pay off in the long run.
    - twunde 10y ago
      I will say that it can be an advantage, but it's rare. It becomes an advantage when your primary language lacks the tools to do something well. One of my previous companies was a PHP shop and they used Python to chop up audio files, which would have been very cumbersome to do in PHP (few if any existing libraries). My current company implemented complex data pipelines in PHP, which really should have been done in a different language (python or scala would have been natural choices).
      - gedrap 10y ago
        I am in a very similar situation right now and I totally agree with you on this one.
dasil003 10y ago
The problem which I don't see discussed nearly enough when people start drinking the microservices koolaid is what does the interface between the microservices look like? If you can define a nice stable interface that changes much less frequently then the constituent services, then it's mostly a question of operational overhead. However, if the microservices comprise many cross-cutting business concerns, then the churn on the interfaces is a massive source of pain compared to (for example) running one process that loads multiple modules where you can leverage all the power of that languages to do basic wiring / type checking ensuring the whole things fits neatly together. IMO, microservices or SOA or whatever you want to call it, is primarily a method of organizing large teams so they don't get hamstrung by ops coordination. In that case you absolutely need it, but for smaller teams the overhead will usually far outweigh the benefit. I'm glad the space is being explored so that we get better tooling and techniques to lower that overhead, but when the dust settles I expect many small teams will discover that we collectively overestimated the better-understood pain of monolithic architectures and underestimated the less-understood pain of microservices.
crdoconnor 10y ago
>The primary offering of microservices is decoupling and simplicity. Microservice architecture is very much orthogonal to loose coupling. I've worked on several microservice architectures with tight coupling. The microservice aspect actually exacerbated the pain caused by the tight coupling because it added the risk overhead of serialization/deserialization and network failures, which simply don't exist in a 'monolith' context. Microservices when implemented are usually either a reflection of conway's law (ID team in building B has its own service; as does the CMS team in Europe), or fashion-driven development (one team working on 17 different services... which can be nasty).

0xfaded 10y ago

> Microservices should be small enough to be owned by a single developer This seems bad for code review, and disastrous with turnover. Whoops, now we need to find a scheme engineer whose eccentricities are roughly equivalent to this last guy. There are also ways to achieve microservice-like architectures without requiring multiple code bases. See Actors (scala akka). Streams are an extension which give automatic load balancing. And if you need it to run over the network, akka-remote has you covered.

hinkley 10y ago
I've not been happy with this kind code ownership in the past. Those who want to misbehave have a nice comfortable place to hide out while appearing relevant because they have a monopoly on an idea that they don't have the skills to be responsible for. So then you have your coworker who wrote a wrapper around the code to sanitize all of the inputs and outputs and it's bigger than the actual code and once in a while it guesses wrong about ambiguous data.
duaneb 10y ago
This somewhat sidesteps an advantage of microservices that they are language agnostic.
- 0xfaded 10y ago
  I've never been convinced this is an advantage. Ryanair (the discount carrier) has a fleet of 354 boeing-737s. This means they cannot fly some routes the bigger jets can, and other routes they burn more fuel than the smaller jets would. BUUUT ... maintenance and logistics are drastically cheaper and efficient. By analogy, I would argue that costs sunk either in training or hiring for specific skills will pay off in the long run.
  - twunde 10y ago
    I will say that it can be an advantage, but it's rare. It becomes an advantage when your primary language lacks the tools to do something well. One of my previous companies was a PHP shop and they used Python to chop up audio files, which would have been very cumbersome to do in PHP (few if any existing libraries). My current company implemented complex data pipelines in PHP, which really should have been done in a different language (python or scala would have been natural choices).
    - gedrap 10y ago
      I am in a very similar situation right now and I totally agree with you on this one.

dasil003 10y ago

The problem which I don't see discussed nearly enough when people start drinking the microservices koolaid is what does the interface between the microservices look like? If you can define a nice stable interface that changes much less frequently then the constituent services, then it's mostly a question of operational overhead. However, if the microservices comprise many cross-cutting business concerns, then the churn on the interfaces is a massive source of pain compared to (for example) running one process that loads multiple modules where you can leverage all the power of that languages to do basic wiring / type checking ensuring the whole things fits neatly together. IMO, microservices or SOA or whatever you want to call it, is primarily a method of organizing large teams so they don't get hamstrung by ops coordination. In that case you absolutely need it, but for smaller teams the overhead will usually far outweigh the benefit. I'm glad the space is being explored so that we get better tooling and techniques to lower that overhead, but when the dust settles I expect many small teams will discover that we collectively overestimated the better-understood pain of monolithic architectures and underestimated the less-understood pain of microservices.

crdoconnor 10y ago

>The primary offering of microservices is decoupling and simplicity. Microservice architecture is very much orthogonal to loose coupling. I've worked on several microservice architectures with tight coupling. The microservice aspect actually exacerbated the pain caused by the tight coupling because it added the risk overhead of serialization/deserialization and network failures, which simply don't exist in a 'monolith' context. Microservices when implemented are usually either a reflection of conway's law (ID team in building B has its own service; as does the CMS team in Europe), or fashion-driven development (one team working on 17 different services... which can be nasty).