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.
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.
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.
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.
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.
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
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.
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
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.
The advantages of using distributed applications are:
The disadvantages of using distributed applications are:
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.
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.
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.
Meet Emily. She’s an API product manager at ACME, Inc., an ecommerce company that runs on dozens of APIs. One morning, her team lead asks a simple question: “Who’s our top API consumer, and which of your APIs are causing the most issues right now?”
In the last two parts of this series, we discussed How to Strengthen a ReAct AI Agent with Kong AI Gateway and How to Build a Single-LLM AI Agent with Kong AI Gateway and LangGraph . In this third and final part, we're going to evolve the AI Agen
In my previous post, we discussed how we can implement a basic AI Agent with Kong AI Gateway. In part two of this series, we're going to review LangGraph fundamentals, rewrite the AI Agent and explore how Kong AI Gateway can be used to protect an LLM
This is part one of a series exploring how Kong AI Gateway can be used in an AI Agent development with LangGraph. The series comprises three parts: Basic ReAct AI Agent with Kong AI Gateway Single LLM ReAct AI Agent with Kong AI Gateway and LangGr
What Is RAG, and Why Should You Use It? RAG (Retrieval-Augmented Generation) is not a new concept in AI, and unsurprisingly, when talking to companies, everyone seems to have their own interpretation of how to implement it. So, let’s start with a r
In February 2024, Kong became the first API platform to launch a dedicated AI gateway, designed to bring production-grade performance, observability, and policy enforcement to GenAI workloads. At its core, Kong’s AI Gateway provides a universal API
In this article, which is based on my talk at VueConf Toronto 2023, we'll explore how to harness the power of Vue.js and micro frontends to create scalable, modular architectures that prioritize the developer experience. We'll unveil practical strate