4 ms·

I have that rant daily at this point. Dev A: I need an API to CRUD Me: But we've been doing CRUD for 30 years without an API this is a small project Dev A: B

I have that rant daily at this point. Dev A: I need an API to CRUD Me: But we've been doing CRUD for 30 years without an API this is a small project Dev A: But I don't know how, its not best practice, my team lead agrees, here is a medium article, get with the times, etc. Me: Ok so you don't know how to do your job. Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy... Me: But all I need is still CRUD, I dont need to scale it, I dont care if its isolated, it should have been 100 lines of code Dev B: its not best practice, my team lead agrees, here is a medium article, get with the times, Docker run everywhere, etc. Me: But what I need to connect it to internal resources and use DNS? Dev B: load balancer! If only you have an AKS cluster! Me: We work in a 25 person company that needs some very basic CRUD. It will never scale past one deployment, ever, if it does, dont worry we will pay someone to do it right because we will be swimming in money. The problem is that people are starting to not know how to do simple things. So you get grumpy admins losing their marbles over the complexity of this BS. Most of the time things could be fixed faster, easier, deployed and managed easier using simple technologies that have been around for 20+ years. But lets wack it with the Python, Docker, React, NoSQL, GraphDB, K8S hammer because...? Not only that, the juniors don't know multiple technologies anymore they just know X. So sysadmins complain that devops is pushing more roles on them, while I have developers that have written full Node.js sites and dont know that IP or a Port, or TCP, UDP, is... So basically, same shtick different decade.

deleted 6y ago
[deleted]
Animats 6y ago
I made that comment once about "Soylent". (Remember Soylent? The nutritional drink?) That company made a big deal about their "tech stack". Not for manufacturing or quality control, but for ordinary web processing. Their order volume was so low that a CGI program on a low-end shared hosting system could do the job. But they were going to "scale", right? Amusingly, they eventually did "scale". They started selling through WalMart in bulk, and accepted their fate as yet another nutritional drink, on the shelves alongside Ensure Plus and Muscle Milk. Their "tech stack" was irrelevant to that.
- dynamite-ready 6y ago
  That's an amusing story. I suppose the Soylent board met a good salesperson, and the pitch worked. So when the team landed the contract, they had to justify their costs some way... I suspect almost every software project in existence is in some way a victim (or beneficiary...) of fanatical marketing. I remember working on an simple CMS site, amongst other things, for a pretty large company. When we begun the project, we were tasked with re-purposing an overworked Plesk instance to host the site. We eventually managed to do it, but then found the small amount of disk space that was left to us was getting chewed up by logs. So I reported this to my project manager, suggesting that we procure more HD space. I think I said something about us 'running out of memory on our hard drive'. The PM promised to feed this back to the client... A week later, our PM said that he and the client had resolved the issue. The client will pay for a new server with a stonking 96GB of RAM!!! That ought fix our 'memory' issue, right!!? I mean, it also came with a 1TB HD, a second box for redundancy, dev time for migration, and additional dev time for a switch to Journald, or Logrotate, so I wasn't rushing to point out the misunderstanding... Working with the second box over RedHat Pacemaker was all new to us though, and a complete PITA. But it was also another 'feature' to sell back to the client. They loved the sound of that. A site that couldn't go down... We made it work, but there was absolutely no real technical need for a Pacemaker cluster and 96GB*2 of RAM. It was just a simple CMS backed site. Occasionally, that's where such complexity comes from. Not the developers themselves, but some loose cannon of a saleperson. That said, these 'sales people' may even be developers themselves. I often think that's a large part of how and why questionably complicated software exists...
goatinaboat 6y ago
Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy... I have 100 different devs telling me "do this thing, it's easy" and it's easy for them, but now I have 100 different things to think about and make work together and devs never think about how their tiny thing fits into the big picture. 99% of web apps could be pure HTML + CSS on the front end, and Flask or something on the back end, talking pure SQL to Postgres. Really. That's all you need. And probably 99.99% of those apps that run internally to one company.
- quicksilver03 6y ago
  Docker facilitates the "throw a Dockerfile onto Ops and that's their problem now" mentality. That's perhaps not intentional, but choosing to over-optimize the developer experience makes life very hard for those who have to support and run the application over time.
  - goatinaboat 6y ago
    Docker facilitates the "throw a Dockerfile onto Ops and that's their problem now" mentality. That's perhaps not intentional, but choosing to over-optimize the developer experience makes life very hard for those who have to support and run the application over time. It also enables pushback along the lines of "your container doesn't run, and it's 100% your fault, as it is supposed to contain all its dependencies". So developers have unwittingly played into the hands of ops there ;-)
adamsea 6y ago
Agreed, mostly. To be fair I think that, based on my limited experience with React and Docker and Python, those 3 technologies have valid use-cases in smaller orgs. The other technologies I'm not familiar enough with to comment on. Also if I was gonna complain about someone I wouldn't complain about devs, I'd complain about team leads, engineering managers - the folks who should be guiding devs - and, the people at the business level who choose the team leads / engineering managers. The devs are at the bottom of the food chain; it's not their fault.
Karrot_Kream 6y ago
So how would you operate each of these bespoke services? One service uses TCP, one uses UDP, one uses SCTP. What happens if your buffer sizes are incorrect? What about if your keep alives are too aggressive? What happens if a problem in your TCP connection pool makes it seem like there's a networking issue and so you play around with your network settings only to have all your other protocols dive in performance? I sympathize with the OP for single developers or small teams (by small, I mean a team of 5 not in a larger corporation), but whenever you have more than a single team, you want to keep system management overhead low. Unifying around a single paradigm like gRPC and Docker containers means that not every team will have their own bespoke chroot configuration and you won't have to retune an HTTP client every time you interface with a new service. I think there's in general too little representation from small-scale or indie developers. I spend a lot of time working with the Gemini protocol outside of work and I appreciate the simpler approach that the protocol takes. I would love to see these sorts of stakeholders have a say in greater net architecture as well, but let's not pretend like this is all complexity for complexity's sake; this stuff is needed at scale.
- xorcist 6y ago
  That's a very good argument against the modern framework-conatiners-k8s stack. We used to be able to keep an organization wide track of things such as tcp services, buffer sizes, timeouts etc. but now it's all a black box deployed by a guy who cut and paste some yaml from a Medium article, at best. It's probably acceptable to not learn the details of what you're doing, as hardware is cheap and all that, but it also constitutes a glass ceiling for how much the organization learns. That's a bigger problem in the long run.
  - Karrot_Kream 6y ago
    Hopefully any organization that decides to use k8s goes into it understanding what they're getting into, but yes if you just get onto the hype train without thinking, you'll probably have a bad time when scaling.
- adev_ 6y ago
  >So how would you operate each of these bespoke services? One service uses TCP, one uses UDP, one uses SCTP. What happens if your buffer sizes are incorrect? Such bullshit. Since when we use UDP for a CRUD service ? Since when SCTP is even considered outside of the telecom world? HTTP and Rest-like API have been able to handle properly simple CRUD API since 20 years without problems, way before gRPC was even a thing. gRPC has its usage for large, complex API that required a proper RPC framework. But in 99% of the case, yes it's an overkill.
Nextgrid 6y ago
A company I used to work for needed a website. They already had a backend and a REST API (served on the same domain as the website should be) and the old website was served directly by the backend that also served the API. I am not aware of why it was chosen to retire that and separate the website into its own service - maybe there was a good reason, so I won't comment on that. However the approach they (or rather some frontend developer) chose was a React front-end (fair enough) with a Node.js backend that translated between the REST API and GraphQL (WTF). The existing API was served on the same domain so the new React website could've directly interacted with it without any problems. But no, this guy wanted to put "GraphQL" on his resume and so introduced an unnecessary extra component and potential point of failure that the company now has to support.
- ZephyrBluu 6y ago
  Yeah, GraphQL seems like a cool piece of tech that's overkill for 90% of the places it's used. I'm a bit confused as to how it's become so popular for normal development when it seems to have a lot more boilerplate and setup than a simple REST API.
  - say-vagnes 6y ago
    I feel like GraphQL is the new NoSQL. Not just that it's mistakenly adopted, but also that it is quite valuable for the right use cases, but the public doesn't seem to understand what those are. Do you really, _really_ need to support queries? 99/100, I'd guess no, and thus constraining people to a more defined interface and access pattern is simpler.
    - what-the-grump 6y ago
      Oh... you need to fill your RDMS with a bunch of JSON responses from your 3rd party API. So you can then decode them in memory because I actually need to select * where identifier = 'banana' to do analytics. Meanwhile the API returns highly structured data perfect for a RDMS, but we dont know how to query SQL without an API in the frontend. So welcome to my hell.
  - 6y ago
sfgweilr4f 6y ago
Dude! You need to run more servers. 250 should do it. I realize its just a simple page with a pair of boxes for name registration, but that's irrelevant! All the cool kids agree. You need infrastructure. It needs to be done as complex as possible! Complexity-as-a-Service won't just happen, you have to want to make it happen. You don't want to be uncool, do you? Looks at a specification on the desk Yep. We'll keep the first and last page. Everything else is gibberish. Next! Edit: Looks like a few people disagree. Perhaps they might like to explain why I saved a bunch of companies around 100k in AWS fees just by pruning their server requirements? No? And yes, one of the projects was a simple set of web forms that required 7 servers to run. We pruned it down to 3 and that was just for redundancy and load. That's just one example. If you disagree state your why.
- uryga 6y ago
  i didn't downvote you, but since you're asking – the first part of your comment is needlessly snarky and doesn't really add much beyond "yeah, i'm frustrated by people adding unnecessary complexity just because it's trendy". on the other hand, the part added in the edit sounds like it could be an interesting story! expanding on that would make for a more interesting comment: > I saved a bunch of companies around 100k in AWS fees just by pruning their server requirements. One of the projects was a simple set of web forms that required 7 servers to run. We pruned it down to 3 and that was just for redundancy and load. EDIT and if that thing about cutting down the specification really happened, just tell the story – no need to wrap it in a performance piece: > I've actually had people come to me with specifications so over-engineered that the whole 20-page doc could be simplified down to a single page without loss of functionality! EDIT 2 and i'm not saying "never use hyperbole"! just don't make it the whole point of your comment :)

deleted 6y ago

[deleted]

Animats 6y ago

I made that comment once about "Soylent". (Remember Soylent? The nutritional drink?) That company made a big deal about their "tech stack". Not for manufacturing or quality control, but for ordinary web processing. Their order volume was so low that a CGI program on a low-end shared hosting system could do the job. But they were going to "scale", right? Amusingly, they eventually did "scale". They started selling through WalMart in bulk, and accepted their fate as yet another nutritional drink, on the shelves alongside Ensure Plus and Muscle Milk. Their "tech stack" was irrelevant to that.

dynamite-ready 6y ago
That's an amusing story. I suppose the Soylent board met a good salesperson, and the pitch worked. So when the team landed the contract, they had to justify their costs some way... I suspect almost every software project in existence is in some way a victim (or beneficiary...) of fanatical marketing. I remember working on an simple CMS site, amongst other things, for a pretty large company. When we begun the project, we were tasked with re-purposing an overworked Plesk instance to host the site. We eventually managed to do it, but then found the small amount of disk space that was left to us was getting chewed up by logs. So I reported this to my project manager, suggesting that we procure more HD space. I think I said something about us 'running out of memory on our hard drive'. The PM promised to feed this back to the client... A week later, our PM said that he and the client had resolved the issue. The client will pay for a new server with a stonking 96GB of RAM!!! That ought fix our 'memory' issue, right!!? I mean, it also came with a 1TB HD, a second box for redundancy, dev time for migration, and additional dev time for a switch to Journald, or Logrotate, so I wasn't rushing to point out the misunderstanding... Working with the second box over RedHat Pacemaker was all new to us though, and a complete PITA. But it was also another 'feature' to sell back to the client. They loved the sound of that. A site that couldn't go down... We made it work, but there was absolutely no real technical need for a Pacemaker cluster and 96GB*2 of RAM. It was just a simple CMS backed site. Occasionally, that's where such complexity comes from. Not the developers themselves, but some loose cannon of a saleperson. That said, these 'sales people' may even be developers themselves. I often think that's a large part of how and why questionably complicated software exists...

goatinaboat 6y ago

Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy... I have 100 different devs telling me "do this thing, it's easy" and it's easy for them, but now I have 100 different things to think about and make work together and devs never think about how their tiny thing fits into the big picture. 99% of web apps could be pure HTML + CSS on the front end, and Flask or something on the back end, talking pure SQL to Postgres. Really. That's all you need. And probably 99.99% of those apps that run internally to one company.

quicksilver03 6y ago
Docker facilitates the "throw a Dockerfile onto Ops and that's their problem now" mentality. That's perhaps not intentional, but choosing to over-optimize the developer experience makes life very hard for those who have to support and run the application over time.
- goatinaboat 6y ago
  Docker facilitates the "throw a Dockerfile onto Ops and that's their problem now" mentality. That's perhaps not intentional, but choosing to over-optimize the developer experience makes life very hard for those who have to support and run the application over time. It also enables pushback along the lines of "your container doesn't run, and it's 100% your fault, as it is supposed to contain all its dependencies". So developers have unwittingly played into the hands of ops there ;-)

adamsea 6y ago

Agreed, mostly. To be fair I think that, based on my limited experience with React and Docker and Python, those 3 technologies have valid use-cases in smaller orgs. The other technologies I'm not familiar enough with to comment on. Also if I was gonna complain about someone I wouldn't complain about devs, I'd complain about team leads, engineering managers - the folks who should be guiding devs - and, the people at the business level who choose the team leads / engineering managers. The devs are at the bottom of the food chain; it's not their fault.

Karrot_Kream 6y ago

So how would you operate each of these bespoke services? One service uses TCP, one uses UDP, one uses SCTP. What happens if your buffer sizes are incorrect? What about if your keep alives are too aggressive? What happens if a problem in your TCP connection pool makes it seem like there's a networking issue and so you play around with your network settings only to have all your other protocols dive in performance? I sympathize with the OP for single developers or small teams (by small, I mean a team of 5 not in a larger corporation), but whenever you have more than a single team, you want to keep system management overhead low. Unifying around a single paradigm like gRPC and Docker containers means that not every team will have their own bespoke chroot configuration and you won't have to retune an HTTP client every time you interface with a new service. I think there's in general too little representation from small-scale or indie developers. I spend a lot of time working with the Gemini protocol outside of work and I appreciate the simpler approach that the protocol takes. I would love to see these sorts of stakeholders have a say in greater net architecture as well, but let's not pretend like this is all complexity for complexity's sake; this stuff is needed at scale.

xorcist 6y ago
That's a very good argument against the modern framework-conatiners-k8s stack. We used to be able to keep an organization wide track of things such as tcp services, buffer sizes, timeouts etc. but now it's all a black box deployed by a guy who cut and paste some yaml from a Medium article, at best. It's probably acceptable to not learn the details of what you're doing, as hardware is cheap and all that, but it also constitutes a glass ceiling for how much the organization learns. That's a bigger problem in the long run.
- Karrot_Kream 6y ago
  Hopefully any organization that decides to use k8s goes into it understanding what they're getting into, but yes if you just get onto the hype train without thinking, you'll probably have a bad time when scaling.
adev_ 6y ago
>So how would you operate each of these bespoke services? One service uses TCP, one uses UDP, one uses SCTP. What happens if your buffer sizes are incorrect? Such bullshit. Since when we use UDP for a CRUD service ? Since when SCTP is even considered outside of the telecom world? HTTP and Rest-like API have been able to handle properly simple CRUD API since 20 years without problems, way before gRPC was even a thing. gRPC has its usage for large, complex API that required a proper RPC framework. But in 99% of the case, yes it's an overkill.

Nextgrid 6y ago

A company I used to work for needed a website. They already had a backend and a REST API (served on the same domain as the website should be) and the old website was served directly by the backend that also served the API. I am not aware of why it was chosen to retire that and separate the website into its own service - maybe there was a good reason, so I won't comment on that. However the approach they (or rather some frontend developer) chose was a React front-end (fair enough) with a Node.js backend that translated between the REST API and GraphQL (WTF). The existing API was served on the same domain so the new React website could've directly interacted with it without any problems. But no, this guy wanted to put "GraphQL" on his resume and so introduced an unnecessary extra component and potential point of failure that the company now has to support.

ZephyrBluu 6y ago
Yeah, GraphQL seems like a cool piece of tech that's overkill for 90% of the places it's used. I'm a bit confused as to how it's become so popular for normal development when it seems to have a lot more boilerplate and setup than a simple REST API.
- say-vagnes 6y ago
  I feel like GraphQL is the new NoSQL. Not just that it's mistakenly adopted, but also that it is quite valuable for the right use cases, but the public doesn't seem to understand what those are. Do you really, _really_ need to support queries? 99/100, I'd guess no, and thus constraining people to a more defined interface and access pattern is simpler.
  - what-the-grump 6y ago
    Oh... you need to fill your RDMS with a bunch of JSON responses from your 3rd party API. So you can then decode them in memory because I actually need to select * where identifier = 'banana' to do analytics. Meanwhile the API returns highly structured data perfect for a RDMS, but we dont know how to query SQL without an API in the frontend. So welcome to my hell.
- 6y ago

sfgweilr4f 6y ago

Dude! You need to run more servers. 250 should do it. I realize its just a simple page with a pair of boxes for name registration, but that's irrelevant! All the cool kids agree. You need infrastructure. It needs to be done as complex as possible! Complexity-as-a-Service won't just happen, you have to want to make it happen. You don't want to be uncool, do you? Looks at a specification on the desk Yep. We'll keep the first and last page. Everything else is gibberish. Next! Edit: Looks like a few people disagree. Perhaps they might like to explain why I saved a bunch of companies around 100k in AWS fees just by pruning their server requirements? No? And yes, one of the projects was a simple set of web forms that required 7 servers to run. We pruned it down to 3 and that was just for redundancy and load. That's just one example. If you disagree state your why.

uryga 6y ago
i didn't downvote you, but since you're asking – the first part of your comment is needlessly snarky and doesn't really add much beyond "yeah, i'm frustrated by people adding unnecessary complexity just because it's trendy". on the other hand, the part added in the edit sounds like it could be an interesting story! expanding on that would make for a more interesting comment: > I saved a bunch of companies around 100k in AWS fees just by pruning their server requirements. One of the projects was a simple set of web forms that required 7 servers to run. We pruned it down to 3 and that was just for redundancy and load. EDIT and if that thing about cutting down the specification really happened, just tell the story – no need to wrap it in a performance piece: > I've actually had people come to me with specifications so over-engineered that the whole 20-page doc could be simplified down to a single page without loss of functionality! EDIT 2 and i'm not saying "never use hyperbole"! just don't make it the whole point of your comment :)