Hacker News Reader

Comment by afpx | Hacker News Reader

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.

View on HN

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.

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

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!).

That's fine. But it still couldn't hurt people to actually learn some computing history.

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)

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.

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.

History and Philosophy of science is definitely a field of study: http://www.hps.cam.ac.uk/ - it definitely doesn't come through from learning the subject in the normal manner, because that tends to present a "finalised" view of science that doesn't include any of the dead ends or lengthy mysteries.

HPS for CS wouldn't be a whole graduate course, but would be a worthwhile module in a larger course.

I'm pretty certain that I'm not the only Cambridge HPS graduate here.

It would be interesting to see some of the thinking behind current approaches to HPS being applied to development teams, both as teams and as part of the larger community of developers

The original Wiki:

http://wiki.c2.com/

The wiki linked above was established in the mid 90s by a group of practitioners who were attempting to document much of the history of software development - best practices, gotchas, etc. It was a great reference then, capturing a lot of what was otherwise being discussed on newsgroups and mailing lists. It still probably has a lot of gems.

Technically, it was the first 'wiki'.

http://wiki.c2.com/?WikiHistory

Those who don't know history are doomed to reinvent it!

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.

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.

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.

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.

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

i often hear "soa is dead. long live services" or some such thing

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.

Reply on news.ycombinator.com