3 ms·

In general in a micro service environment, you try to build things so that 1) you don't need to run other things locally, and 2) if you did need to, the service

In general in a micro service environment, you try to build things so that 1) you don't need to run other things locally, and 2) if you did need to, the services are just containers so it's pretty easy to run one. But you tend to try to write your service so that it treats everything else it depends on like a vendor-provided API. Like, if you were building a Slack bot, you wouldn't ask Slack to let you pull down and run a local copy of Slack's API to test against. You'd maybe set up a test account in Slack's production system, and run your local bot against that to test it before you deploy it with credentials to run against your real slack account. In a microservice architecture, you integrate with other internal systems in the same way.

magicalhippo 3y ago
We're not big on microservices, but we do integrate with a lot of other systems. I find the opaqueness of other services to reduce development speed quite drastically. With local code I can view both sides of the fence and easily see if I'm using it wrong or if it's a bug in my colleagues code. Seems that if you're constantly developing against opaque services you'd end up in the same quagmire quite quickly?
- scarface_74 3y ago
  You shouldn’t care about anything outside of published contracts for dependencies. You’re slwags dependent on underlying APIs
  - magicalhippo 3y ago
    Of course I shouldn't. But when things don't work as I expect, it's far more efficient to be able to view the code on both sides, rather than only on my own side and try to guess what the other side is doing. Besides the usual suspect of wrong understanding on my end leading to misuse, this can also be due to lacking or wrong documentation of the other system, or bugs in the other system due to unexpected inputs or similar. Like just a few days ago we spent an unreasonable amount of time with an API of one of our customers, where we would get empty list back for some of our queries. Turned out something in their service crashed when handed national characters, despite accepting JSON and hence UTF-8 input and nothing in the documentation about English letters only. Rather than returning 400 or 500, the service returned 200 with an empty list, leading us to assume we did something wrong.
    - scarface_74 3y ago
      > But when things don't work as I expect, it's far more efficient to be able to view the code on both sides, rather than only on my own side and try to guess what the other side is doing. Are you able to view the source code of your platform vendor? Everyone is at some level dependent on Black box APIs. If you can document where with certain input you don’t get the expected output, you reach out to the team that is responsible for it whether internally or externally and they either explain it or they fix it. This is the API service I’ve been working with over the past five+ years - three actually working at AWS (Professional Services). https://boto3.amazonaws.com/v1/documentation/api/latest/index.html https://boto3.amazonaws.com/v1/documentation/api/latest/inde... I found a bug in one relatively new API that a service team released, I reached out to the team with a documented scenario and they fixed it. Other times they explained what I was doing wrong. That’s what any large organization does. I’ve worked with other vendors and internal teams plenty of times over the years.
- gen220 3y ago
  This is exactly why the "microservices" pattern is usually adopted along with the "monorepo" pattern. IMO, it's a strong anti-pattern to have the former without the latter.

magicalhippo 3y ago

We're not big on microservices, but we do integrate with a lot of other systems. I find the opaqueness of other services to reduce development speed quite drastically. With local code I can view both sides of the fence and easily see if I'm using it wrong or if it's a bug in my colleagues code. Seems that if you're constantly developing against opaque services you'd end up in the same quagmire quite quickly?

scarface_74 3y ago
You shouldn’t care about anything outside of published contracts for dependencies. You’re slwags dependent on underlying APIs
- magicalhippo 3y ago
  Of course I shouldn't. But when things don't work as I expect, it's far more efficient to be able to view the code on both sides, rather than only on my own side and try to guess what the other side is doing. Besides the usual suspect of wrong understanding on my end leading to misuse, this can also be due to lacking or wrong documentation of the other system, or bugs in the other system due to unexpected inputs or similar. Like just a few days ago we spent an unreasonable amount of time with an API of one of our customers, where we would get empty list back for some of our queries. Turned out something in their service crashed when handed national characters, despite accepting JSON and hence UTF-8 input and nothing in the documentation about English letters only. Rather than returning 400 or 500, the service returned 200 with an empty list, leading us to assume we did something wrong.
  - scarface_74 3y ago
    > But when things don't work as I expect, it's far more efficient to be able to view the code on both sides, rather than only on my own side and try to guess what the other side is doing. Are you able to view the source code of your platform vendor? Everyone is at some level dependent on Black box APIs. If you can document where with certain input you don’t get the expected output, you reach out to the team that is responsible for it whether internally or externally and they either explain it or they fix it. This is the API service I’ve been working with over the past five+ years - three actually working at AWS (Professional Services). https://boto3.amazonaws.com/v1/documentation/api/latest/index.html https://boto3.amazonaws.com/v1/documentation/api/latest/inde... I found a bug in one relatively new API that a service team released, I reached out to the team with a documented scenario and they fixed it. Other times they explained what I was doing wrong. That’s what any large organization does. I’ve worked with other vendors and internal teams plenty of times over the years.
gen220 3y ago
This is exactly why the "microservices" pattern is usually adopted along with the "monorepo" pattern. IMO, it's a strong anti-pattern to have the former without the latter.