4 ms·

I applaud the author for sharing their notes. But also, this is why HN (and general upvote-anything-that-looks-interesting forums) sucks. If you are actually de

I applaud the author for sharing their notes. But also, this is why HN (and general upvote-anything-that-looks-interesting forums) sucks. If you are actually defining architecture, you should not be reading these kind of blog posts. I get that they are interesting to the layman, but so is The Anarchist's Cookbook. Don't make whatever you read in The Anarchist's Cookbook. And I'm crabbing about this because I am easily susceptible to Anarchists Cookbooks. I have had to implement X tech before, and googled for "How do I X", and some blog post came up saying "For X, Use Y". I'm too lazy to read 5 books on the general concept, so I just dive in and immediately download Y and run through the quick-start guide. After spending a while getting it going and getting past the "quick start", I wonder, "Ok, where's the long-start? What's next?" And that doesn't exist. And later, after a lot of digging, it turns out Y actually really sucks. But the blog post didn't go into that. I wasted my time (my own fault) because I read a short blog post. A lot of people live by Infrastructure as Code, and so they will reach for literally anything which has that phrase in its description. But you don't need it to throw together an MVP, and a lot of the IaC "solutions" out there are annoying pieces of crap. I guarantee you that if you pick any of them up, you are in for months of occasionally painful edge cases where the answer to your problem is "You just weren't using it the right way." In reality, if you want to be DevOps (yes, I'm using DevOps as an adjective, ugh) you should probably develop your entire development and deployment workflows by hand, and only when you've accomplished all of the basic requirements of a production service by hand (bootstrapping, configuration, provisioning, testing, deployment, security, metrics, logging, alerts, backup/restore, networking, scalability, load testing, continuous integration, immutable infrastructure & deployments, version-controlled configuration, documentation, etc), then you can start automating it all. If you've done all of these things before, automating it all from the start may be a breeze. If you haven't, you may spend a ton of time on automation, only later to learn that the above need to be changed, requiring rework of the automation.

dshacker 7y ago
Yeah, in reality I was weary about adding the links, these solutions are often created after a problem arose in the system. But I wanted to provide a few places to see what's the initial paths for a beginner to find out more. I can't count the times when I wasn't as knowledgeable approached a conversation about Chef and Puppet that didn't make sense to me, even after I read what Chef and Puppet did. It could be, in the other side, that you really don't grasp the need for these technologies until you've had to manually implement one. Things like the UUIDs are basic to hook up to anything. I can often relate this feeling with nutritional advice. "If you want to be more healthy, eat more advocados", if you only eat advocados, but don't understand what's behind it, or the premise behind it, you'll probably get fat. But if someone tells you "Advocados are a good way to supplement your fats without blah blah blah" and you understand that there isn't a unique solution, then you'll probably be healthier.
james_s_tayler 7y ago
Blame the economics of the internet. Quick starts are all you need for eyeballs. I enjoyed the article. If I'm going to sleep easy at night I'm also going to do a lot more study than just read a blog post here and there. I agree about the "where's the long-start guide?" sentiment though. I think that all the time. You see people say here is how to do event sourcing! Which is nice for their toy sized domain and toy architecture they have concocted. It's usually totally unworkable or woefully incomplete in a production setting. That being said, finding a multitude of reference architectures, plus a handful of "war stories", plus a in-depth long-form educational resource about the topic is usually enough to get you to something workable and real-world.

dshacker 7y ago

Yeah, in reality I was weary about adding the links, these solutions are often created after a problem arose in the system. But I wanted to provide a few places to see what's the initial paths for a beginner to find out more. I can't count the times when I wasn't as knowledgeable approached a conversation about Chef and Puppet that didn't make sense to me, even after I read what Chef and Puppet did. It could be, in the other side, that you really don't grasp the need for these technologies until you've had to manually implement one. Things like the UUIDs are basic to hook up to anything. I can often relate this feeling with nutritional advice. "If you want to be more healthy, eat more advocados", if you only eat advocados, but don't understand what's behind it, or the premise behind it, you'll probably get fat. But if someone tells you "Advocados are a good way to supplement your fats without blah blah blah" and you understand that there isn't a unique solution, then you'll probably be healthier.

james_s_tayler 7y ago

Blame the economics of the internet. Quick starts are all you need for eyeballs. I enjoyed the article. If I'm going to sleep easy at night I'm also going to do a lot more study than just read a blog post here and there. I agree about the "where's the long-start guide?" sentiment though. I think that all the time. You see people say here is how to do event sourcing! Which is nice for their toy sized domain and toy architecture they have concocted. It's usually totally unworkable or woefully incomplete in a production setting. That being said, finding a multitude of reference architectures, plus a handful of "war stories", plus a in-depth long-form educational resource about the topic is usually enough to get you to something workable and real-world.