5 ms·

There are good points in there, but I disliked some of the scare quotes. Microservices were not just concocted by a team at Netflix, and everyone then followed

by afpx 9y ago

There are good points in there, but I disliked some of the scare quotes. Microservices were not just concocted by a team at Netflix, and everyone then followed. Instead, microservices emerged across many different companies and teams concurrently. The architectural style was a natural reaction to many simultaneous forces that were being applied across the broader development ecosystem. Of course, I'm biased because I built two similar architectures at the same time that micro service was becoming a buzz word, and I only knew that the type of architecture had a name much later. But, me and my team just did it that way because we were trying to find the architecture that worked best for us, our tools, and our environment. That is, the form followed the function. And, this was the type of design that naturally turned out.

mdekkers 9y ago
Microservices were not just concocted by a team at Netflix In the distant past, "microservices" were called "loosely coupled architectures" and these have been around since the early 80's I believe, but probably earlier. There isn't anything new about microservices, and they are a great idea in theory. In practice, there are all kinds of challenges, and these will have to weigh in on the architectural decision to deploy this particular pattern. I am genuinely curious as to why we in information technology have such an astounding capacity for re-inventing (and re-labeling) the wheel. I rarely see as much "Not Invented Here" and "Not In My Backyard" as I do in our field.
- enraged_camel 9y ago
  Those who don't know history are doomed to reinvent it!
- TheSpiceIsLife 9y ago
  I suspect it is this way because that's how people learn to program: by building things that already exist in an effort to learn how to build such things. I think people also simply like to D.I.Y
- pjc50 9y ago
  The field is really badly taught. Formal CS does exist, but the corresponding architectural and craftsmanship issues often aren't really. Conversely, the field is full of autodidacts. It's much easier to teach yourself by doing. Companies like it this way and fill themselves with smart kids who reinvent the wheel. Let's not forget that often it's easier to reinvent the wheel than look for existing solutions, especially with the risk of running across a software patent (never read these!).
  - JustSomeNobody 9y ago
    That's fine. But it still couldn't hurt people to actually learn some computing history.
    - pjc50 9y ago
      Where would you suggest they start? (Serious question, I've no idea how you'd find this stuff as a curriculum rather than just cultural immersion)
      - JustSomeNobody 9y ago
        I don't think there is a single starting place. It really depends on the context. As an example, we're talking about microservices, so one could start looking into things that people brought up, like the Unix Philosophy. The thing developers really need to constantly be aware of is this - if you think of it today, another developer has already thought of it 30 years ago. Go find out what he knows.
        Intermernet 9y ago
        I remember my dad telling me that a "science history" class would be mostly useless from a practical standpoint as the study of science would include all of the really important bits of the history of science as a matter of course. This may be accurate when approaching physics, but CS is a very young field. Just reading Knuth can give you a fantastic window into what has been done before. Looking into the history of Bell labs and Xerox PARC can make you understand the reality of what you suggest. I'm not in any way suggesting that there's nothing new to invent in CS, but the current mindframe in many devs is that the state of the art is akin to quantum mechanics following Newtonian physics by a couple of decades. The current revolutions in CS are mostly capability based rather than concept based. The ideas are relatively old, but the technology has allowed them to come to fruition. I think it would be beneficial for all new CS practitioners to have access to a history of CS, as they would not just realise that the current trends aren't particularly new, but that there are a huge number of equally old ideas that are probably ready for prime time, but weren't feasible when first suggested.
- dboreham 9y ago
  I've noticed this phenomenon too and I have some theories: First, the subject is very wide and diverse, such that one individual might take decades to come across a reasonable percentage of it all, and by that time 75% of the field would have churned to new stuff. Second, relatively little is written about real life software, certainly until quite recently. Most books and papers are about academic subjects and issues, not closely related to rubber hitting road and war in the trenches. The result is that techniques get reinvented without the new inventors ever having realize the thing they invented already existed. So now it has a new name and even the people who did know about the old thing don't realize the new thing is the same with a different name. Good example : Sharding.
- cubano 9y ago
  I am genuinely curious as to why we in information technology have such an astounding capacity for re-inventing (and re-labeling) the wheel. I like to call it "ego-driven/fashion development" and I pretty much see some form of it nowadays every time I work with a team of devs with members under the age of 30.
  - aninteger 9y ago
    You could say that as developers "age out" (by becoming managers, moving to other industries) of the development world that this cycle will repeat itself over and over.
- sidlls 9y ago
  It's a combination of (at least) two things, in my opinion. 1. Incorrect or incomplete understanding of the differences between CS and software engineering 2. Ego and arrogance. There are plenty of very arrogant high achieving physics and engineering PhDs I know from my former life as an academic who would be ashamed at the arrogance of a lot of the folks in this field. In my view there is a very deep strain of "I know better than those who came before (and, incidentally, better than many now)." I've never seen anything quite like it in any other context.
privateprofile 9y ago
Actually, I remember service oriented architectures were in use long before this became popular in today's blogosphere and picked up by the constant stream of startup hype/BS, albeit with some minor differences. [1] [1] https://en.wikipedia.org/wiki/Service-oriented_architecture https://en.wikipedia.org/wiki/Service-oriented_architecture
- ninjakeyboard 9y ago
  i often hear "soa is dead. long live services" or some such thing
wmccullough 9y ago
I think the biggest thing most organizations miss is that microservices are just another potential tool in the toolbox. You can have both monolithic and microservices architectures that co-exist across different applications. I'd say that there is even a potential mixture of both. I too feel there were good points, but I'm not ready to throw the baby out with the bathwater because there have been failures in organizations because they chose to adopt the pattern without a great reason for why.

by afpx 9y ago

mdekkers 9y ago

Microservices were not just concocted by a team at Netflix In the distant past, "microservices" were called "loosely coupled architectures" and these have been around since the early 80's I believe, but probably earlier. There isn't anything new about microservices, and they are a great idea in theory. In practice, there are all kinds of challenges, and these will have to weigh in on the architectural decision to deploy this particular pattern. I am genuinely curious as to why we in information technology have such an astounding capacity for re-inventing (and re-labeling) the wheel. I rarely see as much "Not Invented Here" and "Not In My Backyard" as I do in our field.

enraged_camel 9y ago
Those who don't know history are doomed to reinvent it!
TheSpiceIsLife 9y ago
I suspect it is this way because that's how people learn to program: by building things that already exist in an effort to learn how to build such things. I think people also simply like to D.I.Y
pjc50 9y ago
The field is really badly taught. Formal CS does exist, but the corresponding architectural and craftsmanship issues often aren't really. Conversely, the field is full of autodidacts. It's much easier to teach yourself by doing. Companies like it this way and fill themselves with smart kids who reinvent the wheel. Let's not forget that often it's easier to reinvent the wheel than look for existing solutions, especially with the risk of running across a software patent (never read these!).
- JustSomeNobody 9y ago
  That's fine. But it still couldn't hurt people to actually learn some computing history.
  - pjc50 9y ago
    Where would you suggest they start? (Serious question, I've no idea how you'd find this stuff as a curriculum rather than just cultural immersion)
    - JustSomeNobody 9y ago
      I don't think there is a single starting place. It really depends on the context. As an example, we're talking about microservices, so one could start looking into things that people brought up, like the Unix Philosophy. The thing developers really need to constantly be aware of is this - if you think of it today, another developer has already thought of it 30 years ago. Go find out what he knows.
      - Intermernet 9y ago
        I remember my dad telling me that a "science history" class would be mostly useless from a practical standpoint as the study of science would include all of the really important bits of the history of science as a matter of course. This may be accurate when approaching physics, but CS is a very young field. Just reading Knuth can give you a fantastic window into what has been done before. Looking into the history of Bell labs and Xerox PARC can make you understand the reality of what you suggest. I'm not in any way suggesting that there's nothing new to invent in CS, but the current mindframe in many devs is that the state of the art is akin to quantum mechanics following Newtonian physics by a couple of decades. The current revolutions in CS are mostly capability based rather than concept based. The ideas are relatively old, but the technology has allowed them to come to fruition. I think it would be beneficial for all new CS practitioners to have access to a history of CS, as they would not just realise that the current trends aren't particularly new, but that there are a huge number of equally old ideas that are probably ready for prime time, but weren't feasible when first suggested.
dboreham 9y ago
I've noticed this phenomenon too and I have some theories: First, the subject is very wide and diverse, such that one individual might take decades to come across a reasonable percentage of it all, and by that time 75% of the field would have churned to new stuff. Second, relatively little is written about real life software, certainly until quite recently. Most books and papers are about academic subjects and issues, not closely related to rubber hitting road and war in the trenches. The result is that techniques get reinvented without the new inventors ever having realize the thing they invented already existed. So now it has a new name and even the people who did know about the old thing don't realize the new thing is the same with a different name. Good example : Sharding.
cubano 9y ago
I am genuinely curious as to why we in information technology have such an astounding capacity for re-inventing (and re-labeling) the wheel. I like to call it "ego-driven/fashion development" and I pretty much see some form of it nowadays every time I work with a team of devs with members under the age of 30.
- aninteger 9y ago
  You could say that as developers "age out" (by becoming managers, moving to other industries) of the development world that this cycle will repeat itself over and over.
sidlls 9y ago
It's a combination of (at least) two things, in my opinion. 1. Incorrect or incomplete understanding of the differences between CS and software engineering 2. Ego and arrogance. There are plenty of very arrogant high achieving physics and engineering PhDs I know from my former life as an academic who would be ashamed at the arrogance of a lot of the folks in this field. In my view there is a very deep strain of "I know better than those who came before (and, incidentally, better than many now)." I've never seen anything quite like it in any other context.

privateprofile 9y ago

Actually, I remember service oriented architectures were in use long before this became popular in today's blogosphere and picked up by the constant stream of startup hype/BS, albeit with some minor differences. [1] [1] https://en.wikipedia.org/wiki/Service-oriented_architecture https://en.wikipedia.org/wiki/Service-oriented_architecture

ninjakeyboard 9y ago
i often hear "soa is dead. long live services" or some such thing

wmccullough 9y ago

I think the biggest thing most organizations miss is that microservices are just another potential tool in the toolbox. You can have both monolithic and microservices architectures that co-exist across different applications. I'd say that there is even a potential mixture of both. I too feel there were good points, but I'm not ready to throw the baby out with the bathwater because there have been failures in organizations because they chose to adopt the pattern without a great reason for why.