5 ms·

That's a little extreme. Maybe instead you could probe at interview time whether they are happy with their microservices, how many do they have, do they feel h

• Trasmatta 5y ago
  Why is it extreme? There are plenty of companies out there that don't do microservices. There's no need for me to work for one that does. Maybe I'll miss out on a job with an incredibly well architected microservice that I would love, but I'm perfectly content with missing that (rare) job. I've found it incredibly hard or impossible to gauge the quality of a codebase during interviews. (Beyond immediate red flags like "oh, we don't write any tests or do code reviews" or whatever.) And to be honest, most codebases are bad, it's just a matter of degree. And I would almost always prefer working in a bad monolith than bad microservices.
• lmm 5y ago
  > Not all microservice setups are shit shows. Yeah they are. One service per team, the thing that Amazon was originally doing that was the inspiration for all this, works, but you wouldn't call that "microservices" these days; the thing that people call "microservices" is always a shit show.
  • ratww 5y ago
    I've worked at one of those "one service per team" and, boy it was the suckiest most incredibly stupid thing ever. I needed a place to store marketing and PR templates that were completely unrelated to the core of our product. Of course the rule was "one service per team", so the CTO demanded that I store it together with our service, which is the part that performs customer authentication. Meaning, the part that is responsible for securing customer data and everything else. Whenever we had auditors checking it they're puzzled as to why there's marketing material storage inside the auth microservice. This could have been the poster-child example of a good place do have a separate service, but no, the law was the law. It's almost as if there's no such thing as a silver bullet.
    • alisonkisk 5y ago
      That's clearly a problem with the CTO (who I bet was a junior eng who happened to join the founding team) misunderstanding what a "team" is. An incompetent leader can sink any ship.
    • lmm 5y ago
      So why was the team that did customer authentication responsible for marketing and PR templates?
      • ratww 5y ago
        Because "one thing per team" is equally as idiotic and bureaucratic as "one service per team". The company was technologically dysfunctional, not organisationally dysfunctional.
• pjerem 5y ago
  > Maybe instead you could probe at interview time whether they are happy with their microservices There is no way anyone tells you in interview that the codebase is crappy or that they are unhappy with. You’ll always be told « well, like everywhere, we have legacy, but we learnt for it and now every new project is in [put REST + shiny front tech here] and we are happy with it. We migrate step by step ». And then you’ll realize that the codebase they called legacy is what makes the company’s money, it’s not that bad compared to new project and is a pain to maintain because nobody works on it anymore except for urgent bug solving. So, they’ll probably tell you that « they are happy with their microservices » (or quite happy) because they already try to fool themselves about it.
  • Trasmatta 5y ago
    This is so accurate it hurts. No interviewer is ever going to say "dude, our codebase is terrible. The CTO wrote most of the core logic 9 years ago and everybody is afraid to touch it, so we just paper over it with increasingly complex interfaces and abstractions. There are like 25 different ways of doing everything, because every 6 months a dev comes in and thinks we should use their favorite new design pattern everywhere, but then gives up halfway through implementing it. Everything is either massively over engineered or complete spaghetti."
    • zimpenfish 5y ago
      To be fair, I have had that conversation in a couple of interviews but then I'm usually coming in as a contractor to patch up these kind of things.