4 ms·

I'm not sure how I should be reading the article so maybe it's going over my head. > Rule 10: When to make a microservice > I would use a microservice when I

by maps7 6y ago

I'm not sure how I should be reading the article so maybe it's going over my head. > Rule 10: When to make a microservice > I would use a microservice when I have a relatively small and simple chunk of code that needs to run every once in a while. Isn't this wrong? There's no reason a microservice should just run once in a while. It also creates a lot of complexity for a simple chunk of code.

codingdave 6y ago
Most of this article could be ripped to shreds based on its accuracy. But that isn't the point - he has developed a set of rules and guidance that work for your average developer just slinging code in an enterprise. And while yes, almost everything he says is "wrong" if we push the details... I can see that they are all "close enough" to build a workable framework for your basic 9-5 1x dev.
- hamburga 6y ago
  > almost everything he says is "wrong" if we push the details Author here. Part of the point was to expose my ignorance and get people to rip it to shreds. So have at it if you want. I've actually learned a good amount so far using this method.
tumetab1 6y ago
I think there's a hidden assumption that the author didn't expose. > when I have a relatively small and simple chunk of code that needs to run every once in a while. I think "run every once in a while" actually means stable requirements. I think the number of executions per time is irrelevant. Being stable is the important thing. My theory is that "run every once in a while" is substituting stable requirements because that's what I also see in organizations. What is execute a lot usually has an higher importance for business which also translates to unstable requirements.
goalieca 6y ago
Some might say that you should only write one when you need to scale across servers or teams. These projects where everything is a microservice and a single team manages 30 of them are kind of insane.
hamburga 6y ago
OP here: yeah, that is wrong. I meant to say serverless, like AWS lambda. Fairly embarrassing. I just updated the blog.

by maps7 6y ago

codingdave 6y ago

Most of this article could be ripped to shreds based on its accuracy. But that isn't the point - he has developed a set of rules and guidance that work for your average developer just slinging code in an enterprise. And while yes, almost everything he says is "wrong" if we push the details... I can see that they are all "close enough" to build a workable framework for your basic 9-5 1x dev.

hamburga 6y ago
> almost everything he says is "wrong" if we push the details Author here. Part of the point was to expose my ignorance and get people to rip it to shreds. So have at it if you want. I've actually learned a good amount so far using this method.

tumetab1 6y ago

I think there's a hidden assumption that the author didn't expose. > when I have a relatively small and simple chunk of code that needs to run every once in a while. I think "run every once in a while" actually means stable requirements. I think the number of executions per time is irrelevant. Being stable is the important thing. My theory is that "run every once in a while" is substituting stable requirements because that's what I also see in organizations. What is execute a lot usually has an higher importance for business which also translates to unstable requirements.

goalieca 6y ago

Some might say that you should only write one when you need to scale across servers or teams. These projects where everything is a microservice and a single team manages 30 of them are kind of insane.

hamburga 6y ago

OP here: yeah, that is wrong. I meant to say serverless, like AWS lambda. Fairly embarrassing. I just updated the blog.