4 ms·

You're also making a lot of assumptions. I started working in 2004 and in 2006 I was already doing 'microservices', I was responsible for a few web services (.N

You're also making a lot of assumptions. I started working in 2004 and in 2006 I was already doing 'microservices', I was responsible for a few web services (.NET) (with a few endpoints each), other colleagues had others. These web services where part of a bigger system (out of the many that we had). Emphasis here is on few endpoints, the services where split on functionality, some services talked to other services, some directly to the database. One of the reasons for the split was also because we were using Visual Source Safe and multiple people working on the same code was hard. So yes, I think 'Microservices' is a buzzword, it's been driven by the use of containers, deployment automation, and the assumptions that people have done monotliths because they didn't know better is wrong. Every sane engineer who has put too much functionality in a service which at some point caused problems with scaling, agility, etc, would take measures to address it.

icebraining 8y ago
Yes, people were doing microservices before the name appeared, but that's true of all design and architectural patterns. A few people/teams implement similar solutions to similar problems, then someone recognizes the similitude and names that general pattern. Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience (assuming they can see through the snake-oil sellers that inevitably pop up).
- misja111 8y ago
  >> Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience In my experience it's exactly the opposite that has happened. I see microservices being abused all the time, just because someone read a blog and thought they were cool. The same thing happened with SOA by the way.
mattmanser 8y ago
It's funny that the main reason you switched was because of the difficulties of VSS. Your tools forced you to make decisions about how you code! We just switched to SVN. The migration was an easy < one day job, a few weeks of pain with some developers grumbling that it was too complex and then everyone was (mostly) happy that we no longer had to hunt down the consultant who had locked a particularly critical file and was now out of the office the rest of the week.
- dpark 8y ago
  You’ve been on VSS until just recently? That seems insane. Wasn’t the last update to VSS shipped in 2005? Also, why SVN? That seems an antiquated choice at this point.
  - eropple 8y ago
    "Just" being "simply", rather than sticking with VSS.
    - dpark 8y ago
      I read that as “recently” rather than “simply”, but could be wrong.
  - mattmanser 8y ago
    No, this was a decade ago at a company I used to work for. Although a couple of years ago I did have a job where they used it, but I quit after 2 months. For some reason a couple of the Devs would constantly check in blank commits. Not sure if that was a product of VSS or because the Devs were awful (part of the many reasons I left so quickly). It's not quite as bad any more, but still terrible when compared to Git or SVN.
    - dpark 8y ago
      Ok. That makes more sense. :)
  - zimpenfish 8y ago
    One of the first things I did at a contract in 2013 was port their RCS wrapper scripts to SVN. I wept hard for those weeks.
    - dpark 8y ago
      That sounds pretty terrible. Why did they need a bunch of wrappers? I’m a big fan of vanilla tooling. Complex build, version control, etc gets no love and ends up ten years later as a big mess that no one understands or wants to support.

icebraining 8y ago

Yes, people were doing microservices before the name appeared, but that's true of all design and architectural patterns. A few people/teams implement similar solutions to similar problems, then someone recognizes the similitude and names that general pattern. Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience (assuming they can see through the snake-oil sellers that inevitably pop up).

misja111 8y ago
>> Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience In my experience it's exactly the opposite that has happened. I see microservices being abused all the time, just because someone read a blog and thought they were cool. The same thing happened with SOA by the way.

mattmanser 8y ago

It's funny that the main reason you switched was because of the difficulties of VSS. Your tools forced you to make decisions about how you code! We just switched to SVN. The migration was an easy < one day job, a few weeks of pain with some developers grumbling that it was too complex and then everyone was (mostly) happy that we no longer had to hunt down the consultant who had locked a particularly critical file and was now out of the office the rest of the week.

dpark 8y ago
You’ve been on VSS until just recently? That seems insane. Wasn’t the last update to VSS shipped in 2005? Also, why SVN? That seems an antiquated choice at this point.
- eropple 8y ago
  "Just" being "simply", rather than sticking with VSS.
  - dpark 8y ago
    I read that as “recently” rather than “simply”, but could be wrong.
- mattmanser 8y ago
  No, this was a decade ago at a company I used to work for. Although a couple of years ago I did have a job where they used it, but I quit after 2 months. For some reason a couple of the Devs would constantly check in blank commits. Not sure if that was a product of VSS or because the Devs were awful (part of the many reasons I left so quickly). It's not quite as bad any more, but still terrible when compared to Git or SVN.
  - dpark 8y ago
    Ok. That makes more sense. :)
- zimpenfish 8y ago
  One of the first things I did at a contract in 2013 was port their RCS wrapper scripts to SVN. I wept hard for those weeks.
  - dpark 8y ago
    That sounds pretty terrible. Why did they need a bunch of wrappers? I’m a big fan of vanilla tooling. Complex build, version control, etc gets no love and ends up ten years later as a big mess that no one understands or wants to support.