10 ms·

Except the language argument, don't you get all that by just having modules in your code (assuming a statically typed language since the boundaries are type che

Except the language argument, don't you get all that by just having modules in your code (assuming a statically typed language since the boundaries are type checked)?

ivan_gammel 8y ago
Not really. For example, it's easier to mock a microservice, than a module, for testing purposes. Let's say you have component A and component B, A depends on B (dependency implemented via runtime sync or async call), B is computationally intensive or has certain requirements on resources that make it harder or impossible to test on developer's machine. You may want to test only A: with monolithic architecture you'll have to produce another build of the application, that contains mock of B (or you need something like OSGi for runtime module discovery). When both components are implemented as microservices, you can start a container with mock of B instead of real B.
- scarface74 8y ago
  Mocking modules for unit testing has been a solved problem for decades in almost every language.
  - jrs95 8y ago
    And running an integration test on a single modular application is easy. Doing it for a distributed system is very hard.
    - ivan_gammel 8y ago
      Running E2E blackbox test is equally simple for all kinds of architectures, especially today, when it's so easy to create a clean test environment with multiple containers even on developer's machine. It may be harder to automate this process for a distributed system, but, frankly speaking, I don't see a big difference between a docker-compose file or a launch script for monolith - I've been writing such tests for distributed systems casually for several years and from my personal experience it's much easier to process the test output and debug the microservices than monolithic applications.
      - amirouche 8y ago
        > it's much easier to process the test output and debug the microservices than monolithic applications. You easier to debug end-to-end tests of a microservice architecture that monolith? That's not my experience. How do you manage to put side by side all the events when they are in dozen of files?
        ivan_gammel 8y ago
        I just don't use files for anything (services should be designed with the assumption that container can be destroyed any time, so files are simply not an option here). If you are talking about the logs, there are solutions like Graylog to aggregate and analyze them.
        scarface74 8y ago
        Using only files for logging is the last thing I would do in 2018. I use Serilog for structured logging. Depending on the log destination, your logs are either stored in an RDMS (I wouldn’t recommend it) or created as JSON with name value pairs that can be sent directly to a JSON data store like ElasticSearch or Mongo where you can do adhoc queries. https://stackify.com/what-is-structured-logging-and-why-developers-need-it/ https://stackify.com/what-is-structured-logging-and-why-deve...
    - bpicolo 8y ago
      Easy until you have 100,000 of them anyway, in which case it's expensive and slow to run it for every dev. (At that point you have enough devs that microservices 100% make sense, though)
  - ivan_gammel 8y ago
    Mocking modules for unit testing - yes. Testing the specific build artifact with a module replaced by a mock - no, it is not.
    - scarface74 8y ago
      A dependency injection framework where you use flags at the composition root to determine whether the “real” implementation class or the mock class is used based on the environment. IOrderService -> OrderService in production. IOrderService ->FakeOrderService when testing.
      - ivan_gammel 8y ago
        Do you realize that this is actually an anti-pattern, that adds unnecessary complexity and potential security problems to your app? Test code must be separated from production code - something, that should know every developer.
        scarface74 8y ago
        It’s basically a feature flag. I don’t like feature flags but it is a thing. But if you are testing an artifact, why isn’t the artifact testing part of your CI process? What you want to do is no more or less an anti pattern than swapping out mock services to test a microservice. I’m assuming the use of a service discovery tool to determine what gets run. Either way, you could screw it up by it being misconfigured.
        ivan_gammel 8y ago
        First of all it is the test code, no matter whether it's implemented as a feature flag or in any other way. Test code and test data shall not be mixed with the production one for many well-documented and well-known reasons: security, additional points of failure, additional memory requirements, impact on architecture etc. >But if you are testing an artifact, why isn’t the artifact testing part of your CI process? It is and it shall be part of the CI process. Commit gets assigned build number in tag, artifact gets the version and build number in it's name and metadata, deployment to CI environment is performed, tests are executed against specific artifact, so every time you deploy to production you have a proof, that the exact binary that is being deployed has been verified in its production configuration. >I’m assuming the use of a service discovery tool to determine what gets run. Service discovery is irrelevant to this problem. Substitution of mock can be done with or without it.

Except the language argument, don't you get all that by just having modules in your code (assuming a statically typed language since the boundaries are type checked)?

ivan_gammel 8y ago

Not really. For example, it's easier to mock a microservice, than a module, for testing purposes. Let's say you have component A and component B, A depends on B (dependency implemented via runtime sync or async call), B is computationally intensive or has certain requirements on resources that make it harder or impossible to test on developer's machine. You may want to test only A: with monolithic architecture you'll have to produce another build of the application, that contains mock of B (or you need something like OSGi for runtime module discovery). When both components are implemented as microservices, you can start a container with mock of B instead of real B.

scarface74 8y ago
Mocking modules for unit testing has been a solved problem for decades in almost every language.
- jrs95 8y ago
  And running an integration test on a single modular application is easy. Doing it for a distributed system is very hard.
  - ivan_gammel 8y ago
    Running E2E blackbox test is equally simple for all kinds of architectures, especially today, when it's so easy to create a clean test environment with multiple containers even on developer's machine. It may be harder to automate this process for a distributed system, but, frankly speaking, I don't see a big difference between a docker-compose file or a launch script for monolith - I've been writing such tests for distributed systems casually for several years and from my personal experience it's much easier to process the test output and debug the microservices than monolithic applications.
    - amirouche 8y ago
      > it's much easier to process the test output and debug the microservices than monolithic applications. You easier to debug end-to-end tests of a microservice architecture that monolith? That's not my experience. How do you manage to put side by side all the events when they are in dozen of files?
      - ivan_gammel 8y ago
        I just don't use files for anything (services should be designed with the assumption that container can be destroyed any time, so files are simply not an option here). If you are talking about the logs, there are solutions like Graylog to aggregate and analyze them.
      - scarface74 8y ago
        Using only files for logging is the last thing I would do in 2018. I use Serilog for structured logging. Depending on the log destination, your logs are either stored in an RDMS (I wouldn’t recommend it) or created as JSON with name value pairs that can be sent directly to a JSON data store like ElasticSearch or Mongo where you can do adhoc queries. https://stackify.com/what-is-structured-logging-and-why-developers-need-it/ https://stackify.com/what-is-structured-logging-and-why-deve...
  - bpicolo 8y ago
    Easy until you have 100,000 of them anyway, in which case it's expensive and slow to run it for every dev. (At that point you have enough devs that microservices 100% make sense, though)
- ivan_gammel 8y ago
  Mocking modules for unit testing - yes. Testing the specific build artifact with a module replaced by a mock - no, it is not.
  - scarface74 8y ago
    A dependency injection framework where you use flags at the composition root to determine whether the “real” implementation class or the mock class is used based on the environment. IOrderService -> OrderService in production. IOrderService ->FakeOrderService when testing.
    - ivan_gammel 8y ago
      Do you realize that this is actually an anti-pattern, that adds unnecessary complexity and potential security problems to your app? Test code must be separated from production code - something, that should know every developer.
      - scarface74 8y ago
        It’s basically a feature flag. I don’t like feature flags but it is a thing. But if you are testing an artifact, why isn’t the artifact testing part of your CI process? What you want to do is no more or less an anti pattern than swapping out mock services to test a microservice. I’m assuming the use of a service discovery tool to determine what gets run. Either way, you could screw it up by it being misconfigured.
        ivan_gammel 8y ago
        First of all it is the test code, no matter whether it's implemented as a feature flag or in any other way. Test code and test data shall not be mixed with the production one for many well-documented and well-known reasons: security, additional points of failure, additional memory requirements, impact on architecture etc. >But if you are testing an artifact, why isn’t the artifact testing part of your CI process? It is and it shall be part of the CI process. Commit gets assigned build number in tag, artifact gets the version and build number in it's name and metadata, deployment to CI environment is performed, tests are executed against specific artifact, so every time you deploy to production you have a proof, that the exact binary that is being deployed has been verified in its production configuration. >I’m assuming the use of a service discovery tool to determine what gets run. Service discovery is irrelevant to this problem. Substitution of mock can be done with or without it.