When considering the evolution of some component activity - which we will call A (whether it's compute or storage or platform or electricity or will writing is irrelevant) ... 
Each of those evolved instances of the component has its own diffusion curve, with its own chasm to cross etc ... hence evolution consists of many diffusion curves ... BUT ...
You not only need to consider chasms (of which there are many in the evolution of a single thing) but also crossing boundaries (e.g. custom to product or product to commodity) introduces inertia caused by past success (related to practices associated with that component) ...
... for this reason of inertia, you often find the laggards to one stage of evolution (who have minimal installations of the component) become disproportionally early adopters of the next stage of evolution. Hence, switching back to diffusion curves then ...
... and the reason for this rant? One of the issues with serverless is we should find a disproportionate number of early adopters to serverless being laggards in IaaS precisely because they were laggards and do not have the installed base and inertia that comes with it.
Be very careful of your "DevOps" advice. There are at least two factions, one of which is experienced in IaaS and dismissive of serverless without the real experience to judge it. There can be significant inertia to change in those who consider themselves to be "cloudy".
So, if you want advice on serverless, only ask those who have been using it in production and have several years experience of it. I would strongly advise you not to listen to those who do not have significant and regular experience with it ...
... and I would only consider further investment below the framework (code execution) layer e.g. investment in containers ... if those truly experienced in serverless (not in containers or general DevOps or other) said that serverless was not suitable ...
... because whatever investment I make below the framework layer today will not only reinforce existing inertia but become something I need to replace later. I would be cautious about investing in what will become invisible subsystems ....
And if you're not telling at least 10% of your engineers to get experienced with serverless right now ... and yes, in some cases the business will have to force the agenda because of inertia ... then you will run the danger of spending vast sums on white elephants.
There is an entire industry building up to help you spend huge amounts of money building your own serverless environment ... be very careful. I expect to see many $1Bn wasted efforts.
So focus on public use, not building your own. Shelve those home grown serverless plans in favour of public use for a good five years. Once you have the experience, then you can decide. You'll thank me later.
