Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> For every project/job/app that needs the AWS levels of resilience (...)

I don't think you're framing the issue from an educated standpoint. You're confusing high-availability with not designing a brittle service by paying attention to very basic things that are trivial to do. For example, supporting very basic blue-green deployments that come for free in virtually any conceivable way to deploy services. You only need a reverse proxy and just enough competence to design and develop services that can run in parallel. This is hardly an issue, and in this day and age not being able to pull this off is a hallmark of incompetence.



> I don't think you're framing the issue from an educated standpoint.

And I think you'd make a better point without the personal remarks and/or skepticism over my competence.

I mean, was all this really necessary to make your point?

> myopic, naive, clueless take

> specious reasoning

> If you work on single-person "teams" maintaining something that is barely used and does not even have SLAs and can be shut down for hours

> a place of clueless buzzwords

> not understanding what they are talking about

> hallmark of incompetence

I also think you're ignoring what I said about 30-odd years of resilience that came before microservices.

> For example, supporting very basic blue-green deployments that come for free in virtually any conceivable way to deploy services.

I'm genuinely confused here: what does that have to do with creating monoliths? Are you claiming that monoliths prevent a whole lot of good practices (blue-green, canary deployments, whatever)?

Because monoliths have been deployed in a gradual rollout fashion before, have been multi-sited for DR rollovers onto secondaries, have been deployed with hot rollovers, etc.

There are, right now, COBOL "monoliths" running and managing a significant part of your life.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: