4 ms·

It is a pure function call. There are no side effects, just a clear and simple input stream and a clear and simple output stream. I agree with your characteriz

It is a pure function call. There are no side effects, just a clear and simple input stream and a clear and simple output stream. I agree with your characterization. All except maybe the "I'd probably write a quick JS viewer that can collapse stack traces" part. Here's the thing: I'm so minimalist that I'm only going to add frameworks and libraries as a last result, if you stuck a gun to my head. I'm going to resist as much as I possibly can. I love writing code. And every line of code I write has to be compiled, deployed, is prone to bugs, has version dependencies, and so on. Many times it adds unnecessary complexity to the solution. I love using cool frameworks and libraries. Same goes for them. The magic here is that the vast majority of whatever you're doing? It's already been done. Use O/S code that's ran successfully for ten, twenty years. Write your own code only as a last result. Micrososervices shouldn't have more than 100 lines of code. Yes, it's a function. Maybe 3 or 4 closely-related functions. If it gets past that level of complexity, refactor. (The only thing I'd add here is that you'll end up factoring out common code as you go along. That code needs to be put into a shared corporate library, which also should be small, along with shared types) When done well, you end up with the realization that you've been doing it wrong all along. When done poorly, you just make an even bigger mess than you did doing it the old way. Here's one small example. I was writing a production project for some folks a few years ago. We needed some way of showing system status. The old way could have used all sorts of things: logging systems, server metric systems, and so on. I would have probably done some research, downloaded a library or framework, set it up along the happy path, and made some really awesome html dashboards. Then the library would change, or the metrics would be different, or the configuration would need tweaking, etc. I figured out what we really needed to see was time/date stamps on certain files. So I pipe ls to a web file and chron it. Five minutes later it's working. It'll be working ten years from now. If we need something more complicated? We'll add it. One tiny little bit at a time. I'm okay with calling that a microservice, since it's infrastructure code that needs to be deployed and maintained as part of the app. But it's really only a line of BASH. Some people would say that what I did was completely trivial. These are people who do not understand what the hell is going on. That was a win. If I could have 5 or 10 microservices like that which provide business value? I'm freaking way ahead of the value curve as opposed to a similar team who's still slogging through 7,000 lines of mostly boilerplate code that does basically the same thing.

danmaz74 10y ago
> I'm okay with calling that a microservice, since it's infrastructure code that needs to be deployed and maintained as part of the app. But it's really only a line of BASH. I'm under the impression that most people wouldn't call that a microsevice. Moreover, isn't that solution completely dependent on the implementation of the code that is writing those certain files, without making this dependence explicit - and pretty difficult to test automatically?
- DanielBMarkham 10y ago
  Actually no. No more than CSV dependency prevents spreadsheets from working with one another. I think the key thing here is your word "explicit". There are lots of ways to make things explicit. The concerns of coupling and cohesion don't go anywhere. There are other ways to address them. Testing is actually significantly easier, not more difficult.
  - danmaz74 10y ago
    I'll take your words about testability and maintainability, but still, I'm not convinced this would be be considered a microservice by most proponents of the term: > Like in SOA, services in a microservice architecture[1] are processes that communicate with each other over the network in order to fulfill a goal. Also, like in SOA, these services use technology agnostic protocols.[2] https://en.wikipedia.org/wiki/Microservices https://en.wikipedia.org/wiki/Microservices
nostrademons 10y ago
I'd agree philosophically that this is the right way to do it, but that's not what most people are speaking about when they say "microservices". They usually mean small independent servers communicating via RPC, each of which only does one thing. I'd say that this is pretty much the opposite of what you describe, since now each task needs the overhead of serialization, deserialization, marshalling, error-checking, process monitoring, etc.
- 10y ago

danmaz74 10y ago

> I'm okay with calling that a microservice, since it's infrastructure code that needs to be deployed and maintained as part of the app. But it's really only a line of BASH. I'm under the impression that most people wouldn't call that a microsevice. Moreover, isn't that solution completely dependent on the implementation of the code that is writing those certain files, without making this dependence explicit - and pretty difficult to test automatically?

DanielBMarkham 10y ago
Actually no. No more than CSV dependency prevents spreadsheets from working with one another. I think the key thing here is your word "explicit". There are lots of ways to make things explicit. The concerns of coupling and cohesion don't go anywhere. There are other ways to address them. Testing is actually significantly easier, not more difficult.
- danmaz74 10y ago
  I'll take your words about testability and maintainability, but still, I'm not convinced this would be be considered a microservice by most proponents of the term: > Like in SOA, services in a microservice architecture[1] are processes that communicate with each other over the network in order to fulfill a goal. Also, like in SOA, these services use technology agnostic protocols.[2] https://en.wikipedia.org/wiki/Microservices https://en.wikipedia.org/wiki/Microservices

nostrademons 10y ago

I'd agree philosophically that this is the right way to do it, but that's not what most people are speaking about when they say "microservices". They usually mean small independent servers communicating via RPC, each of which only does one thing. I'd say that this is pretty much the opposite of what you describe, since now each task needs the overhead of serialization, deserialization, marshalling, error-checking, process monitoring, etc.

10y ago