People keep asking ...
1) serverless first, on a public provider. Don't rebuild services that already exist, consume them.
2) If you must, then use containers sparingly on a public provider. Remember containers are less constrained and flexibility is not a friend.
1/2
1) serverless first, on a public provider. Don't rebuild services that already exist, consume them.
2) If you must, then use containers sparingly on a public provider. Remember containers are less constrained and flexibility is not a friend.
1/2
2/2
If you're told that you need to build on-premise then stop, robustly challenge the idea, question why is this, ask if anyone has actually used serverless and explain you'll consider a proposal whilst cutting IT spending, reducing headcount and sweating existing assets.
If you're told that you need to build on-premise then stop, robustly challenge the idea, question why is this, ask if anyone has actually used serverless and explain you'll consider a proposal whilst cutting IT spending, reducing headcount and sweating existing assets.
X : Why reduce headcount or sweat existing assets?
Me : Removal of inertia. Make sure the axe falls on those wedded to past practice. Serverless isn't a question of "if" but "when" and whilst you should give people a path (i.e. investment in education), inertia must be managed.
Me : Removal of inertia. Make sure the axe falls on those wedded to past practice. Serverless isn't a question of "if" but "when" and whilst you should give people a path (i.e. investment in education), inertia must be managed.
