Unpacking Distributed Applications: What Are They? And How Do They Work?
Distributed architectures have become an integral part of modern digital landscape. With the proliferation of cloud computing, big data, and highly available systems, traditional monolithic architectures have given way to more distributed, scalable, and resilient designs.
In this blog, we look at what makes an application distributed and how distributed applications work to bring about high availability, scalability, and resilience.
What is a distributed application?
A distributed application is a collection of computer programs spread across multiple computational nodes. Each node is a separate physical device or software process but works towards a shared objective. This setup is also known as distributed computing systems.
An application running on one single computer represents a single point of failure — if that computer fails, the application becomes unavailable. Distributed applications are often contrasted with monolithic applications.
A monolithic app can be harder to scale as the various components can’t be scaled independently. They can also become a drag on developer velocity as they grow because more developers need to work on a shared codebase that doesn’t necessarily have well-defined boundaries. This leads to slower updates and more delicate upgrades.
When splitting an application into different pieces and running them in many places, the overall system can tolerate more failures. It also allows an application to take advantage of scaling features not available to a single application instance, namely the ability to scale horizontally. This does, however, come at a cost: increased complexity and operational overhead — you’re now running lots of application components instead of one big application.
How do distributed apps work?
In distributed computing a single problem is divided up and each part is processed by a component. Distributed components running on all the machines in the computer network constitute the application.
For example, distributed computing can encrypt large volumes of data; solve physics and chemical equations with many variables; and render high-quality, three-dimensional video animation. Distributed systems, distributed programming, and distributed algorithms are some other terms that all refer to distributed computing.
Distributed computing works by computers passing messages to each other within the distributed systems architecture. Communication protocols or rules create a dependency between the components of the distributed system. This interdependence is called coupling, and there are two main types of coupling.
Loose coupling
In loose coupling, components are weakly connected so that changes to one component do not affect the other. For example, client and server computers can be loosely coupled by time. Messages from the client are added to a server queue, and the client can continue to perform other functions until the server responds to its message.
Tight coupling
High-performing distributed systems often use tight coupling. Fast local area networks typically connect several computers, which creates a cluster. In cluster computing, each computer is set to perform the same task. Central control systems, called clustering middleware, control and schedule the tasks and coordinate communication between the different computers.
Different types of distributed application models
Client-server architecture
This model considers the existence of a server with large computational capabilities. This server, in turn, is the entity responsible for receiving requests and providing services for several users. The functions are separated into two categories: clients and servers.
Clients have limited information and processing ability. Instead, they make requests to the servers, which manage most of the data and other resources.
Server computers synchronize and manage access to resources. They respond to client requests with data or status information.
This type of architecture facilitates remote access to data sources and business logic and enables a thin-client architecture and shared access to resources.
Example of a client-server architecture
Service-oriented architecture
SOA, or service-oriented architecture, defines a way to make software components reusable and interoperable through service interfaces. Services use common interface standards and an architectural pattern so they can be rapidly incorporated into new applications. The interface is a service contract between the service provider and the consumer.
Service interfaces are frequently defined by using web service definition language (WSDL) which is a standard tag structure based on XML (extensible markup language). The services are exposed by using standard network protocols—such as simple object access protocol (SOAP)/HTTP.
An ESB, or enterprise service bus, is an architectural pattern whereby a centralized software component performs integrations between applications. It performs transformations of data models, handles connectivity and messaging, performs routing, converts communication protocols, and potentially manages the composition of multiple requests. You’ll typically see an ESB implemented in a SOA architecture.
This type of architecture enables interoperability between heterogeneous environments and reusable components and facilitates the orchestration and composition of services. Astute readers may realize that the ESB itself can become a monolithic application.
Future-Proof API Management: Federated, agile & secure for what's next
Example of a service-oriented architecture
In the most basic terms, a distributed database is a database that stores data in multiple locations instead of one location. This means that rather than putting all data on one server or on one computer, data is placed on multiple servers or in a cluster of computers consisting of individual nodes. These nodes are often geographically separate and may be physical computers or virtual machines.
Each node stores a set of data and runs on distributed database management system software (DDBMS). To determine which data will be stored amongst which nodes, the concept of data distribution must be considered.
With this type of architecture data storage and management are distributed across networked servers. Sharding of the data enables horizontal scaling as data volume grows and since there is not a single point of failure, it’s fault tolerant.
Example of a distributed database
Cloud computing & SaaS
Software as a Service (SaaS) is a cloud-based software model that delivers applications to end-users through an internet browser. SaaS vendors host services and applications for customers to access on-demand. With a SaaS offering, you do not have to think about how the service is maintained or how the underlying infrastructure is managed; you only need to think about how you will use the software.
Today, SaaS is the most common public cloud computing service, and the dominant software delivery model. Much of the software that workforces use — from everyday tools like Slack (for messaging) and Dropbox (for file storage and sharing), to core business applications such as enterprise resource planning (ERP) and human resources/workforce optimization platforms — is delivered via the SaaS model.
Kong Konnect is an example of a SaaS-based API management platform offering both a hybrid solution as well as Dedicated Cloud Gateways, Developer Portal, Analytics, and a Service Hub.
Example of a SaaS offering
Cloud computing architecture offers on-demand compute, storage, and services as well as enabling easy scaling of distributed systems. Elasticity can be accomplished by leveraging cloud native application design.
SaaS takes advantage of cloud computing infrastructure and economies of scale to provide customers a more streamlined approach to adopting, using and paying for software.
Advantages and disadvantages of distributed applications
The advantages of using distributed applications are:
- Scalability — They’re horizontally scalable by adding additional compute to further distribute the workload or increase storage capacity or add processing power.
- Availability — They’re more tolerant to software failures or network partitions making them very resilient
- Transparency — Distributed applications provide logical separation between the user and physical devices making it seem like you’re interacting with a single computer
- Efficiency — You get faster performance with optimum resource utilization which makes managing intermittent spikes for workloads easier.
The disadvantages of using distributed applications are:
- Data integration and consistency — Maintaining consistency across multiple nodes becomes a formidable challenge in a distributed system. Ensuring all nodes have a shared view of the system’s state requires meticulous coordination. We won’t get into CAP theorem (Consistency, Availability and Partition Tolerance) in this blog, but here's a link if you’re interested in learning more about it.
- Network and communication failure — Distributed systems are prone to failures due to network partitions, hardware issues, or software bugs. Ensuring the system can gracefully handle these failures without compromising the user experience is a persistent challenge.
- Management overhead — More intelligence, monitoring, logging, load balancing functions need to be added for visibility into the operation and failures of the distributed systems.
Modernizing distributed app development
We hear the term “application modernization” a lot lately but what does it really mean?
Application modernization is the process of updating, upgrading, or transforming existing software applications to improve their functionality, performance, security, and user experience.
For the vast majority of companies that were not “born” digital — and therefore not primed to take advantage of all the latest cloud technologies—there’s little choice about whether to modernize or not. Remaining stuck in the past in your infrastructure, technology, applications, and approach to software development means ceding the race to more agile, responsive, and innovative competitors. Large legacy businesses today must evolve quickly to remain competitive and relevant.
There are many strategies for application modernization that depend on an organization’s goals. Many of them focus just on rehosting or a “lift-and-shift” to reduce code changes or replatforming, which is somewhere between rehosting and refactoring.
Before we dig into the ways to go about modernizing applications, let’s not forget that there is also a cultural change or mindset change in how application development is done. Teams need to be aligned to be more collaborative and use tools and processes that speed up the build and delivery process without sacrificing quality. Much of this aligns with the increasingly popular API-first model.
Key technologies and patterns for application modernization
The most common pattern of application modernization involves refactoring and breaking down a monolithic application into a collection of small, loosely coupled microservices. This process can seem daunting. However, there are ways to go about doing this methodically.
One approach is to use a “strangler pattern” instead of breaking down the monolithic application all at once. This pattern is about taking the application apart bit by bit, pulling out the easiest, most valuable parts first until there is nothing left of the monolith.
Often part of the refactoring to microservices is replatforming or rehosting applications. While it’s possible to simply lift-and-shift applications to reduce the amount of coding, more often, the value is found in restructuring the application to be more cloud native (taking advantage of cloud models including containers and Kubernetes).
Another approach to modernization can involve leaving applications in place and securely exposing their functions or data via APIs. This approach relies more heavily on integration than migration and enables new cloud native application development to take advantage of the capabilities of existing systems and data.
Conclusion
In this blog, we defined what a distributed system is, why you’d use one, and briefly described several types of distributed applications. We then covered the advantages and disadvantages of distributed systems, and lastly how to leverage distributed architecture in application modernization.
In my next blog, we’ll look at how we can overcome distributed application challenges by adopting an API management business model and service mesh tools.