4 ms·

My company is migrating a huge monolith to microservices. One of the proposed benefits is that it makes end to end testing easier because each service only inte

My company is migrating a huge monolith to microservices. One of the proposed benefits is that it makes end to end testing easier because each service only interacts with a couple other services, so each service will be easier to write integration tests for. But in the monolith, those services communicate over interfaces, and are currently tested as unit tests! So we're replacing unit tests with integration tests and calling that a win because our integration test coverage is higher.

markus_zhang 6y ago
Just wait until BA asks for data from different sources and you have to connect those parts...
dehrmann 6y ago
> So we're replacing unit tests with integration tests Nit: those were always integration tests.
- ric2b 6y ago
  But now they get to use docker and some homegrown scripts in their tests, instead of a testing framework!
rraghur 6y ago
Reminds me of the tweet - we replaced our monolith with Microservices so that every outrage is like a murder mystery
- mst 6y ago
  I believe the technical term for a tightly coupled set of microservices is a 'distributed microlith'.
- sokoloff 6y ago
  Presumably you intended outage, but outrage also fits and is poetic in its own manner.
reader_1000 6y ago
If one part of the application needs to be changed frequently and/or is used by other applications, then it makes sense to separate it as a microservice. However, for other parts, I think it might be better to stay as a monolith since when you have a network in your calls, things get messier. Networks are unreliable even if it is your local area network. In my career I saw some unrelated network equipment was sending a RST packet to load balancer with application servers IP address and resulting in service unavaiable errors. It took us weeks to find that out since it was happening very rarely and there were many layers between load balancer and application servers. Network means slowness, connection errors, unknown results, etc all of which should be handled carefully.
- aflag 6y ago
  Not sure if rate of change truly matters. In my opinion, microservices make most sense when dealing with multiple team. It's much easier to update core services when everyone depends on it through the network, rather than requiring people to redeploy their stuff. If you're a single team operation, it's not really a problem if all your stuff runs in a single process. It may even benefit you in terms of performance and scalability, to be honest.
  - reader_1000 6y ago
    Rate of change may matter when your monolith application takes too long to deploy (i.e a big war application with lots of initializations at start), although rolling updates may help here. It will also be easier to rollback if things go wrong. On the other hand, I agree with your point of multiple teams. I tried to mean same thing with "used by other applications"
    - aflag 6y ago
      How long are you talking? I can't think of a process I've ever worked on that took more than a few seconds to start. As you say, if you have any sort of rolling deployment mechanism the start time of your application is somewhat irrelevant. Unless your application takes a massive time to start, it seems like the wrong thing to optimise for. Surely you only deploy things a few times a day, if that, and hopefully most deployments don't require rollbacks. Also, with the current network speeds and memory availability, it's hard to imagine the war size to be a bottleneck in web development. Depending on other services via a well defined network interface is good for decoupling teams. So it depends on the number of employees you have coding for the same platform, rather than on clients or anything like that.

markus_zhang 6y ago

Just wait until BA asks for data from different sources and you have to connect those parts...

dehrmann 6y ago

> So we're replacing unit tests with integration tests Nit: those were always integration tests.

ric2b 6y ago
But now they get to use docker and some homegrown scripts in their tests, instead of a testing framework!

rraghur 6y ago

Reminds me of the tweet - we replaced our monolith with Microservices so that every outrage is like a murder mystery

mst 6y ago
I believe the technical term for a tightly coupled set of microservices is a 'distributed microlith'.
sokoloff 6y ago
Presumably you intended outage, but outrage also fits and is poetic in its own manner.

reader_1000 6y ago

If one part of the application needs to be changed frequently and/or is used by other applications, then it makes sense to separate it as a microservice. However, for other parts, I think it might be better to stay as a monolith since when you have a network in your calls, things get messier. Networks are unreliable even if it is your local area network. In my career I saw some unrelated network equipment was sending a RST packet to load balancer with application servers IP address and resulting in service unavaiable errors. It took us weeks to find that out since it was happening very rarely and there were many layers between load balancer and application servers. Network means slowness, connection errors, unknown results, etc all of which should be handled carefully.

aflag 6y ago
Not sure if rate of change truly matters. In my opinion, microservices make most sense when dealing with multiple team. It's much easier to update core services when everyone depends on it through the network, rather than requiring people to redeploy their stuff. If you're a single team operation, it's not really a problem if all your stuff runs in a single process. It may even benefit you in terms of performance and scalability, to be honest.
- reader_1000 6y ago
  Rate of change may matter when your monolith application takes too long to deploy (i.e a big war application with lots of initializations at start), although rolling updates may help here. It will also be easier to rollback if things go wrong. On the other hand, I agree with your point of multiple teams. I tried to mean same thing with "used by other applications"
  - aflag 6y ago
    How long are you talking? I can't think of a process I've ever worked on that took more than a few seconds to start. As you say, if you have any sort of rolling deployment mechanism the start time of your application is somewhat irrelevant. Unless your application takes a massive time to start, it seems like the wrong thing to optimise for. Surely you only deploy things a few times a day, if that, and hopefully most deployments don't require rollbacks. Also, with the current network speeds and memory availability, it's hard to imagine the war size to be a bottleneck in web development. Depending on other services via a well defined network interface is good for decoupling teams. So it depends on the number of employees you have coding for the same platform, rather than on clients or anything like that.