What the hell have you built? Turns out a pretty straightforward service.

That diagram is just aws, programming language, database. For some reason hadoop I guess. And riak/openstack as redundant.

It just seems like pretty standard stuff with some seemingly small extra parts because that make me think that someone on the team was familiar with something like ruby, so they used that instead of using java.

"Why is Redis talking to MongoDB" It isn't.

"Why do you even use MongoDB" Because that's the only database there, and nosql schemaless solutions are faster to get started... because you don't have to specify a schema. It's not something I would ever choose, but there is a reason for it.

"Let's talk about scale" Let's not, because other than hadoop, these are all valid solutions for projects that don't prioritize scale. Things like a distributed system aren't just about technology, but also data design that aren't that difficult to do and are useful for reasons other thant performance.

"Your deployment strategy" Honestly, even 15 microservices and 8 databases (assuming that it's really 2 databases across multiple envs) aren't that bad. If they are small and can be put on one single server, they can be reproduced for dev/testing purposes without all the networking cruft that devops can spend their time dealing with.

▲

lwn 2 days ago | parent | next [-]

This comment makes this thread a great time capsule. Given that the website is now over 10 years old, it perfectly illustrates how much 'best practices' and architectural complexity (and cloud bills) have changed since then.

▲

preommr 2 days ago | parent [-]

No no, don't give me this.

I was there before 10 years ago. I remember the pain in the ass that was hosting your own web server and own hardware, dealing with networking issues with cisco switches and thinking about getting a ccna. I remember the days of trying to figure out php and ranodm ass modules or how python and wsgi fit together on a slow ass windows machine instead of just spinning up an app and doing network calls using a spa.

Have you guys just forgotten all the enterprise crap that existed? Have you guys forgotten before that how things like compilers (ones you had to pay exorbintant amounts of money for) and different architectures were the headaches?

It's been two steps forward, one steps back, but we're still way better off.

Yes, people bring in k8s because they want to resume build and it goes poorly, but I've also used k8s in my personal setup that was much easier than the poor man's version I had of it.

All of this is just rose-tinted glasses, and people throwing the baby out with the bathwater. Just because some people have bad experiences with microservices because people don't often do them right, people just write them off completely.

	▲	actionfromafar a day ago \| parent [-]
		I know people who can wrangle k8s and set up rules in whatever it's called to spin up and down the whole kaboodle of services effortlessly. It's like they know a whole level of programming I'm not familiar with, at all. I know the dotnet stuff pretty well, after many years fiddling with it. I do stuff in dotnet now I didn't have even terminology to talk about before. What they do in k8s and friends reminds me of that. I personally don't care for it and if I design something I make it so it avoids that stuff if I can at all help it. But I've come to see that it can have real value. The thing is though, that then you really need someone to be that very competent ops person. If you're a grug like me, you don't get many shots to be good at something. I probably don't have the years in me to be good at both ops and "pure" programming. So if you are a startup and you're not some kind of not only very smart but smart, fast and with taste, maybe pick your battles. If you are great at the ops side, ok, maybe design it from that perspective and hire a bunch of not-made-of-unobtainium regular middle-of-the-road coders to fill in what the microservices and stuff should contain and manage those. This requires money for a regular hiring budget. (Or you are supersmart and productive and "play pretend enterprise" with all roles yourself. But I have never seen such a person.) Or focus on a tight design which can run without any of that, if you come more from the "I'm making a single program" part of the world. Tinkering syndrome can strike in any kind of design, so you need personal maturity whatever path you choose.

▲

whstl 2 days ago | parent | prev | next [-]

> Honestly, even 15 microservices and 8 databases (assuming that it's really 2 databases across multiple envs) aren't that bad

Sure, they aren't bad. They're horrible.

▲

JSR_FDED 2 days ago | parent | prev | next [-]

Whoosh

▲

wiseowise 2 days ago | parent | prev [-]

> Honestly, even 15 microservices and 8 databases (assuming that it's really 2 databases across multiple envs) aren't that bad.

Clown fiesta.