4 ms·

So they split everything apart because their tests were failing and they didn't want to spend time fixing them, and they they merged it back together by spendin

So they split everything apart because their tests were failing and they didn't want to spend time fixing them, and they they merged it back together by spending time fixing and improving their tests? It seems like the problem here was bad testing and micro repos, not microservices.

dgritsko 8y ago
I agree, and their conclusion even features this salient bit: >However, we weren’t set up to scale. We lacked the proper tooling for testing and deploying the microservices when bulk updates were needed. As a result, our developer productivity quickly declined. My impression after reading this post was that microservices were symptoms of problems in how their organization wasn't set up to implement them effectively, rather than the actual cause of those problems.
- deleted 8y ago
  [deleted]
- matwood 8y ago
  Yeah, multiple services are going to be challenging if an organization has not already setup fully automated CI/CD pipeline(s).
_5meq 8y ago
Agreed. It's amazing to me how people still "meh" away testing as a secondary concern, and then regret it later. Over and over again. WRITING software is easy, anyone can do it. CHANGING software is extremely difficult. THAT is why we have tests. Also, if you are smart about it, you can get documentation out of the deal for relatively little additional cost. My go to example is on-boarding new developers: New dev: "OK, i'm here! How do I start?" with tests: Clone the repo, install dependencies, and run the test suite. As you develop new features, be sure to write additional test. They are up and going in a matter of minutes. without tests: Clone the repo, install deps, download testing database, achieve homeostasis with your dev environment, learn the entire system, build up the state you require to write your feature, iterate on it by hand over and over again.
- madamelic 8y ago
  >without tests: Clone the repo, install deps, download testing database, achieve homeostasis with your dev environment, learn the entire system, build up the state you require to write your feature, iterate on it by hand over and over again. My first job out of college was like that. I had been doing professional-ish (I was paid and employed but I basically worked alone with no other engineers around) work for two years but this still didn't raise any flags. You basically quoted exactly the setup.

dgritsko 8y ago

I agree, and their conclusion even features this salient bit: >However, we weren’t set up to scale. We lacked the proper tooling for testing and deploying the microservices when bulk updates were needed. As a result, our developer productivity quickly declined. My impression after reading this post was that microservices were symptoms of problems in how their organization wasn't set up to implement them effectively, rather than the actual cause of those problems.

deleted 8y ago
[deleted]
matwood 8y ago
Yeah, multiple services are going to be challenging if an organization has not already setup fully automated CI/CD pipeline(s).

_5meq 8y ago

Agreed. It's amazing to me how people still "meh" away testing as a secondary concern, and then regret it later. Over and over again. WRITING software is easy, anyone can do it. CHANGING software is extremely difficult. THAT is why we have tests. Also, if you are smart about it, you can get documentation out of the deal for relatively little additional cost. My go to example is on-boarding new developers: New dev: "OK, i'm here! How do I start?" with tests: Clone the repo, install dependencies, and run the test suite. As you develop new features, be sure to write additional test. They are up and going in a matter of minutes. without tests: Clone the repo, install deps, download testing database, achieve homeostasis with your dev environment, learn the entire system, build up the state you require to write your feature, iterate on it by hand over and over again.

madamelic 8y ago
>without tests: Clone the repo, install deps, download testing database, achieve homeostasis with your dev environment, learn the entire system, build up the state you require to write your feature, iterate on it by hand over and over again. My first job out of college was like that. I had been doing professional-ish (I was paid and employed but I basically worked alone with no other engineers around) work for two years but this still didn't raise any flags. You basically quoted exactly the setup.