Avoid The 8 Fallacies of Distributed Software Development

Introduction

With today’s advanced technologies, distributed systems are becoming increasingly popular.

Today’s software products are mostly delivered over a network (the internet). By definition, this makes them distributed.

With proper design, distributed systems scale better, run faster, and are more reliable than traditional monolithic systems. However, distributed systems also come with their own unique set of challenges. From ensuring data is consistent to dealing with network latency, many things can go wrong and cause your product development to fail.

To make a successful distributed system, you must know the basics and avoid the eight most common mistakes. Suppose your developers are aware of these pitfalls and use the right strategies. Then, they can make new software architectures that take advantage of the power of distributed systems, avoid common problems, and make sure their projects succeed.

This article will look at the most common faulty mental models to help you avoid them and build better software today.

Let’s dive in.

What are the eight fallacies of distributed systems?

L. Peter Deutsch and others at Sun Microsystems made a list of the most common misconceptions held by new distributed application programmers. They called them the “fallacies of distributed computing.”

These false assumptions lead to severe application design, implementation, and operational issues. Being aware of these common mistakes prevents you from making the wrong assumptions about distributed computing.

Distributed systems often make eight mistakes that make them hard to scale, slow to respond, and unreliable.

These fallacies are:

1. The Network is Reliable
2. Latency is Zero
3. Bandwidth is Infinite
4. The Network is Secure
5. Topology Doesn’t Change
6. There is One Administrator
7. Transport Cost is Zero
8. The Network is Homogenous

Let’s tour this rogue’s gallery of common mistakes.

Distributed Systems Fallacy #1: The Network is Reliable

Even in a highly reliable physical network, transmissions fail.

Network devices drop packets, introduce latency, and even cause outages. You must plan to send each piece of information multiple times and plan on them arriving out of order.

This means you need ways to find and fix these problems or prepare for them ahead of time. For example, ensuring change requests are idempotent.

Distributed Systems Fallacy #2: Latency is Zero

There is always a round-trip time when sending data over an application’s network, whether physical or virtual.

Applications seem to be stuck when there is a delay between what the user does and how your program responds. You can overcome this latency by optimizing for performance, which is expensive. Alternatively, you can design for it up front using asynchronous user experience techniques.

Distributed Systems Fallacy #3: Bandwidth is Infinite

While businesses may only have to pay a little to get more capacity, it’s not unlimited or free. In addition, latency is not a constant value. It varies over time.

The bandwidth of your network connection is finite, even if your network is using fiber optic cables and has gigabit-speed connections between all systems. Your application should be built with the idea that each hop from one system to another will have limited bandwidth.

Besides that, availability is limited. Virtual networks, for example, often have limited capacity. This means that applications may need to throttle their usage to prevent network congestion.

This means that your application must be able to handle the fact that latency changes and must be able to automatically adapt to latency changes based on the type of activity being performed. You must carefully plan how your application will use network resources to make sure that it doesn’t exceed the capacity of the network.

Distributed Systems Fallacy #4: The Network is Secure

Even though there are risks to a distributed system’s security, they can be dealt with.

Any in-flight information is available for harvest. You mitigate this by always assuming someone is listening and using encryption.

On top of that, a denial-of-service (DoS) attack can crash your system. You must plan ahead to throttle incoming requests.

Distributed Systems Fallacy #5: Topology Doesn’t Change

Over time, your application topology will change.

Assuming a static topology causes unnecessary headaches. For example, if an application thinks a particular path will always be there, but if that path disappears, the application breaks. Therefore, you must always build an application to handle changes gracefully.

Distributed Systems Fallacy #6: There is one administrator

A distributed system involves multiple parties, and you must plan for them to have different priorities.

For example, the network administrator may want to run a network that is as reliable as possible. The application administrator may want to reduce costs by turning off unused services.

Distributed Systems Fallacy #7: Transport Cost is Zero

While there are many ways to achieve data flow between distributed systems, there is always some cost.

Networks with a lot of chatter can cause delays that, when added up, slow your system to a crawl. To stop this from happening, you should avoid making network calls inside loops and make sure that all messages sent out are coarse-grained and chunky instead of fine-grained and chatty.

Distributed Systems Fallacy #8: The network is homogenous.

If a system assumes a homogenous network. A network is homogenous if all nodes have the same network, hardware, and software. If your system is self-contained and only used in environments that you fully control and manage.

But it’s more likely that your system depends on one or more in-house or third-party services to work and will be put into places you don’t have full control over, such as cloud service providers.

To avoid falling victim to this fallacy, plan ahead for changing network configurations.

• Design: use technology neutral contracts for service interactions.
• Control: Use infrastructure as code (IAC). This is a key component of DevOps, where your infrastructure is modeled in code rather than manually managed. This way, your automated environments are governed by the same quality processes as your application source code, with versioning using source control, unit testing, and peer reviews.
• Monitor:To gain better visibility into the behavior of a distributed system, ensure that centralized logging, metrics, and tracing are part of the system’s design.
• Decouple: Use appropriate decoupling between system components. Decoupling allows for greater resiliency in the event of either planned (system upgrades) or unplanned (service failure) downtime.

Conclusion

By knowing about these pitfalls and using the right strategies, developers can make groundbreaking software architectures that make the most of the power of distributed systems and ensure their projects are successful.

Distributed systems are robust. They make applications more scalable and reliable. Distributed systems are also complex and challenging to implement well.

To ensure these projects work, the people working on them need to know about the eight mistakes of distributed systems and how to fix them.

This article gave a quick tour of some of the most common mistakes product developers make when making apps and how they can lead to significant security breaches and other problems. Your product designers and engineers must know these assumptions and avoid making them. And we covered a few hints that will help point you in the right direction.

Best wishes and warm regards—Matt

By the way

Are you ready to take advantage of the benefits of distributed systems?

We’ll give you a full analysis of your current system and make suggestions on how to upgrade to a distributed architecture. Our assessment will help you better understand the benefits of distributed systems and how they will improve your product line.

Click here now to learn more about how we can help you get started with distributed system development.