> "If it weren't containers it would be a new programming language, framework, or another agile methodology. Your argument has very little to do with containers

> "If it weren't containers it would be a new programming language, framework, or another agile methodology. Your argument has very little to do with containers." Agreed, containers are just one way to package software, they aren't the be-all-end-all when it comes to making software modular. One example of a modular design abstraction that does not rely on containers is the data access layer ( https://en.wikipedia.org/wiki/Data_access_layer https://en.wikipedia.org/wiki/Data_access_layer ). The idea being you can design a service that sits on top of a data store (whether that's a RDBMS or otherwise), that encapsulates the core business logic that you want the applications in your business to adhere to. This data access layer can potentially be shared by differing applications. The implementation of this does not rely on containers. Also, just in case "data access layer" (DAL for short) seems like a corporate IT term, I'd say the best tool I've ever seen that's used to build DALs is GraphQL. http://graphql.org/ http://graphql.org/