Cover the basics and learn how to design and develop distributed systems.

Become a Distributed Systems Professional

Gone are the days when monolithic applications were the norm. Most applications we use today are too complex for that type of construction. Instead, most applications that appear as a single unit are actually built as a collection of inter-operating but independent computational components. Developers are expected to have mastery over a programming language or two. Moreover, they should also know the basics of distributed systems.

In this module, we’ll learn what distributed systems are, and learn about the challenges unique to distributed systems. We’ll cover popular architectural patterns for achieving targets like replication and sharding. We’ll complete the module with a study of two popular distributed systems: Apache Spark and Apache Druid. With the knowledge gained through this module, we’ll be able to design and develop distributed systems. We’ll also develop an understanding of optimal design and architectural choices based on the application requirements.

Introduction to Distributed Systems for Dummies

The last topic we’ll cover in this chapter is maintainability.

# What is maintainability?


A **maintainable** distributed system should be:

- Easy to operate and keep running
- Easy for developers and newcomers to understand the system
- Should easily be extensible, if further use cases and features are to be incorporated

Maintainability is the combination of the above three properties in a distributed system. Let’s discuss this briefly.

# Easy to operate

If a distributed system is difficult to operate, it will be increasingly difficult to keep it running. As a developer, it is certainly crucial to put sincere effort into ensuring the operability of your system.

In the industry, there are several standard practices that you should consider, namely:

- **Adding visible monitoring and logging**: Add monitoring and logging mechanisms to your system, and make them visible via specific platforms. For instance, many companies use third-party services (like Datadog) for monitoring their systems.

- **Building automation support**: It should be simple to quickly bootstrap the critical parts of your system so that in times of disaster, you can quickly respond.

- **Creating proper documentation**: New developers joining your team should be benefiting from the docs that you provide. Good documentation will help you build and scale a skilled developer team. Also, when things fail, developers should have proper docs at their disposal so that they can conduct the recovery procedure.

- **Implementing a self-healing mechanism**: If things go wrong, the system should try to fix the issue itself. This is very crucial to building a robust system. Achieving a self-healing mechanism can be hard but the outcome is worth it. Though this self-healing mechanism should allow developers to take control if required.

- **Minimizing surprises**: As an owner, you should list the stuff that might go wrong and create recovery processes for each. If you encounter new surprises, learn from them, document what you learned, and enhance the recovery mechanism. In time, this will help you minimize surprises in your system.

# Easy to understand

A maintainable distributed system has to be easy to understand. If a new developer joins tomorrow, they should understand the system with reasonable effort. Distributed systems tend to get complicated quickly. You should be cautious about this.

Let’s briefly look at a few industry standard practices:

- **Avoid complicated dependencies**: Try to avoid complex dependencies as much as possible. It’s reasonable that your system will have dependencies on other systems or different third party services. Try to keep them simple and easy to understand. Don’t let your system get tangled in dependencies.

- **Avoid making assumptions**: Many systems get overly complicated just because someone down the line makes an assumption with no convincing logic. A hunch might work once or twice, but not always. Try to avoid this. Sometimes developers make changes that include hidden assumptions which are difficult to track down when things go wrong. 

# Easy to extend

A system is unlikely to remain the same over time. Businesses grow, new use cases are created, features have to be added, etc. Over time, the system will be further enhanced from its current state, and this is natural.

If the system is not built in an extensible way, then it will be increasingly difficult to maintain as it grows. To make an extensible system, you can keep a few practices in mind:

- **Develop good coding practices**: This practice builds a consistent codebase and greatly helps extendability. Over time, many developers will work on your system and these people may have different styles. If you can ensure good practices, it will be easier to extend the codebase when adding new features.

- **Create the habit of refactoring when required**: If you find a part of the codebase that can be refactored into a better version, do it. Many times developers avoid refactoring—eventually the things that need to be refactored add up and the task becomes so massive that it never gets done.

- **Build a well-defined deployment procedure**: Developers should be able to go from one development to another deployment with ease. To achieve this, build automation and create documentation where required.

---

# Key takeaways

- Maintainability is what keeps your system alive in the long run. 
- A lot of effort will be put into maintaining the system after building it.
- As the owner of a system, try to ensure maintainability from the very beginning of the development process.

Learn about maintainability in distributed systems.