Starting point
When we grow as software developer, the scope of focus increases by default, which means one goes from working on low level designs to high level designs, working on single component to multiple components(system), working on single system to multiple systems(organisation level architecture). This growth demands that we increase the scope of our knowledge to next level, so that we can efficiently understand, create, maintain and deprecate the systems.
While there is lot of content around what and why of distributed systems, the focus area of this post is to share learning, experiences and best practices gained while working with distributed systems.
Working with Distributed Systems
These days its a must to have knowledge on "what are distributed systems" and "how they work" in order to grow as a software developer. The reason is that on daily basis, there are so many webapps or online applications which we use to either be more productive at work or even for basic communication with our peers. Without a doubt, all these apps are implementing "Distributed systems" concept in order to be robust, highly available, fault tolerant, work in asynchronous mode and with various other benefits.
"Distributed system" , as the words suggest that the "system" is distributed in nature. Now distribution can be in terms of application usage pattern, server's geographical location, responsibilities of application, etc.
But all of this comes as a cost, for example if you want to make your application fault tolerant, which means you want your application to be running and serving traffic even if there happens to be an outage at the company where you have hosted your application. Best practices suggest remediating this situation by deploying your application into multiple availability zones(for instance at different geographical locations), which inherently means that you now have a fleet instead of just single server, which means more cost.
Working with distributed systems tends to increase complexity and suddenly concept of maintenance becomes even more important than monolithic systems. Monolithic systems are opposite to "distributed systems" in terms of "handling of responsibilities". A Monolithic system handles all the responsibilities on its own, which will be simple to maintain, but will be hard to handle in cases where this system itself goes down for any reason. Responsibilities are the different functionalities which are performed by the application for example, UI rendering, data processing and storage, monitoring, logging to name a few.
As a developer, its always better to have basic understanding of already built and in-use distributed systems in market. Today, we have so many cloud services providers. These are best examples of distributed systems in there own, because they have to fulfil mostly all the things which are required in distributed systems to run their business itself. These cloud providers offers many maintained services which we should be aware of, and become expert in knowing when and where to use these services to design a better system.
Distributed systems have various characteristics, and we should be aware of them all. It doesn't necessarily mean to incorporate all of them within the same system, the decision to trade-off which characteristic of Distributed System comes from a combination of lot of factors like project fund limits, service provider's limits, stage of application (whether its already receiving huge traffic or its just about to start), etc. These information points become very useful, as developer so that we know, what is the best option for us to solve a problem. For solving the same problem, we can have many systems with different designs, but we have to pick the one which fits in all constraints of the problem and at the same point is scalable, maintainable, and cost effective to business.
Hopefully you would have learned something from the post, in case you want to know more about the topic or want to hear on another topic, please feel free to comment.
Top comments (0)