diff --git a/content/en/function-as-a-service.md b/content/en/function-as-a-service.md
index 55cca70..6155011 100644
--- a/content/en/function-as-a-service.md
    b/content/en/function-as-a-service.md
@@ -5,30  5,24 @@ category: Technology
 tags: ["infrastructure", "", ""]
 ---
 
-Function as a Service (FaaS) is a type of [serverless](/serverless/) [cloud computing](/cloud-computing/) [service](/service/) 
-that allows executing code in response to events 
-without maintaining the complex infrastructure 
-typically associated with building and launching [microservices](/microservices/) applications. 
-With FaaS, users manage only functions and data while the cloud provider manages the application. 
-This allows developers to get the functions they need without paying for services when code isn’t running.  
 Function as a Service (FaaS) is a cloud computing model that provides a platform for executing event-triggered functions, allowing for automatic scaling without manual intervention.
 At its essence, FaaS enables the deployment of individual functions that are activated by specific events, operate on a short-term basis, and then shut down, ensuring resources are not wasted.
 This model supports an [autoscaling](/auto-scaling/) feature, enabling a function instance to be initiated per request and terminated post-execution, emphasizing its stateless nature.
 Consequently, FaaS platforms can implement a true pay-as-you-go billing approach, eliminating costs when functions are dormant, distinguishing it from other models like [Platform as a Service (PaaS)](/platform-as-a-service/), which require continuous resource availability.
 
 ## Problem it addresses
 
-In a traditional on-premises scenario, a business manages and maintains its own data center. 
-The business must invest in servers, storage, software, and other technologies 
-and potentially hire an IT staff or contractors to purchase, manage, and upgrade all the equipment and licenses. 
-The data center has to be built to meet peak demand, even when workloads decline and those resources stand idle. 
-Conversely, if the business grows quickly, the IT department might struggle to keep up. 
-Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) cloud computing model, 
-users pre-purchase capacity units, meaning you pay a public cloud provider for always-on server components to run your apps. 
-It’s the user’s responsibility to scale up server capacity during times of high demand 
-and scale down when that capacity is no longer needed. 
-The cloud infrastructure necessary to run an app is active even when the app isn’t being used.
 Traditionally, businesses have relied on maintaining on-premises data centers, necessitating substantial investment in hardware, software, and personnel.
 This setup demands resources to be scaled to peak demand, resulting in underutilized assets during downtime.
 Moreover, rapid business growth can overwhelm IT capabilities, leading to operational inefficiencies.
 In contrast, [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) models, while offering cloud-based solutions, still place the onus of scaling resources on the user, requiring payment for continuous server availability irrespective of actual usage.
 
 ## How it helps
 
-FaaS gives developers an [abstraction](/abstraction/) for running web applications in response to events without managing servers. 
-For example, uploading a file could trigger custom code that transcodes the file into various formats. 
-FaaS infrastructure will auto-scale the code for heavy use, 
-and the developer does not have to spend any time or resources building the code for [scalability](/scalability/). 
-Billing is based on computation time alone, which means businesses do not have to pay when the functions are not in use.
 FaaS gives developers an [abstraction](/abstraction/) for running web applications in response to events, eliminating the need to manage server infrastructure.
 For example, an action such as uploading a file could trigger custom code that transcodes the file into various formats.
 The FaaS infrastructure automatically adjusts resources to match demand, freeing developers from the complexities of coding for [scalability](/scalability/).
 Charges apply solely for the duration of computation, ensuring no costs accrue when functions are inactive.
 	
 For more information, refer to the [Serverless](/serverless/) glossary entry.
 Although "serverless" and "FaaS" are often used as interchangeable terms, they embody distinct concepts.
\ No newline at end of file

diff --git a/content/en/container-orchestration.md b/content/en/container-orchestration.md
index 504cdec..124d2dc 100644
--- a/content/en/container-orchestration.md
    b/content/en/container-orchestration.md
@@ -4,19  4,19 @@ status: Completed
 category: Concept
 ---
 
-[Container](/container/) orchestration refers to managing and automating the lifecycle of containerized applications in dynamic environments. 
-It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes)), which enables deployments, (auto)scaling, auto-healing, and monitoring. 
 [Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments.
 It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes/)), which enables deployments, (auto)scaling, auto-healing, and monitoring.
 Orchestration is a metaphor:
-The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should. 
 The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should.
 
-## Problem it addresses 
 ## Problem it addresses
 
-Managing [microservices](/microservices), security, and network communication at scale — and [distributed systems](/distributed-systems) in general — is hard, if not impossible, to manage manually.
-Container orchestration allows users to automate all these management tasks. 
 Managing [microservices](/microservices-architecture/), security, and network communication at scale — and [distributed systems](/distributed-systems/) in general — is hard, if not impossible, to manage manually.
 Container orchestration allows users to automate all these management tasks.
 
 ## How it helps
 
-Container orchestration tools allow users to determine a system's state. 
 Container orchestration tools allow users to determine a system's state.
 First, they declare how it should look like (e.g., x containers, y pods, etc.).
-The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes). 
 The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes).
 This automation simplifies many of the engineering teams' otherwise highly manual and complex operational tasks, including provisioning, deployment, scaling (up and down), networking, load balancing, and other activities.

diff --git a/content/en/serverless.md b/content/en/serverless.md
index c3fd084..17a824a 100644
--- a/content/en/serverless.md
    b/content/en/serverless.md
@@ -5,29  5,28 @@ Category: Technology
 tags: ["architecture", "", ""]
 ---
 
-Serverless is a cloud native development model that allows developers to 
-build and run applications without having to manage servers. 
-While servers do still exist within the serverless paradigm, they are [abstracted](/abstraction/) away from the application development process.
-A cloud provider handles the routine work of provisioning, maintaining, and [scaling](/scalability/) the server infrastructure. 
-Developers can conveniently package their code into [containers](/container/) for deployment.
-Once deployed, serverless apps respond to demand and automatically scale up and down as needed. 
-Serverless offerings from public cloud providers are usually metered on-demand through an event-driven execution model. 
-Consequently, when a serverless function is in an idle state, there are no associated costs.
 
 Serverless Computing [abstracts](/abstraction/) servers away from the user.
 Operational management falls to the service provider, including handling physical machines and VM provisioning.
 Service providers can be public cloud entities or internal IT departments serving their development teams.
 These providers offer user interfaces such as SDKs, CLIs, or OCI-compliant runtimes, focusing on code and deployment tasks.
 Charges are based on a pay-per-use model.
 [Scaling](/scalability/) and resource provisioning for computing, storage, or networking are automatically adjusted based on application demand without user intervention.
 A serverless platform provider consolidates resources to serve multiple users on a single physical machine, ensuring isolation through virtualization, especially with [VMs](/virtual-machine/).
 
 Serverless is a comprehensive term encompassing services with these attributes, extending from [Platform-as-a-Service (PaaS)](/platform-as-a-service/) to [Software-as-a-Service (SaaS)](/software-as-a-service/).
 
 ## Problem it addresses
 
-Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) [cloud computing](/cloud-computing/) model, 
-users pre-purchase units of capacity, meaning you pay a public cloud provider for always-on server components to run your apps. 
-It’s the user’s responsibility to scale up server capacity during times of high demand and 
-to scale down when that capacity is no longer needed. 
-The cloud infrastructure required to operate an application remains active even when the application is not in use.
 In traditional [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) [cloud computing](/cloud-computing/) models, users commit to a predefined capacity, resulting in charges for continuous server availability regardless of actual use.
 Responsibility for adjusting server capacity to meet fluctuating demands falls on the user, maintaining active infrastructure even during idle periods.
 
 ## How it helps
 
-Contrasting with traditional approaches, the serverless architecture launches applications only when they are needed. 
-When an event triggers app code to run, the public cloud provider dynamically allocates resources for that code. 
-The user stops paying when the code finishes executing. 
-In addition to the cost and efficiency benefits, 
-serverless frees developers from routine and menial tasks associated with app scaling and server provisioning. 
-With serverless, routine tasks such as managing the operating system and file system, security patches, 
-load balancing, capacity management, scaling, logging, and monitoring are all offloaded to a cloud services provider.
 Serverless architecture introduces a more efficient approach, activating services solely upon demand.
 This model ensures dynamic resource allocation by a cloud provider, eliminating costs for unused services.
 Beyond financial and operational efficiencies, serverless technology relieves developers of the burdens of scaling applications and managing server infrastructure.
 Tasks such as operating system maintenance, security updates, load balancing, capacity planning, and monitoring are delegated to the cloud provider, streamlining the development process.
 
 Refer to the [Function-as-a-Service (FaaS)](/function-as-a-service/) glossary entry for more information.
 Although "serverless" and "FaaS" are often used as interchangeable terms, they embody distinct concepts.

diff --git a/content/en/loosely-coupled-architecture.md b/content/en/loosely-coupled-architecture.md
index 8244d14..0bccb3a 100644
--- a/content/en/loosely-coupled-architecture.md
    b/content/en/loosely-coupled-architecture.md
@@ -5,15  5,15 @@ category: Property
 tags: ["fundamental", "architecture", "property"]
 ---
 
-Loosely coupled architecture is an architectural style 
-where the individual components of an application are built independently from one another 
-(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architectures/)). 
-Each component, sometimes referred to as a [microservice](/microservices/), is built to perform a specific function 
-in a way that can be used by any number of other services. 
-This pattern is generally slower to implement than tightly coupled architecture 
 Loosely coupled architecture is an architectural style
 where the individual components of an application are built independently from one another
 (the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architecture/)).
 Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function
 in a way that can be used by any number of other services.
 This pattern is generally slower to implement than tightly coupled architecture
 but has a number of benefits, particularly as applications scale.
 
-Loosely coupled applications allow teams to develop features, deploy, and scale independently, 
-which allows organizations to iterate quickly on individual components. 
-Application development is faster and teams can be structured around their competency, 
-focusing on their specific application. 
 Loosely coupled applications allow teams to develop features, deploy, and scale independently,
 which allows organizations to iterate quickly on individual components.
 Application development is faster and teams can be structured around their competency,
 focusing on their specific application.

diff --git a/content/en/continuous-delivery.md b/content/en/continuous-delivery.md
index 9cec1a2..ca9afe0 100644
--- a/content/en/continuous-delivery.md
    b/content/en/continuous-delivery.md
@@ -10,8  10,9 @@ in which code changes are automatically deployed into an acceptance environment
 (or, in the case of continuous deployment, into production). 
 CD crucially includes procedures to ensure that software is adequately tested 
 before deployment and provides a way to rollback changes if deemed necessary. 
-Continuous integration (CI) is the first step towards continuous delivery 
-(i.e., changes have to merge cleanly before being tested and deployed).
 [Continuous integration](/continuous-integration/) (CI) is the first step towards 
 continuous delivery (i.e., changes have to merge cleanly before being tested and 
 deployed).
 
 ## Problem it addresses
 
@@ -26,7  27,7 @@ deploying more changes at once and increasing the risk that something goes wrong
 CD strategies create a fully automated path to production 
 that tests and deploys the software using various deployment strategies 
 such as [canary](/canary-deployment/) or [blue-green](/blue-green-deployment/) releases. 
-This allows developers to deploy code frequently,  giving them peace of mind that the new revision has been tested. 
 This allows developers to deploy code frequently, giving them peace of mind that the new revision has been tested. 
 
 ## Related terms
 

diff --git a/content/en/cloud-computing.md b/content/en/cloud-computing.md
index e8152f9..f92f709 100644
--- a/content/en/cloud-computing.md
    b/content/en/cloud-computing.md
@@ -5,17  5,21 @@ category: concept
 tags: ["infrastructure", "fundamental", ""]
 ---
 
-Cloud computing offers compute resources like CPU, network, and disk capabilities on-demand over the internet, allowing users to access and use computing power in a remote physical location. 
-We generally differentiate between private and public cloud, depending on whether the cloud infrastructure is exclusively dedicated to an organization or shared for open public services.
 Cloud computing offers CPU power, storage, and network capabilities over the internet, 
 enabling scalable and flexible access to resources across global data centers. 
 It spans private clouds, dedicated to single organizations for security and control, 
 and public clouds, open for widespread use, optimizing cost and scalability.
 
 ## Problem it addresses
 
-Organizations traditionally faced two main challenges when attempting to expand computing power. 
-They could either acquire, support, and design (new) facilities to host their physical servers and network or expand and maintain existing ones. 
-Cloud computing solves that challenge by allowing organizations to outsource some of their computing needs. 
 Traditionally, organizations needing more computing capacity had to choose between costly investments in new server facilities or upgrades to existing infrastructure, a slow and resource-heavy process.
 
 ## How it helps
 
-Cloud providers allow organizations to rent compute resources on-demand and pay for usage, delivering two key benefits.
-First, organizations can focus on their product or service without waiting, planning, and spending resources on new physical infrastructure. And second, they can simply [scale](/scalability/) on-demand as needed.
-Cloud computing allows organizations to adopt as much or as little infrastructure as they need.
 Organizations can use cloud computing to rent computing resources on demand without the burden of managing physical infrastructure. 
 This strategy has two main advantages:
 - It removes the delays and expenses of establishing new infrastructure so organizations can concentrate on their core business.
 - Organizations can [scale](https://github.com/ronitblenz/glossary/blob/cloud_computing/content/en/scalability.md) their resources up or down based on demand, aligning infrastructure with business needs.
 Thus, cloud computing provides an efficient way for organizations to access necessary infrastructure flexibly and economically without excess commitment.
 
 ---

diff --git a/content/en/microservices-architecture.md b/content/en/microservices-architecture.md
index 9badc03..81c11b5 100644
--- a/content/en/microservices-architecture.md
    b/content/en/microservices-architecture.md
@@ -5,31  5,31 @@ tags: ["architecture", "fundamental", ""]
 ---
 
 A microservices architecture is an architectural approach that breaks applications into individual independent (micro)[services](/service/), with each service focused on a specific functionality.
-These services work together closely, appearing to the end user as a single entity. 
-Take Netflix as an example. 
-Its interface allows you to access, search, and preview videos. 
 These services work together closely, appearing to the end user as a single entity.
 Take Netflix as an example.
 Its interface allows you to access, search, and preview videos.
 These capabilities are likely powered by smaller services that each handle one functionality, e.g., authentication, search, and running previews in your browser.
 
 This architectural approach allows developers to push out new features or update functionality much faster than if they were all tightly coupled, such as in a [monolithic application](/monolithic-apps/) (more to that below).
 
 ## Problem it addresses
 
-Applications are made up of different parts, each responsible for a specific capability. 
-Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts. 
-Going back to our Netflix example. 
-Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day.  
-The surge in signups demands more signup capacity. 
-Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources. 
 Applications are made up of different parts, each responsible for a specific capability.
 Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts.
 Going back to our Netflix example.
 Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day.
 The surge in signups demands more signup capacity.
 Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources.
 
-Monolithic architectures also make it easy for developers to succumb to design pitfalls. 
-Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architectures/) and harder to enforce the principle of separation of concerns. 
-Monoliths also often require developers to understand the entire codebase before deploying any changes. 
-Microservices architecture is a response to these challenges.  
 Monolithic architectures also make it easy for developers to succumb to design pitfalls.
 Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architecture/) and harder to enforce the principle of separation of concerns.
 Monoliths also often require developers to understand the entire codebase before deploying any changes.
 Microservices architecture is a response to these challenges.
 
 
 ## How it helps
 
-Separating functionality into different microservices makes them easier to deploy, update, and scale independently. 
-It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app. 
-While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude. 
 Separating functionality into different microservices makes them easier to deploy, update, and scale independently.
 It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app.
 While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude.
 Many [cloud-native technologies](/cloud-native-tech/) aim to make microservices easier to deploy and manage.

diff --git a/content/en/stateful-apps.md b/content/en/stateful-apps.md
index a86399c..4412df8 100644
--- a/content/en/stateful-apps.md
    b/content/en/stateful-apps.md
@@ -5,12  5,12 @@ category: Property
 tags: ["fundamental", "application", "property"]
 ---
 
-When we speak of stateful (and [stateless](/stateless-apps/)) apps, 
-state refers to any data the app needs to store to function as designed. 
-Any kind of online shop that remembers your cart is a stateful app for example. 
 When we speak of stateful (and [stateless](/stateless-apps/)) apps,
 state refers to any data the app needs to store to function as designed.
 Any kind of online shop that remembers your cart is a stateful app for example.
 
-Today, most applications we use are at least partly stateful. In cloud native environments though, 
-stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps) are very dynamic. 
 Today, most applications we use are at least partly stateful. In cloud native environments though,
 stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps/) are very dynamic.
 They can be scaled up and down, restarted, and moved around but still need to be able to access their state.
 
 Therefore, stateful apps needs some kind of storage that is accessible from anywhere, like databases.