I think what will be more important is targeting the type of application supported: old school, three tier app that are statefull everywhere, or cloud native, microservices apps that are stateless (shoving statefullness of to caches and databases).
I would listen to developers, but more likely an architect or head of development than allow the grass roots to start buying and using anything they wanted. I am not naive enough to believe that developers don’t go out and look at neat new stuff, a developer happy and content to just do maintenance on existing software is a rare commodity indeed. Developers may have introduced some tools such as Git, Github, JIRA and Jenkins but these will at some point still require some level of management buy in and approval , nor do they affect the company wide license expenditure.
There’s a lot on “this is how large organizations actually work,” which is good context for what all this “enterprise nonsense” is all about:
In order for a developer to sign up to a public cloud service any even remotely competent compliance driven department will ensure there is a process for approval for the spend which would include justification. If the initial spend is approved then there is a risk that a developer might be naive in his usage of the cloud environment and start moving data around or investing in massive amounts of computing power. This would normally be caught at a monthly bill cycle by any diligent IT manager/Director. If not then the finance team would certainly pick up on the unusual spend.
In summary: “hi, we’re a ‘large enterprise,’; cloud, we don’t do things like that.”