What factors prevent companies from shifting to distributed network architecture?

2.8k views23 Comments

Head of Security and Compliance in Software, 51 - 200 employees
One factor is the type of workload. For business applications, I don't necessarily require that kind of latency for prompt responses. But at the same time, a major enterprise is stuck with their architecture. Someday a company using new architecture will come in and probably take away from the benefits that they have to offer, while that first enterprise is just trying to stitch themselves together with the new models and still survive. But the majority of their architecture will still be stuck with those problems.

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.
CTO in Healthcare and Biotech, 11 - 50 employees
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.
3 Replies
CEO in Services (non-Government), Self-employed

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 Software, 51 - 200 employees

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?

CIO, 5,001 - 10,000 employees

It takes a long time to get there, so sometimes it's hard to convey the benefit versus the effort and get people to believe that they can even execute on it.

Sr. Director of Engineering in Software, 51 - 200 employees
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.
Vice President Global Head of Value Engineering in Software, 1,001 - 5,000 employees
While I remain a fan of distributed architecture primarily from a load balancing, recovery and scale perspective, the main concerns in shifting to this format are: 
1. Centralised offers a single point of control and easier governance mechanisms
2. Harder to manage updates in a distributed setup. Hence a challenge for larger orgs to go this way.
3. Different latencies & performance levels create a burden on IT from an efficiency standpoint.
4. Troubleshooting & diagnostics is not easy in a distributed setup and takes longer to resolve.
Chief Technology Officer in Healthcare and Biotech, 1,001 - 5,000 employees
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), 51 - 200 employees
2 main reasons
1. Requirement of workloads which need it
2. Skill set of the team to adapt.
Director of Engineering in Software, 51 - 200 employees
I think architectural complexity coupled with cost of implementing and managing it are some of the main factors. The benefits with distributed network might not many a times outweigh the effort you need to put in to achieve it.
CTO in Healthcare and Biotech, 2 - 10 employees
Customer requirements for security and availability are probably number one. Distributed is great, but if the customer is running their own network, they often want you to cater to them not the other way around. The second would be technical skillsets. Knowing what services to use and how to use them requires scarce skillset that can be cost-prohibitive. 
Chair and Professor, Startup CTO in Education, 5,001 - 10,000 employees
I think it is a combination of cost, workload, ease of management, and willingness to change. 
Vice President of Software Development in Finance (non-banking), 1,001 - 5,000 employees
Complexity, capacity, capability, and ability to operate @scale once in a distributed network and skill set to troubleshoot in the complex distributed network are some of the hindrances to moving to a distributed network. In general, when we are starting new it is easy however if it is been decades and the product landscape had become complex, it becomes complex to migrate. Also needed care to be taken to make sure the security design is apt and update the tech to make sure the additional hops are not adding up the latency. 

Content you might like

Too many active projects at once43%

Poor communication46%

Too many customizations47%

Misalignment with business priorities34%

Skills gaps31%

Lack of resources26%

Other (please list in the comments)1%


757 views1 Upvote

CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.
Read More Comments
47k views133 Upvotes324 Comments

Discretionary budgeting8%

Strategic budgeting72%

A combination of discretionary & strategic budgeting17%

Other (please explain in the comments)1%


918 views1 Comment