Hacker News Reader

I agree more or less with 1 and 4 mostly. But for monitoring either you would have to monitor the service calling this microservice or need to have a way to detect error.

> if it does have memory leaks anyways, just basic cpu/mem usage monitoring on your hosts

Who keeps on monitoring like this? How frequently would you do it? In a startup there are somewhere in the range of 5 microservice of that scale per programmer and daily monitoring of each service by doing top is not feasible.

> 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary.

Your solution literally is more complex than simple jenkins or ansible script for build then kubectl rollout restart yet is lot more fragile. Anyways the point stands that you need to have a way for deployment

My larger point is basically just against dogma and “best practices”. Every decision has tradeoffs and is highly dependent on the larger organizational context.

For example, kubectl rollout assumes that your service is already packaged as a container, you are already running a k8s cluster and the team knows how to use it. In that context, maybe your method is a lot better. But in another context where k8s is not adopted and the ops team is skilled at linux admin but not at k8s, my way might be better. There’s no one true way and there never will be. Technical decisions cannot be made in a vacuum.

Knowing k8s makes it a lot harder - there’s nothing wrong with apps on ec2.

Except for running out of money - or spending a lot of work on optimizing stuff yourself.

Which can also be done on a right sized ec2 instance.

> 4. security? well ok, PDFs can be vulnerable to parser attacks. so lock down the permissions and network rules on the service.

Haha. You're a bit of an optimist, eh?

This is scarily accurate to some of our services. Hasn't failed us yet, but we're preemptively moving to CICD with docker

> Overall this setup would work perfectly fine in a small/medium company and take 5-10x less time than doing everything the FAANG way.

The point was never comparing it to the FAANG way. The point is: it's easier (at the beginning) to maintain ONE monolith (and all the production stuff related to it) than N microservices.