5 ms·

Truth is an interesting concept. It's often subjective and has many forms. Within the context of the cloud, almost all cloud services are only mutable, so "trut

Truth is an interesting concept. It's often subjective and has many forms. Within the context of the cloud, almost all cloud services are only mutable, so "truth" is whatever the current state of the cloud actually is. Whatever is in Git is merely idealism. Whatever you are maintaining, read the docs completely first. And I mean cover to cover. Not just the one chapter you need to get a PoC up and running. You will wish you had later, and it will come in handy many times over your career. Consider it an investment in your future. Read books on microservices before you implement them. Whatever two-line quip you read on a blog will not be as good as reading several whole books from experts. Docker multi-stage builds won't work in some circumstances. Build optimization eventually gets complex, the more you rely on builds to be "advanced".

pabs3 4y ago
The only truth is the memory and disk contents of the devices that make up your cloud. Everything else is an abstraction of that, which discards data and potentially is out of sync with reality.
crdrost 4y ago
Thanks for the alternative microservices quip, it was better than the original. Indeed, I find that “microservices should only perform a single task” is a really dangerous way to phrase it because we have no idea what the article means by “task.” The classic microservices separation is to separate an ordering service from a shipping service, is each of those one “task”? Or at the most extreme, is saving an order distinct from returning the list of your outstanding orders? Even when people graduate to a language of DDD and refine, often they settle on “one microservice per bounded context” where “bounded context” means “separated however I want it separated at the time,” and has no consistent principle behind... This despite the fact that I think Eric was quite explicit in his explanation of the idea, he meant a mapping of the software idea to the fussy complex world of businesspeople and business language: perhaps a better way to phrase this is that it's one microservice per archetype of user, “we have people from the warehouses who all speak the same shipping jargon, we should have a microservice specifically for them which speaks their language,” and I think most developers target their microservices smaller than that, in which case it is definitely not “one microservice per bounded context”. Don't get me started on how “strong coupling” is shorthand for “coupled in ways I don't like” etc. ... Sometimes I feel like I'm on an episode of “whose line is it anyway?”, where everything is made up and the points don't matter.
- LawTalkingGuy 4y ago
  All guidance assumes it's for a thinking person. You should look at what could be learned, not insist that there be one unambiguous message and that it be earth-shaking. > I find that “microservices should only perform a single task” is a really dangerous way to phrase it because we have no idea what the article means by “task.” First off, it's not dangerous. It's just loosely defined. Second, it's not important to know their task size to still know that two different (to them!) things shouldn't be shoved together. If the two tasks fit together so well that it's a mere 5% extra code to do them both, then maybe they are two sides of the same coin. But if "one simple thing" is painful to implement maybe it's really two separate things under one blanket. > often they settle on “one microservice per bounded context” where “bounded context” means “separated however I want it separated at the time,” Right, because sometimes 'bounded context' is what Legal tells you about data residency and sometimes it's about optimal latency. > Don't get me started on how “strong coupling” is shorthand for “coupled in ways I don't like” Strong coupling is generally easy to define, relative to loose coupling, in any given language/platform. The value of engineering around it depends on the value of doing the thing which requires it multiplied by how often you have to do it.
  - KronisLV 4y ago
    > First off, it's not dangerous. It's just loosely defined. I'm not sure about this. Some people might take it at face value and end up with dozens if not hundreds of services for a domain that doesn't quite need them. Ergo, the project that they work on might have the development velocity plummet, because it has too much accidental complexity and ops overhead. That's how you get humorous parody videos like these ("Microservices" by KRAZAM): https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ As anyone who has ever seen SOLID or DRY taken as gospel, many people out there would probably agree with the claim that some general advice can definitely be dangerous.
    - LawTalkingGuy 4y ago
      > Some people might take it at face value and end up with dozens if not hundreds of services You're worried that someone junior enough to run with random advice is going to be able to rearchitect their entire codebase into hundreds of microservices and deploy it to production without testing its performance/stability/etc? I think they should try. It's a great way to learn why, and why not. > many people out there would probably agree with the claim that some general advice can definitely be dangerous. It's just mouth noises which aren't dangerous. We need to be able to hear other people's opinions (advice is just an opinion after all) without immediately adopting it.
thewisenerd 4y ago
while I wouldn't wish the bootstrap problem on my worst enemy, I think the idealism helps for at least versioning configuration changes, and partial component-level tear-downs and bring ups (you don't need this often, but when you do, you do). also, with k8s, nothing like deleting the wrong object or making a change and not knowing what it was, N revisions ago.
k__ 4y ago
"read the docs completely first" I learned from using software like Photoshop and Ableton Live, that you shouldn't underestimate the complexity of any software you use. Take a few days or weeks, if you can, to read docs or do high quality courses on the topic and it will make your life easier in the long run.

pabs3 4y ago

The only truth is the memory and disk contents of the devices that make up your cloud. Everything else is an abstraction of that, which discards data and potentially is out of sync with reality.

crdrost 4y ago

Thanks for the alternative microservices quip, it was better than the original. Indeed, I find that “microservices should only perform a single task” is a really dangerous way to phrase it because we have no idea what the article means by “task.” The classic microservices separation is to separate an ordering service from a shipping service, is each of those one “task”? Or at the most extreme, is saving an order distinct from returning the list of your outstanding orders? Even when people graduate to a language of DDD and refine, often they settle on “one microservice per bounded context” where “bounded context” means “separated however I want it separated at the time,” and has no consistent principle behind... This despite the fact that I think Eric was quite explicit in his explanation of the idea, he meant a mapping of the software idea to the fussy complex world of businesspeople and business language: perhaps a better way to phrase this is that it's one microservice per archetype of user, “we have people from the warehouses who all speak the same shipping jargon, we should have a microservice specifically for them which speaks their language,” and I think most developers target their microservices smaller than that, in which case it is definitely not “one microservice per bounded context”. Don't get me started on how “strong coupling” is shorthand for “coupled in ways I don't like” etc. ... Sometimes I feel like I'm on an episode of “whose line is it anyway?”, where everything is made up and the points don't matter.

LawTalkingGuy 4y ago
All guidance assumes it's for a thinking person. You should look at what could be learned, not insist that there be one unambiguous message and that it be earth-shaking. > I find that “microservices should only perform a single task” is a really dangerous way to phrase it because we have no idea what the article means by “task.” First off, it's not dangerous. It's just loosely defined. Second, it's not important to know their task size to still know that two different (to them!) things shouldn't be shoved together. If the two tasks fit together so well that it's a mere 5% extra code to do them both, then maybe they are two sides of the same coin. But if "one simple thing" is painful to implement maybe it's really two separate things under one blanket. > often they settle on “one microservice per bounded context” where “bounded context” means “separated however I want it separated at the time,” Right, because sometimes 'bounded context' is what Legal tells you about data residency and sometimes it's about optimal latency. > Don't get me started on how “strong coupling” is shorthand for “coupled in ways I don't like” Strong coupling is generally easy to define, relative to loose coupling, in any given language/platform. The value of engineering around it depends on the value of doing the thing which requires it multiplied by how often you have to do it.
- KronisLV 4y ago
  > First off, it's not dangerous. It's just loosely defined. I'm not sure about this. Some people might take it at face value and end up with dozens if not hundreds of services for a domain that doesn't quite need them. Ergo, the project that they work on might have the development velocity plummet, because it has too much accidental complexity and ops overhead. That's how you get humorous parody videos like these ("Microservices" by KRAZAM): https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ As anyone who has ever seen SOLID or DRY taken as gospel, many people out there would probably agree with the claim that some general advice can definitely be dangerous.
  - LawTalkingGuy 4y ago
    > Some people might take it at face value and end up with dozens if not hundreds of services You're worried that someone junior enough to run with random advice is going to be able to rearchitect their entire codebase into hundreds of microservices and deploy it to production without testing its performance/stability/etc? I think they should try. It's a great way to learn why, and why not. > many people out there would probably agree with the claim that some general advice can definitely be dangerous. It's just mouth noises which aren't dangerous. We need to be able to hear other people's opinions (advice is just an opinion after all) without immediately adopting it.

thewisenerd 4y ago

while I wouldn't wish the bootstrap problem on my worst enemy, I think the idealism helps for at least versioning configuration changes, and partial component-level tear-downs and bring ups (you don't need this often, but when you do, you do). also, with k8s, nothing like deleting the wrong object or making a change and not knowing what it was, N revisions ago.

k__ 4y ago

"read the docs completely first" I learned from using software like Photoshop and Ableton Live, that you shouldn't underestimate the complexity of any software you use. Take a few days or weeks, if you can, to read docs or do high quality courses on the topic and it will make your life easier in the long run.