> But I'd venture a guess that lots of organizations have to find that middle ground between building constantly vs remodeling / improving the foundation. > I'

> But I'd venture a guess that lots of organizations have to find that middle ground between building constantly vs remodeling / improving the foundation. > I'm focusing a bit more on devops Shiny object syndrome can affect all fields. A dev story: One of the new projects at work is an invoice automation system. For whatever reason, the initial design called for Redis as a key value store, and pgsql for their relational data. Ops already supports a ton of services on a shoestring budget, and Redis isn't currently on the list. I only found out about it when I saw a PR documenting the dependencies; they're now researching whether Postgres's hstore is compatible with their needs. Unconstrained, it's easy to end up with lavish designs that spread ops too thinly. An ops story: Containers is the big one some ops members won't be quiet about. AFAICT, it provides us no real advantage over VMs, and we're likely to deploy containers on top of openstack VMs anyways. Of course, we deploy a number of open source apps like Drupal, WordPress, and MoinMoin that would need to be re-architected to support things like immutable infrastructure. And it's not like the dev has time to support those, they'd be busy auditing and fixing their own software.