What factors prevent companies from shifting to distributed network architecture?
Sort By:
Oldest
CTO in Healthcare and Biotech2 years ago
One problem could be people’s unwillingness to change from legacy to centralized, to decentralized, to distributed architecture. Not everyone has the redundancy and the willingness to move from one architecture to the other, even though they might have the resources. They may even have the buy-in from the CEO and everyone else at that level. But some people prefer to stay in their comfort zone. Startups are more likely to move to decentralized or distributed, but bigger companies might not be willing.CEO in Services (non-Government)2 years ago
In some respects, I completely agree with you. It's about willingness and about budget and time and capability. But is it reluctance to move or is it a lack of understanding of the benefit?
Head of Security and Compliance in Software2 years ago
Is it actually a lack of understanding, or is it due to the complexity of what was previously built that cannot be easily uplifted to the new model?
Sr. Director of Engineering in Travel and Hospitality2 years ago
It depends on different things: first, being the application architecture (monolith or modular), then the type of network payloads being exchanged as well. The architecture and design choices of how redudancy and scalability are implemented in old application defines how easy or tough it is to move it distributed environment without much refactoring.Chief Technology Officer in Healthcare and Biotech2 years ago
There are a number of factors.For one, is it relevant to their application requirements?
Another is do they have the technical skill and know-how, not only to shift but even to recognise the possible options and to consider them.
And then there’s always the old issues about technical debt and legacy and maybe an organisation wants to shift but it’s current app is monolithic and has a fragmented code base and this and that - all meaning they may well want to change but feel trapped or paralysed.
CTO in Finance (non-banking)2 years ago
2 main reasons1. Requirement of workloads which need it
2. Skill set of the team to adapt.
As for cloud native software, once you build your architecture from the beginning to make sure that you can deploy anywhere, you have a lot more utility to do distributed. And even the cloud native companies that started about 10 years back, had to go through an extremely painful evolution to be able to deploy anywhere. In the last few years, Kubernetes has really matured. And if you adopt Kubernetes today, you can replicate and deploy in a different data center, anywhere in the world in a matter of a couple of days, even on public infrastructure. But those cloud-native companies that started on AWS, for example, didn't have those models at that time. Migrating and modernizing them is a big pain because they already have the workloads running. On the other hand, if you start with a clean slate, it's much easier for you.