3 ms·
I do custom enterprise software and there the story is somewhat different. In that landscape many existing workloads are either being migrated to VMs or contain
by meekins 5y ago
I do custom enterprise software and there the story is somewhat different. In that landscape many existing workloads are either being migrated to VMs or containers in the cloud or replaced with new cloud native applications. Companies are eager to have as minimal on-prem setup as possible (mostly for legacy software too difficult or risky to migrate).
For entirely new applications serverless solutions are usually the first option to be considered since they are very easy to operate. Many clients also don't have much expertise in-house for operating k8s so new workloads would be operated by outsourced ops teams or development teams themselves which is very expensive. Large enterprises also have formed some sort of "strategic partnership" or alliance with either Amazon or Microsoft so cloud agnosticism rarely enters the picture. In addition to being easier to operate, skilled development teams are also very fast to deliver on serverless since there's very little infrastructure-level things to worry about. The team can focus on business logic and delivering value from day 1. If you only look at Heroku I can assure you the market for serverless is much bigger and constantly growing.
- debarshri 5y agoThanks for your insight. What happens to their existing applications, do they move them to serverless too? I am working on an enterprise software in the space. Would love you be in touch with you and get some insights.
- meekins 5y agoThe most common approach I've seen is lift & shift to a VM and possibly some devops pixie dust on top to adopt golden image deployments. My perspective is limited and evidence anecdotal but I've seen only one on-prem to serverless "migration" project so far and that was a complete rewrite. The original codebase was ~20 years old, had a tight dependency on an expensive proprietary database and a variety of scalability issues so it would have needed thorough rearchitecting anyway. A more common pattern is to do the lift & shift and incrementally either create new services or migrate existing ones to serverless where it makes sense (the strangler pattern).