4 ms·

So originally software development used micro-services rather than modules. A lot of software developers get this wrong and think modules were first. They were

So originally software development used micro-services rather than modules. A lot of software developers get this wrong and think modules were first. They were not. The software developers just grew up during the module fad caused by the personal computer before everything circled back around to micro-services. The purpose of OOP was to replicate the benefits of micro-services in single user environments. A class corresponds to a service type and an object an physical instance of the service. So why did Monoliths/modules fail? Some pretty simple issues, incomplete isolate between the modules, memory corruption and performance issues easily propagate between the "isolated" modules. But the main killer is compile times. Monoliths/module based programs require massive compile times that grow quickly with the size of the program.

BinaryIgor 11mo ago
If you have each module as independently versioned package, the compile times are not slow, since you only need to compile modules that have changed and modules are provided as compiled dependencies. Each individual module is fast to compile.
bloppe 11mo ago
Is there somewhere I could read more about this take?
- foobarian 11mo ago
  Sounds like some mystical time during mainframe heyday era.
- ReflectedImage 11mo ago
  Of course: https://www.youtube.com/watch?v=wo84LFzx5nI https://www.youtube.com/watch?v=wo84LFzx5nI
strken 11mo ago
Sorry, what? Are you claiming that ENIAC was using microservices? That's a claim that needs some kind of supporting evidence, or at least a better explanation.
- ReflectedImage 11mo ago
  Procedure, functional and Entity Component Systems (Sketchpad, 1963) programs came first. Micro-services then came along (Distributed computing). Then OOP was then invented to replicate the benefits of micro-services in single user environments.
  - antonvs 11mo ago
    Sorry, but this is laughably wrong and bears no resemblance to how the history of computing actually developed. The first systems that could reasonably be described as distributed computing weren’t developed until the 1970s. The object-oriented language Simula was developed a decade earlier. And those early 1970s distributed computing systems were not, by any stretch of the imagination, microservices. It wasn’t until around the 1990s that the precursors to what we call microservices today appeared, in systems like CORBA, DCOM, and RMI. And the actual term “microservice” didn’t appear until after 2010. (You may be conflating “service” with “microservice”. Not all distributed networked services qualify as microservices.)
jillesvangurp 11mo ago
As soon as functions were invented, we had modules. And as soon as we had the ability to call those over a network, people started building the same stuff over and over again. It's eery how much of the stuff that Kubernetes does maps almost one to one to the same kind of stuff that for example CORBA used to do. Naming, discovery, security, events, configuration etc. You'll find CORBA specific ways of doing all that. Except that stuff dates back 35 years. There is probably a bunch of stuff before CORBA that could be added to this list but that's before my time. DCOM (MS) replicated some of that but never really caught on. You'll find quite a bit of that kind of stuff in OSGI (Java) that was somewhat popular in the early 2000s. And there was of course the whole SOAP / Web Services / SOA mess that people got into around the same time. Docker emerged early 2010s and Kubernetes soon followed and fast forward ten years and we're neck deep into the same shit all over again via micro services. Part of this is just stuff you kind of need if you want to do a distributed system (like service discovery, auditing, security, etc.). And part of that is a lot of complexity resulting from that. Especially when you are distributing for organizational rather than technical reasons (Conway's law). Which is a major driving force in larger organizations. The point here is that none of this is new. Also this stuff did not really fail but just seamlessly morphed into the next thing. People keep on making the mistake of believing that buzzword compliance makes things better/easier when in reality you are paying a largish price in terms of complexity and overhead for not that much gain. There's a lot of wheel reinvention happening here as well. And a lot of the exact same naivity being projected on the latest and greatest framework or thing. The same type of people that are cheer leading microservices now would have been cheer leading web services twenty years ago. In some cases these literally are the same people. Or companies. There's a reason IBM is all over this stuff, for example.
antonvs 11mo ago
> So originally software development used micro-services rather than modules. This is not even remotely true, in any conceivable sense. But I'd love to hear what you were thinking of.
- ReflectedImage 11mo ago
  The concept of a module comes from the concept of a service. Services have small public interfaces that conceal their private internal workings. I understand it's a very surprising thing to learn.
  - antonvs 11mo ago
    You wrote “originally software development used…” But originally, software development used or supported neither modules nor services. The original versions of languages like FORTRAN or COBOL had no such concepts. They had functions, procedures, or subroutines as the highest level of abstraction below the program level. And earlier computing systems were even lower level.

BinaryIgor 11mo ago

If you have each module as independently versioned package, the compile times are not slow, since you only need to compile modules that have changed and modules are provided as compiled dependencies. Each individual module is fast to compile.

bloppe 11mo ago

Is there somewhere I could read more about this take?

foobarian 11mo ago
Sounds like some mystical time during mainframe heyday era.
ReflectedImage 11mo ago
Of course: https://www.youtube.com/watch?v=wo84LFzx5nI https://www.youtube.com/watch?v=wo84LFzx5nI

strken 11mo ago

Sorry, what? Are you claiming that ENIAC was using microservices? That's a claim that needs some kind of supporting evidence, or at least a better explanation.

ReflectedImage 11mo ago
Procedure, functional and Entity Component Systems (Sketchpad, 1963) programs came first. Micro-services then came along (Distributed computing). Then OOP was then invented to replicate the benefits of micro-services in single user environments.
- antonvs 11mo ago
  Sorry, but this is laughably wrong and bears no resemblance to how the history of computing actually developed. The first systems that could reasonably be described as distributed computing weren’t developed until the 1970s. The object-oriented language Simula was developed a decade earlier. And those early 1970s distributed computing systems were not, by any stretch of the imagination, microservices. It wasn’t until around the 1990s that the precursors to what we call microservices today appeared, in systems like CORBA, DCOM, and RMI. And the actual term “microservice” didn’t appear until after 2010. (You may be conflating “service” with “microservice”. Not all distributed networked services qualify as microservices.)

jillesvangurp 11mo ago

As soon as functions were invented, we had modules. And as soon as we had the ability to call those over a network, people started building the same stuff over and over again. It's eery how much of the stuff that Kubernetes does maps almost one to one to the same kind of stuff that for example CORBA used to do. Naming, discovery, security, events, configuration etc. You'll find CORBA specific ways of doing all that. Except that stuff dates back 35 years. There is probably a bunch of stuff before CORBA that could be added to this list but that's before my time. DCOM (MS) replicated some of that but never really caught on. You'll find quite a bit of that kind of stuff in OSGI (Java) that was somewhat popular in the early 2000s. And there was of course the whole SOAP / Web Services / SOA mess that people got into around the same time. Docker emerged early 2010s and Kubernetes soon followed and fast forward ten years and we're neck deep into the same shit all over again via micro services. Part of this is just stuff you kind of need if you want to do a distributed system (like service discovery, auditing, security, etc.). And part of that is a lot of complexity resulting from that. Especially when you are distributing for organizational rather than technical reasons (Conway's law). Which is a major driving force in larger organizations. The point here is that none of this is new. Also this stuff did not really fail but just seamlessly morphed into the next thing. People keep on making the mistake of believing that buzzword compliance makes things better/easier when in reality you are paying a largish price in terms of complexity and overhead for not that much gain. There's a lot of wheel reinvention happening here as well. And a lot of the exact same naivity being projected on the latest and greatest framework or thing. The same type of people that are cheer leading microservices now would have been cheer leading web services twenty years ago. In some cases these literally are the same people. Or companies. There's a reason IBM is all over this stuff, for example.

antonvs 11mo ago

> So originally software development used micro-services rather than modules. This is not even remotely true, in any conceivable sense. But I'd love to hear what you were thinking of.

ReflectedImage 11mo ago
The concept of a module comes from the concept of a service. Services have small public interfaces that conceal their private internal workings. I understand it's a very surprising thing to learn.
- antonvs 11mo ago
  You wrote “originally software development used…” But originally, software development used or supported neither modules nor services. The original versions of languages like FORTRAN or COBOL had no such concepts. They had functions, procedures, or subroutines as the highest level of abstraction below the program level. And earlier computing systems were even lower level.