3 ms·

I like this. I am a firm believer of keeping things simple until you need them. Service meshes have their place, and they are useful when your running at scale,

I like this. I am a firm believer of keeping things simple until you need them. Service meshes have their place, and they are useful when your running at scale, or you really need all the features, but most people don't need them. You often hear people asking for enhanced telemetry, or that they need it to load balance grpc. The simple solution is to fix the telemetry in your app, and get your grpc client to use a headless k8s service and set it up correctly. This is a bit more involved upfront, but its better than maintaining another tool, and adding the extra complexity to your infra.

francis-io 6y ago
I do agree your first point about keeping things simple. The problem comes when you grow big enough to then need these complicated things, it becomes hard to "turn the ship" re-engineering everything. I could easily argue that laying down the "main" parts of your intra up front, especially on new projects, might be worth it.
- theptip 6y ago
  It's true that it's more expensive to do the work later, but you also have way more resources later; in my experience the second term increases faster than the first one. Every day you spend wiring up infra is a day you're not iterating on your product, and from the accounts I've seen, most startups fail because they run out of money before they find PMF, not because they later got bogged down refactoring their V1 architecture. I advise keeping architecture as simple as possible at first by building a monolith (or maybe FaaS if you're really doing throwaway experimentation), and keep refactoring it until your domain knowledge has solidified and it's clear where your service boundaries actually are; it's very unlikely that you'll get the service split correct the first time if you do it too early.
- politelemon 6y ago
  That does require predicting or assuming what the future will look like. If it becomes an unsuitable choice, then you end up with the same problem of turning the ship and the pain that comes with it. Or if you can be obstinate enough, pass the overhead on to others around you which brings its own pain. It's just pain all around man. What can we do?

francis-io 6y ago

I do agree your first point about keeping things simple. The problem comes when you grow big enough to then need these complicated things, it becomes hard to "turn the ship" re-engineering everything. I could easily argue that laying down the "main" parts of your intra up front, especially on new projects, might be worth it.

theptip 6y ago
It's true that it's more expensive to do the work later, but you also have way more resources later; in my experience the second term increases faster than the first one. Every day you spend wiring up infra is a day you're not iterating on your product, and from the accounts I've seen, most startups fail because they run out of money before they find PMF, not because they later got bogged down refactoring their V1 architecture. I advise keeping architecture as simple as possible at first by building a monolith (or maybe FaaS if you're really doing throwaway experimentation), and keep refactoring it until your domain knowledge has solidified and it's clear where your service boundaries actually are; it's very unlikely that you'll get the service split correct the first time if you do it too early.
politelemon 6y ago
That does require predicting or assuming what the future will look like. If it becomes an unsuitable choice, then you end up with the same problem of turning the ship and the pain that comes with it. Or if you can be obstinate enough, pass the overhead on to others around you which brings its own pain. It's just pain all around man. What can we do?