Hacker News new | past | comments | ask | show | jobs | submit login

> it's about taking operational concerns into account early in the design of a piece of software and acknowledging that it's going to do much better in the wild when the people building it are also accountable to making it easy to operate.

I agree that it's important to be thinking about these future states and having those conversations from day 1. But, I also think that it's easy to abstract away all of the various pieces and dependencies of some application, because we're sold by cloud providers that this design is "reliable" and "robust" and more generally speaking "a better design." But, what if those things aren't actually needed at that point in an applications life? What problem is really being solved if these things don't present a problem? If the application has a few dozen daily users, why is every single piece of it an AWS service vs. a single AWS EC2 instance? It gets even worse than this, of course. I've seen instances where a team of developers had no idea their application was using ElastiCache and experienced application outages as a result of AWS maintenance windows.

Sometimes, I guess, it just strikes me as putting the cart before the horse. And specifically with AWS (but somehow less so with Heroku or DigitalOcean, in my head).




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: