Microservices on Producthunt daily

istio

Thu, 25 Sep 2025 15:28:48 +0800

istio/istio

Istio

Istio is an open source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio is the path to load balancing, service-to-service authentication, and monitoring – with few or no service code changes.

For in-depth information about how to use Istio, visit istio.io
To ask questions and get assistance from our community, visit Github Discussions
To learn how to participate in our overall community, visit our community page

In this README:

In addition, here are some other documents you may wish to read:

Istio Community - describes how to get involved and contribute to the Istio project
Istio Developer’s Guide - explains how to set up and use an Istio development environment
Project Conventions - describes the conventions we use within the code base
Creating Fast and Lean Code - performance-oriented advice and guidelines for the code base

You’ll find many other useful documents on our Wiki.

Introduction

Istio is an open platform for providing a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies and aggregate telemetry data. Istio’s control plane provides an abstraction layer over the underlying cluster management platform, such as Kubernetes.

Istio is composed of these components:

Envoy - Sidecar proxies per microservice to handle ingress/egress traffic between services in the cluster and from a service to external services. The proxies form a secure microservice mesh providing a rich set of functions like discovery, rich layer-7 routing, circuit breakers, policy enforcement and telemetry recording/reporting functions.

Note: The service mesh is not an overlay network. It simplifies and enhances how microservices in an application talk to each other over the network provided by the underlying platform.
Istiod - The Istio control plane. It provides service discovery, configuration and certificate management. It consists of the following sub-components:
- Pilot - Responsible for configuring the proxies at runtime.
- Citadel - Responsible for certificate issuance and rotation.
- Galley - Responsible for validating, ingesting, aggregating, transforming and distributing config within Istio.
Operator - The component provides user friendly options to operate the Istio service mesh.

Repositories

The Istio project is divided across a few GitHub repositories:

istio/api. This repository defines component-level APIs and common configuration formats for the Istio platform.
istio/community. This repository contains information on the Istio community, including the various documents that govern the Istio open source project.
istio/istio. This is the main code repository. It hosts Istio’s core components, install artifacts, and sample programs. It includes:
- istioctl. This directory contains code for the istioctl command line utility.
- pilot. This directory contains platform-specific code to populate the abstract service model, dynamically reconfigure the proxies when the application topology changes, as well as translate routing rules into proxy specific configuration.
- security. This directory contains security related code, including Citadel (acting as Certificate Authority), citadel agent, etc.
istio/proxy. The Istio proxy contains extensions to the Envoy proxy (in the form of Envoy filters) that support authentication, authorization, and telemetry collection.
istio/ztunnel. The repository contains the Rust implementation of the ztunnel component of Ambient mesh.
istio/client-go. This repository defines auto-generated Kubernetes clients for interacting with Istio resources programmatically.

[!NOTE] Only the istio/api and istio/client-go repositories expose stable interfaces intended for direct usage as libraries.

Issue management

We use GitHub to track all of our bugs and feature requests. Each issue we track has a variety of metadata:

Epic. An epic represents a feature area for Istio as a whole. Epics are fairly broad in scope and are basically product-level things. Each issue is ultimately part of an epic.
Milestone. Each issue is assigned a milestone. This is 0.1, 0.2, …, or ‘Nebulous Future’. The milestone indicates when we think the issue should get addressed.
Priority. Each issue has a priority which is represented by the column in the Prioritization project. Priority can be one of P0, P1, P2, or >P2. The priority indicates how important it is to address the issue within the milestone. P0 says that the milestone cannot be considered achieved if the issue isn’t resolved.

Istio is a Cloud Native Computing Foundation project.

cognitive-load

Tue, 02 Sep 2025 15:29:59 +0800

zakirullin/cognitive-load

Cognitive Load is what matters

Readable version | Chinese | Korean | Turkish | Japanese

It is a living document, last update: September 2025. Your contributions are welcome!

Introduction

There are so many buzzwords and best practices out there, but most of them have failed. We need something more fundamental, something that can’t be wrong.

Sometimes we feel confusion going through the code. Confusion costs time and money. Confusion is caused by high cognitive load. It’s not some fancy abstract concept, but rather a fundamental human constraint. It’s not imagined, it’s there and we can feel it.

Since we spend far more time reading and understanding code than writing it, we should constantly ask ourselves whether we are embedding excessive cognitive load into our code.

Cognitive load

Cognitive load is how much a developer needs to think in order to complete a task.

When reading code, you put things like values of variables, control flow logic and call sequences into your head. The average person can hold roughly four such chunks in working memory. Once the cognitive load reaches this threshold, it becomes much harder to understand things.

Let’s say we have been asked to make some fixes to a completely unfamiliar project. We were told that a really smart developer had contributed to it. Lots of cool architectures, fancy libraries and trendy technologies were used. In other words, the author had created a high cognitive load for us.

We should reduce the cognitive load in our projects as much as possible.

Cognitive load and interruptions

We are going to use “cognitive load” in an informal sense; sometimes it lines up with the specific scientific concept of Cognitive Load, but we don’t know enough about where it does and doesn’t match.

Types of cognitive load

Intrinsic - caused by the inherent difficulty of a task. It can’t be reduced, it’s at the very heart of software development.

Extraneous - created by the way the information is presented. Caused by factors not directly relevant to the task, such as smart author’s quirks. Can be greatly reduced. We will focus on this type of cognitive load.

Let’s jump straight to the concrete practical examples of extraneous cognitive load.

We will refer to the level of cognitive load as follows:
🧠: fresh working memory, zero cognitive load
🧠++: two facts in our working memory, cognitive load increased
🤯: cognitive overload, more than 4 facts

Our brain is much more complex and unexplored, but we can go with this simplistic model.

Complex conditionals

if val > someConstant // 🧠+
    && (condition2 || condition3) // 🧠+++, prev cond should be true, one of c2 or c3 has be true
    && (condition4 && !condition5) { // 🤯, we are messed up by this point
    ...
}

Introduce intermediate variables with meaningful names:

isValid = val > someConstant
isAllowed = condition2 || condition3
isSecure = condition4 && !condition5 
// 🧠, we don't need to remember the conditions, there are descriptive variables
if isValid && isAllowed && isSecure {
    ...
}

Nested ifs

if isValid { // 🧠+, okay nested code applies to valid input only
    if isSecure { // 🧠++, we do stuff for valid and secure input only
        stuff // 🧠+++
    }
}

Compare it with the early returns:

if !isValid
    return
 
if !isSecure
    return

// 🧠, we don't really care about earlier returns, if we are here then all good

stuff // 🧠+

We can focus on the happy path only, thus freeing our working memory from all sorts of preconditions.

Inheritance nightmare

We are asked to change a few things for our admin users: 🧠

AdminController extends UserController extends GuestController extends BaseController

Ohh, part of the functionality is in BaseController, let’s have a look: 🧠+
Basic role mechanics got introduced in GuestController: 🧠++
Things got partially altered in UserController: 🧠+++
Finally we are here, AdminController, let’s code stuff! 🧠++++

Oh, wait, there’s SuperuserController which extends AdminController. By modifying AdminController we can break things in the inherited class, so let’s dive in SuperuserController first: 🤯

Prefer composition over inheritance. We won’t go into detail - there’s plenty of material out there.

Too many small methods, classes or modules

Method, class and module are interchangeable in this context

Mantras like “methods should be shorter than 15 lines of code” or “classes should be small” turned out to be somewhat wrong.

Deep module - simple interface, complex functionality
Shallow module - interface is relatively complex to the small functionality it provides

Having too many shallow modules can make it difficult to understand the project. Not only do we have to keep in mind each module responsibilities, but also all their interactions. To understand the purpose of a shallow module, we first need to look at the functionality of all the related modules. Jumping between such shallow components is mentally exhausting, linear thinking is more natural to us humans.

Information hiding is paramount, and we don’t hide as much complexity in shallow modules.

I have two pet projects, both of them are somewhat 5K lines of code. The first one has 80 shallow classes, whereas the second one has only 7 deep classes. I haven’t been maintaining any of these projects for one year and a half.

Once I came back, I realised that it was extremely difficult to untangle all the interactions between those 80 classes in the first project. I would have to rebuild an enormous amount of cognitive load before I could start coding. On the other hand, I was able to grasp the second project quickly, because it had only a few deep classes with a simple interface.

The best components are those that provide powerful functionality yet have a simple interface.
John K. Ousterhout

The interface of the UNIX I/O is very simple. It has only five basic calls:

open(path, flags, permissions)
read(fd, buffer, count)
write(fd, buffer, count)
lseek(fd, offset, referencePosition)
close(fd)

A modern implementation of this interface has hundreds of thousands of lines of code. Lots of complexity is hidden under the hood. Yet it is easy to use due to its simple interface.

This deep module example is taken from the book A Philosophy of Software Design by John K. Ousterhout. Not only does this book cover the very essence of complexity in software development, but it also has the greatest interpretation of Parnas’ influential paper On the Criteria To Be Used in Decomposing Systems into Modules. Both are essential reads. Other related readings: A Philosophy of Software Design vs Clean Code, It’s probably time to stop recommending Clean Code, Small Functions considered Harmful.

P.S. If you think we are rooting for bloated God objects with too many responsibilities, you got it wrong.

Responsible for one thing

All too often, we end up creating lots of shallow modules, following some vague “a module should be responsible for one, and only one, thing” principle. What is this blurry one thing? Instantiating an object is one thing, right? So MetricsProviderFactoryFactory seems to be just fine. The names and interfaces of such classes tend to be more mentally taxing than their entire implementations, what kind of abstraction is that? Something went wrong.

We make changes to our systems to satisfy our users and stakeholders. We are responsible to them.

A module should be responsible to one, and only one, user or stakeholder.

This is what this Single Responsibility Principle is all about. Simply put, if we introduce a bug in one place, and then two different business people come to complain, we’ve violated the principle. It has nothing to do with the number of things we do in our module.

But even now, this rule can do more harm than good. This principle can be understood in as many different ways as there are individuals. A better approach would be to look at how much cognitive load it all creates. It’s mentally demanding to remember that change in one place can trigger a chain of reactions across different business streams. And that’s about it, no fancy terms to learn.

Too many shallow microservices

This shallow-deep module principle is scale-agnostic, and we can apply it to microservices architecture. Too many shallow microservices won’t do any good - the industry is heading towards somewhat “macroservices”, i.e., services that are not so shallow (=deep). One of the worst and hardest to fix phenomena is so-called distributed monolith, which is often the result of this overly granular shallow separation.

I once consulted a startup where a team of five developers introduced 17(!) microservices. They were 10 months behind schedule and appeared nowhere close to the public release. Every new requirement led to changes in 4+ microservices. It took an enormous amount of time to reproduce and debug an issue in such a distributed system. Both time to market and cognitive load were unacceptably high. 🤯

Is this the right way to approach the uncertainty of a new system? It’s enormously difficult to elicit the right logical boundaries in the beginning. The key is to make decisions as late as you can responsibly wait, because that is when you have the most information at hand. By introducing a network layer up front, we make our design decisions hard to revert right from the start. The team’s only justification was: “The FAANG companies proved microservices architecture to be effective”. Hello, you got to stop dreaming big.

The Tanenbaum-Torvalds debate argued that Linux’s monolithic design was flawed and obsolete, and that a microkernel architecture should be used instead. Indeed, the microkernel design seemed to be superior “from a theoretical and aesthetical” point of view. On the practical side of things - three decades on, microkernel-based GNU Hurd is still in development, and monolithic Linux is everywhere. This page is powered by Linux, your smart teapot is powered by Linux. By monolithic Linux.

A well-crafted monolith with truly isolated modules is often much more flexible than a bunch of microservices. It also requires far less cognitive effort to maintain. It’s only when the need for separate deployments becomes crucial, such as scaling the development team, that you should consider adding a network layer between the modules, future microservices.

Feature-rich languages

We feel excited when new features got released in our favourite language. We spend some time learning these features, we build code upon them.

If there are lots of features, we may spend half an hour playing with a few lines of code, to use one or another feature. And it’s kind of a waste of time. But what’s worse, when you come back later, you would have to recreate that thought process!

You not only have to understand this complicated program, you have to understand why a programmer decided this was the way to approach a problem from the features that are available. 🤯

These statements are made by none other than Rob Pike.

Reduce cognitive load by limiting the number of choices.

Language features are OK, as long as they are orthogonal to each other.

Thoughts from an engineer with 20 years of C++ experience ⭐️

I was looking at my RSS reader the other day and noticed that I have somewhat three hundred unread articles under the "C++" tag. I haven't read a single article about the language since last summer, and I feel great!

I've been using C++ for 20 years for now, that's almost two-thirds of my life. Most of my experience lies in dealing with the darkest corners of the language (such as undefined behaviours of all sorts). It's not a reusable experience, and it's kind of creepy to throw it all away now.

Like, can you imagine, the token || has a different meaning in requires ((!P<T> || !Q<T>)) and in requires (!(P<T> || Q<T>)). The first is the constraint disjunction, the second is the good-old logical OR operator, and they behave differently.

You can't allocate space for a trivial type and just memcpy a set of bytes there without extra effort - that won't start the lifetime of an object. This was the case before C++20. It was fixed in C++20, but the cognitive load of the language has only increased.

Cognitive load is constantly growing, even though things got fixed. I should know what was fixed, when it was fixed, and what it was like before. I am a professional after all. Sure, C++ is good at legacy support, which also means that you will face that legacy. For example, last month a colleague of mine asked me about some behaviour in C++03. 🤯

There were 20 ways of initialization. Uniform initialization syntax has been added. Now we have 21 ways of initialization. By the way, does anyone remember the rules for selecting constructors from the initializer list? Something about implicit conversion with the least loss of information, but if the value is known statically, then... 🤯

This increased cognitive load is not caused by a business task at hand. It is not an intrinsic complexity of the domain. It is just there due to historical reasons (extraneous cognitive load).

I had to come up with some rules. Like, if that line of code is not as obvious and I have to remember the standard, I better not write it that way. The standard is somewhat 1500 pages long, by the way.

By no means I am trying to blame C++. I love the language. It's just that I am tired now.

Thanks to 0xd34df00d for writing.

Business logic and HTTP status codes

On the backend we return:
401 for expired jwt token
403 for not enough access
418 for banned users

The engineers on the frontend use backend API to implement login functionality. They would have to temporarily create the following cognitive load in their brains:
401 is for expired jwt token // 🧠+, ok just temporary remember it
403 is for not enough access // 🧠++
418 is for banned users // 🧠+++

Frontend developers would (hopefully) introduce some kind numeric status -> meaning dictionary on their side, so that subsequent generations of contributors wouldn’t have to recreate this mapping in their brains.

Then QA engineers come into play: “Hey, I got 403 status, is that expired token or not enough access?” QA engineers can’t jump straight to testing, because first they have to recreate the cognitive load that the engineers on the backend once created.

Why hold this custom mapping in our working memory? It’s better to abstract away your business details from the HTTP transfer protocol, and return self-descriptive codes directly in the response body:

1
2
3

{
    "code": "jwt_has_expired"
}

Cognitive load on the frontend side: 🧠 (fresh, no facts are held in mind)
Cognitive load on the QA side: 🧠

The same rule applies to all sorts of numeric statuses (in the database or wherever) - prefer self-describing strings. We are not in the era of 640K computers to optimise for memory.

People spend time arguing between 401 and 403, making decisions based on their own mental models. New developers are coming in, and they need to recreate that thought process. You may have documented the “whys” (ADRs) for your code, helping newcomers to understand the decisions made. But in the end it just doesn’t make any sense. We can separate errors into either user-related or server-related, but apart from that, things are kind of blurry.

P.S. It’s often mentally taxing to distinguish between “authentication” and “authorization”. We can use simpler terms like “login” and “permissions” to reduce the cognitive load.

Abusing DRY principle

Do not repeat yourself - that is one of the first principles you are taught as a software engineer. It is so deeply embedded in ourselves that we can not stand the fact of a few extra lines of code. Although in general a good and fundamental rule, when overused it leads to the cognitive load we can not handle.

Nowadays, everyone builds software based on logically separated components. Often those are distributed among multiple codebases representing separate services. When you strive to eliminate any repetition, you might end up creating tight coupling between unrelated components. As a result changes in one part may have unintended consequences in other seemingly unrelated areas. It can also hinder the ability to replace or modify individual components without impacting the entire system. 🤯

In fact, the same problem arises even within a single module. You might extract common functionality too early, based on perceived similarities that might not actually exist in the long run. This can result in unnecessary abstractions that are difficult to modify or extend.

Rob Pike once said:

A little copying is better than a little dependency.

We are tempted to not reinvent the wheel so strong that we are ready to import large, heavy libraries to use a small function that we could easily write by ourselves.

All your dependencies are your code. Going through 10+ levels of stack trace of some imported library and figuring out what went wrong (because things go wrong) is painful.

Tight coupling with a framework

There’s a lot of “magic” in frameworks. By relying too heavily on a framework, we force all upcoming developers to learn that “magic” first. It can take months. Even though frameworks enable us to launch MVPs in a matter of days, in the long run they tend to add unnecessary complexity and cognitive load.

Worse yet, at some point frameworks can become a significant constraint when faced with a new requirement that just doesn’t fit the architecture. From here onwards people end up forking a framework and maintaining their own custom version. Imagine the amount of cognitive load a newcomer would have to build (i.e. learn this custom framework) in order to deliver any value. 🤯

By no means do we advocate to invent everything from scratch!

We can write code in a somewhat framework-agnostic way. The business logic should not reside within a framework; rather, it should use the framework’s components. Put a framework outside of your core logic. Use the framework in a library-like fashion. This would allow new contributors to add value from day one, without the need of going through debris of framework-related complexity first.

Why I Hate Frameworks

Layered architecture

There is a certain engineering excitement about all this stuff.

I myself was a passionate advocate of Hexagonal/Onion Architecture for years. I used it here and there and encouraged other teams to do so. The complexity of our projects went up, the sheer number of files alone had doubled. It felt like we were writing a lot of glue code. On ever changing requirements we had to make changes across multiple layers of abstractions, it all became tedious. 🤯

Abstraction is supposed to hide complexity, here it just adds indirection. Jumping from call to call to read along and figure out what goes wrong and what is missing is a vital requirement to quickly solve a problem. With this architecture’s layer uncoupling it requires an exponential factor of extra, often disjointed, traces to get to the point where the failure occurs. Every such trace takes space in our limited working memory. 🤯

This architecture was something that made intuitive sense at first, but every time we tried applying it to projects it made a lot more harm than good. In the end, we gave it all up in favour of the good old dependency inversion principle. No port/adapter terms to learn, no unnecessary layers of horizontal abstractions, no extraneous cognitive load.

Coding principles and experience

@flaviocopes

If you think that such layering will allow you to quickly replace a database or other dependencies, you’re mistaken. Changing the storage causes lots of problems, and believe us, having some abstractions for the data access layer is the least of your worries. At best, abstractions can save somewhat 10% of your migration time (if any), the real pain is in data model incompatibilities, communication protocols, distributed systems challenges, and implicit interfaces.

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

We did a storage migration, and that took us about 10 months. The old system was single-threaded, so the exposed events were sequential. All our systems depended on that observed behaviour. This behavior was not part of the API contract, it was not reflected in the code. A new distributed storage didn’t have that guarantee - the events came out-of-order. We spent only a few hours coding a new storage adapter, thanks to an abstraction. We spent the next 10 months on dealing with out-of-order events and other challenges. It’s now funny to say that abstractions helps us replace components quickly.

So, why pay the price of high cognitive load for such a layered architecture, if it doesn’t pay off in the future? Plus, in most cases, that future of replacing some core component never happens.

These architectures are not fundamental, they are just subjective, biased consequences of more fundamental principles. Why rely on those subjective interpretations? Follow the fundamental rules instead: dependency inversion principle, single source of truth, cognitive load and information hiding. Your business logic should not depend on low-level modules like database, UI or framework. We should be able to write tests for our core logic without worrying about the infrastructure, and that’s it. Discuss.

Do not add layers of abstractions for the sake of an architecture. Add them whenever you need an extension point that is justified for practical reasons.

Layers of abstraction aren’t free of charge, they are to be held in our limited working memory.

Domain-driven design

Domain-driven design has some great points, although it is often misinterpreted. People say, “We write code in DDD”, which is a bit strange, because DDD is more about the problem space rather than the solution space.

Ubiquitous language, domain, bounded context, aggregate, event storming are all about problem space. They are meant to help us learn the insights about the domain and extract the boundaries. DDD enables developers, domain experts and business people to communicate effectively using a single, unified language. Rather than focusing on these problem space aspects of DDD, we tend to emphasise particular folder structures, services, repositories, and other solution space techniques.

Chances are that the way we interpret DDD is likely to be unique and subjective. And if we build code upon this understanding, i.e., if we create a lot of extraneous cognitive load - future developers are doomed. 🤯

Team Topologies provides a much better, easier to understand framework that helps us split the cognitive load across teams. Engineers tend to develop somewhat similar mental models after learning about Team Topologies. DDD, on the other hand, seems to be creating 10 different mental models for 10 different readers. Instead of being common ground, it becomes a battleground for unnecessary debates.

Cognitive load in familiar projects

The problem is that familiarity is not the same as simplicity. They feel the same — that same ease of moving through a space without much mental effort — but for very different reasons. Every “clever” (read: “self-indulgent”) and non-idiomatic trick you use incurs a learning penalty for everyone else. Once they have done that learning, then they will find working with the code less difficult. So it is hard to recognise how to simplify code that you are already familiar with. This is why I try to get “the new kid” to critique the code before they get too institutionalised!

It is likely that the previous author(s) created this huge mess one tiny increment at a time, not all at once. So you are the first person who has ever had to try to make sense of it all at once.

In my class I describe a sprawling SQL stored procedure we were looking at one day, with hundreds of lines of conditionals in a huge WHERE clause. Someone asked how anyone could have let it get this bad. I told them: “When there are only 2 or 3 conditionals, adding another one doesn’t make any difference. By the time there are 20 or 30 conditionals, adding another one doesn’t make any difference!”

There is no “simplifying force” acting on the code base other than deliberate choices that you make. Simplifying takes effort, and people are too often in a hurry.

Thanks to Dan North for his comment.

If you’ve internalized the mental models of the project into your long-term memory, you won’t experience a high cognitive load.

The more mental models there are to learn, the longer it takes for a new developer to deliver value.

Once you onboard new people on your project, try to measure the amount of confusion they have (pair programming may help). If they’re confused for more than ~40 minutes in a row - you’ve got things to improve in your code.

If you keep the cognitive load low, people can contribute to your codebase within the first few hours of joining your company.

Examples

Our architecture is a standard CRUD app architecture, a Python monolith on top of Postgres
How Instagram scaled to 14 million users with only 3 engineers
The companies where we were like ”woah, these folks are smart as hell” for the most part failed
One function that wires up the entire system. If you want to know how the system works - go read it

These architectures are quite boring and easy to understand. Anyone can grasp them without much mental effort.

Involve junior developers in architecture reviews. They will help you to identify the mentally demanding areas.

Maintaining software is hard, things break and we would need every bit of mental effort we can save.

Conclusion

Imagine for a moment that what we inferred in the second chapter isn’t actually true. If that’s the case, then the conclusion we just negated, along with the conclusions in the previous chapter that we had accepted as valid, might not be correct either. 🤯

Do you feel it? Not only do you have to jump all over the article to get the meaning (shallow modules!), but the paragraph in general is difficult to understand. We have just created an unnecessary cognitive load in your head. Do not do this to your colleagues.

We should reduce any cognitive load above and beyond what is intrinsic to the work we do.

LinkedIn, X, GitHub, artemzr(аt)g-yоu-knоw-com

Comments

Rob Pike
Nice article.

Andrej Karpathy (ChatGPT, Tesla)
Nice post on software engineering. Probably the most true, least practiced viewpoint.

Elon Musk
True.

Addy Osmani (Chrome, the most complex software system in the world)
I've seen countless projects where smart developers created impressive architectures using the latest design patterns and microservices. But when new team members tried to make changes, they spent weeks just trying to understand how everything fits together. The cognitive load was so high that productivity plummeted and bugs multiplied.

The irony? Many of these complexity-inducing patterns were implemented in the name of "clean code."

What really matters is reducing unnecessary cognitive burden. Sometimes this means fewer, deeper modules instead of many shallow ones. Sometimes it means keeping related logic together instead of splitting it into tiny functions.

And sometimes it means choosing boring, straightforward solutions over clever ones. The best code isn't the most elegant or sophisticated - it's the code that future developers (including yourself) can understand quickly.

Your article really resonates with the challenges we face in browser development. You're absolutely right about modern browsers being among the most complex software systems. Managing that complexity in Chromium is a constant challenge that aligns perfectly with many of the points you made about cognitive load.

One way we try to handle this in Chromium is through careful component isolation and well-defined interfaces between subsystems (like rendering, networking, JavaScript execution, etc.). Similar to your deep modules example with Unix I/O - we aim for powerful functionality behind relatively simple interfaces. For instance, our rendering pipeline handles incredible complexity (layout, compositing, GPU acceleration) but developers can interact with it through clear abstraction layers.

Your points about avoiding unnecessary abstractions really hit home too. In browser development, we constantly balance between making the codebase approachable for new contributors while handling the inherent complexity of web standards and compatibility.

Sometimes the simplest solution is the best one, even in a complex system.

antirez (Redis)
Totally agree about it :) Also, what I believe is missing from mentioned "A Philosophy of Software Design" is the concept of "design sacrifice". That is, sometimes you sacrifice something and get back simplicity, or performances, or both. I apply this idea continuously, but often is not understood.

A good example is the fact that I always refused to have hash items expires. This is a design sacrifice because if you have certain attributes only in the top-level items (the keys themselves), the design is simpler, values will just be objects. When Redis got hash expires, it was a nice feature but required (indeed) many changes to many parts, raising the complexity.

Another example is what I'm doing right now, Vector Sets, the new Redis data type. I decided that Redis would not be the source of truth about vectors, but that it can just take an approximate version of them, so I was able to do on-insert normalization, quantization without trying to retain the large floats vector on disk, and so forth. May vector DBs don't sacrifice the fact of remembering what the user put inside (the full precision vector).

These are just two random examples, but I apply this idea everywhere. Now the thing is: of course one must sacrifice the right things. Often, there are 5% features that account for a very large amount of complexity: that is a good thing to kill :D

A developer from the internet
You would not hire me... I sell myself on my track record of released enterprise projects.

I worked with a guy that could speak design patterns. I could never speak that way, though I was one of the few that could well understand him. The managers loved him and he could dominate any development conversation. The people working around him said he left a trail of destruction behind him. I was told that I was the first person that could understand his projects. Maintainability matters. I care most about TCO. For some firms, that's what matters.

I logged into Github after not being there for a while and for some reason it took me to an article in a repository by someone that seemed random. I was thinking "what is this" and had some trouble getting to my home page, so I read it. I didn't really register it at the time, but it was amazing. Every developer should read it. It largely said that almost everything we've been told about programming best practices leads to excessive "cognitive load", meaning our minds are getting kicked by the intellectual demands. I've known this for a while, especially with the demands of cloud, security and DevOps.

I also liked it because it described practices I have done for decades, but never much admit to because they are not popular... I write really complicated stuff and need all the help I can get.

Consider, if I'm right, it popped up because the Github folks, very smart people, though that developers should see it. I agree.

Comments on Hacker News (2)

nats-server

Sat, 30 Aug 2025 15:25:22 +0800

nats-io/nats-server

NATS is a simple, secure and performant communications system for digital systems, services and devices. NATS is part of the Cloud Native Computing Foundation (CNCF). NATS has over 40 client language implementations, and its server can run on-premise, in the cloud, at the edge, and even on a Raspberry Pi. NATS can secure and simplify design and operation of modern distributed systems.

Documentation

Official Website
Official Documentation
FAQ
Watch a video overview of NATS.
Watch this video from SCALE 13x to learn more about its origin story and design philosophy.

Contact

Twitter: Follow us on Twitter!
Google Groups: Where you can ask questions
Slack: Click here to join. You can ask questions to our maintainers and to the rich and active community.

Contributing

If you are interested in contributing to NATS, read about our…

Roadmap

The NATS product roadmap can be found here.

Adopters

Who uses NATS? See our list of users on https://nats.io.

Security

Security Audit

A third party security audit was performed by Trail of Bits following engagement by the Open Source Technology Improvement Fund (OSTIF). You can see the full report from April 2025 here.

Reporting Security Vulnerabilities

If you’ve found a vulnerability or a potential vulnerability in the NATS server, please let us know at nats-security.

License

Unless otherwise noted, the NATS source files are distributed under the Apache Version 2.0 license found in the LICENSE file.

awesome-scalability

Mon, 11 Aug 2025 15:35:27 +0800

binhnguyennus/awesome-scalability

An updated and organized reading list for illustrating the patterns of scalable, reliable, and performant large-scale systems. Concepts are explained in the articles of prominent engineers and credible references. Case studies are taken from battle-tested systems that serve millions to billions of users.

If your system goes slow

Understand your problems: scalability problem (fast for a single user but slow under heavy load) or performance problem (slow for a single user) by reviewing some design principles and checking how scalability and performance problems are solved at tech companies. The section of intelligence are created for those who work with data and machine learning at big (data) and deep (learning) scale.

If your system goes down

“Even if you lose all one day, you can build all over again if you retain your calm!” - Thuan Pham, former CTO of Uber. So, keep calm and mind the availability and stability matters!

If you are having a system design interview

Look at some interview notes and real-world architectures with completed diagrams to get a comprehensive view before designing your system on whiteboard. You can check some talks of engineers from tech giants to know how they build, scale, and optimize their systems. Good luck!

If you are building your dream team

The goal of scaling team is not growing team size but increasing team output and value. You can find out how tech companies reach that goal in various aspects: hiring, management, organization, culture, and communication in the organization section.

Community power

Contributions are greatly welcome! You may want to take a look at the contribution guidelines. If you see a link here that is no longer maintained or is not a good fit, please submit a pull request!

Many long hours of hard work have gone into this project. If you find it helpful, please share on Facebook, on Twitter, on Weibo, or on your chat groups! Knowledge is power, knowledge shared is power multiplied. Thank you!

Content

Principle

Scalability

Availability

Stability

Performance

Intelligence

Architecture

Interview

Organization

Talk

A Piece of Cake

Roses are red. Violets are blue. Binh likes sweet. Treat Binh a tiramisu? :cake:

backstage

Sat, 09 Aug 2025 15:29:14 +0800

backstage/backstage

Backstage

English | 한국어 | 中文版 | Français

What is Backstage?

Backstage is an open source framework for building developer portals. Powered by a centralized software catalog, Backstage restores order to your microservices and infrastructure and enables your product teams to ship high-quality code quickly without compromising autonomy.

Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end.

Out of the box, Backstage includes:

Backstage Software Catalog for managing all your software such as microservices, libraries, data pipelines, websites, and ML models
Backstage Software Templates for quickly spinning up new projects and standardizing your tooling with your organization’s best practices
Backstage TechDocs for making it easy to create, maintain, find, and use technical documentation, using a “docs like code” approach
Plus, a growing ecosystem of open source plugins that further expand Backstage’s customizability and functionality

Backstage was created by Spotify but is now hosted by the Cloud Native Computing Foundation (CNCF) as an Incubation level project. For more information, see the announcement.

Project roadmap

For information about the detailed project roadmap including delivered milestones, see the Roadmap.

Getting Started

To start using Backstage, see the Getting Started documentation.

Documentation

The documentation of Backstage includes:

Community

To engage with our community, you can use the following resources:

Discord chatroom - Get support or discuss the project
Contributing to Backstage - Start here if you want to contribute
RFCs - Help shape the technical direction
FAQ - Frequently Asked Questions
Code of Conduct - This is how we roll
Adopters - Companies already using Backstage
Blog - Announcements and updates
Newsletter - Subscribe to our email newsletter
Backstage Community Sessions - Join monthly meetups and explore Backstage community
Give us a star ⭐️ - If you are using Backstage or think it is an interesting project, we would love a star ❤️

Governance

See the GOVERNANCE.md document in the backstage/community repository.

License

Copyright 2020-2025 © The Backstage Authors. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page: https://www.linuxfoundation.org/trademark-usage

Licensed under the Apache License, Version 2.0: http://www.apache.org/licenses/LICENSE-2.0

Security

Please report sensitive security issues using Spotify’s bug-bounty program rather than GitHub.

For further details, see our complete security release process.

kubesphere

Sun, 03 Aug 2025 15:29:40 +0800

kubesphere/kubesphere

The container platform tailored for Kubernetes multi-cloud, datacenter, and edge management

What is KubeSphere

English | 中文

KubeSphere is a distributed operating system for cloud-native application management, using Kubernetes as its kernel. It provides a plug-and-play architecture, allowing third-party applications to be seamlessly integrated into its ecosystem. KubeSphere is also a multi-tenant container platform with full-stack automated IT operation and streamlined DevOps workflows. It provides developer-friendly wizard web UI, helping enterprises to build out a more robust and feature-rich platform, which includes most common functionalities needed for enterprise Kubernetes strategy, see Feature List for details.

The following screenshots give a close insight into KubeSphere. Please check What is KubeSphere for further information.

Workbench	Project Resources

CI/CD Pipeline	App Store

Demo environment

🎮 KubeSphere Lite provides you with free, stable, and out-of-the-box managed cluster service. After registration and login, you can easily create a K8s cluster with KubeSphere installed in only 5 seconds and experience feature-rich KubeSphere.

🖥 You can view the Demo Video to get started with KubeSphere.

Features

🧩 Extensible Architecture

Designed for flexibility, supporting plugin-based extensions and seamless integrations. Easily customize and expand functionalities to meet evolving needs. Learn more.

🕸 Provisioning Kubernetes Cluster

Support deploy Kubernetes on any infrastructure, support online and air-gapped installation. Learn more.

🔗 Kubernetes Multi-cluster Management

Provide a centralized control plane to manage multiple Kubernetes clusters, and support the ability to propagate an app to multiple K8s clusters across different cloud providers.

🤖 Kubernetes DevOps

Provide GitOps-based CD solutions and use Argo CD to provide the underlying support, collecting CD status information in real time. With the mainstream CI engine Jenkins integrated, DevOps has never been easier. Learn more.

🔎 Cloud Native Observability

Multi-dimensional monitoring, events and auditing logs are supported; multi-tenant log query and collection, alerting and notification are built-in. Learn more.

🌐 Service Mesh (Istio-based)

Provide fine-grained traffic management, observability and tracing for distributed microservice applications, provides visualization for traffic topology. Learn more.

💻 App Store

Provide an App Store for Helm-based applications, and offer application lifecycle management on Kubernetes platform. Learn more.

💡 Edge Computing Platform

KubeSphere integrates KubeEdge to enable users to deploy applications on the edge devices and view logs and monitoring metrics of them on the console. Learn more.

🗃 Support Multiple Storage and Networking Solutions

Support GlusterFS, CephRBD, NFS, LocalPV solutions, and provide CSI plugins to consume storage from multiple cloud providers.

Provide Load Balancer Implementation OpenELB for Kubernetes in bare-metal, edge, and virtualization.

Provides network policy and Pod IP pools management, support Calico, Flannel, Kube-OVN

🏢 Multi-Tenancy

Isolated workspaces with role-based access control ensure secure resource sharing across multiple tenants. Supports fine-grained permissions and quota management. Learn more.

🧠 GPU Workloads Scheduling and Monitoring

Create GPU workloads on the GUI, schedule GPU resources, and manage GPU resource quotas by tenant.

Architecture

KubeSphere 4.x adopts a microkernel + extension components architecture (codename LuBan). The core part (KubeSphere Core) only includes the essential basic functions required for system operation, with independent functional modules split and provided in the form of extension components. Users can dynamically manage the extension components during system operation. With the extension capabilities, KubeSphere can support more application scenarios and meet the needs of different users.

Latest release

🎉 KubeSphere v4.1.2 was released! It brings enhancements and better user experience, see the Release Notes For 4.1.2 for the updates.

Installation

KubeSphere can run anywhere from on-premise datacenter to any cloud to edge. In addition, it can be deployed on any version-compatible Kubernetes cluster. KubeSphere consumes very few resources, and you can optionally install additional extensions after installation.

Quick start

Installing on K8s

Run the following commands to install KubeSphere on an existing Kubernetes cluster:

`1`	`helm upgrade --install -n kubesphere-system --create-namespace ks-core https://charts.kubesphere.io/main/ks-core-1.1.3.tgz --debug --wait`

KubeSphere for hosted Kubernetes services

KubeSphere is hosted on the following cloud providers, and you can try KubeSphere by one-click installation on their hosted Kubernetes services.

You can also install KubeSphere on other hosted Kubernetes services within minutes, see the step-by-step guides to get started.

👨‍💻 No internet access? Refer to the Air-gapped Installation.

Guidance, discussion, contribution, and support

You can reach the KubeSphere community and developers via the following channels:

:hugs: Please submit any KubeSphere bugs, issues, and feature requests to KubeSphere GitHub Issue.

:heart_decoration: The KubeSphere team also provides efficient official ticket support to respond in hours. For more information, click KubeSphere Online Support.

Contribution

KubeSphere Development Guide explains how to build and develop KubeSphere.
KubeSphere Extension Development Guide explains how to develop KubeSphere extensions.

Code of conduct

Participation in the KubeSphere community is governed by the Code of Conduct.

Security

The security process for reporting vulnerabilities is described in SECURITY.md.

Who are using KubeSphere

The user case studies page includes the user list of the project. You can leave a comment to let us know your use case.

KubeSphere is a member of CNCF and a Kubernetes Conformance Certified platform , which enriches the CNCF CLOUD NATIVE Landscape.

WasmEdge

Fri, 18 Jul 2025 15:35:26 +0800

WasmEdge/WasmEdge

中文 | 正體中文 | 日本語で読む

🤩 WasmEdge is the easiest and fastest way to run LLMs on your own devices. 🤩

WasmEdge is a lightweight, high-performance, and extensible WebAssembly runtime. It is the fastest Wasm VM. WasmEdge is an official sandbox project hosted by the CNCF. LlamaEdge is an application framework built on top of WasmEdge to run GenAI models (e.g., LLM, speech-to-text, text-to-image, and TTS) across GPUs on servers, personal computers, and edge devices. Additional use cases include microservices on the edge cloud, serverless SaaS APIs, embedded functions, smart contracts, and smart devices.

Quick start guides

🚀 Install WasmEdge
👷🏻‍♂️ Build and contribute to WasmEdge
⌨️ Run a standalone Wasm program or a JavaScript program from CLI or Docker
🤖 Chat with an open source LLM via LlamaEdge
🔌 Embed a Wasm function in your Go, Rust, or C app
🛠 Manage and orchestrate Wasm runtimes using Kubernetes, data streaming frameworks, and blockchains
📚 Check out our official documentation

Introduction

The WasmEdge Runtime provides a well-defined execution sandbox for its contained WebAssembly bytecode program. The runtime offers isolation and protection for operating system resources (e.g., file system, sockets, environment variables, processes) and memory space. The most important use case for WasmEdge is to safely execute user-defined or community-contributed code as plug-ins in a software product (e.g., SaaS, software-defined vehicles, edge nodes, or even blockchain nodes). It enables third-party developers, vendors, suppliers, and community members to extend and customize the software product. Learn more here

Performance

A Lightweight Design for High-performance Serverless Computing, published on IEEE Software, Jan 2021. https://arxiv.org/abs/2010.07115
Performance Analysis for Arm vs. x86 CPUs in the Cloud, published on infoQ.com, Jan 2021. https://www.infoq.com/articles/arm-vs-x86-cloud-performance/
WasmEdge is the fastest WebAssembly Runtime in Suborbital Reactr test suite, Dec 2021

Features

WasmEdge can run standard WebAssembly bytecode programs compiled from C/C++, Rust, Swift, AssemblyScript, or Kotlin source code. It runs JavaScript, including 3rd party ES6, CJS, and NPM modules, in a secure, fast, lightweight, portable, and containerized sandbox. It also supports mixing of those languages (e.g., to use Rust to implement a JavaScript API), the Fetch API, and Server-side Rendering (SSR) functions on edge servers.

WasmEdge supports all standard WebAssembly features and many proposed extensions. It also supports a number of extensions tailored for cloud-native and edge computing uses (e.g., the WasmEdge network sockets,Postgres and MySQL-based database driver, and the WasmEdge AI extension).

Learn more about technical highlights of WasmEdge.

Integrations and management

WasmEdge and its contained wasm program can be started from the CLI as a new process, or from an existing process. If started from an existing process (e.g., from a running Go or Rust program), WasmEdge will simply run inside the process as a function. Currently, WasmEdge is not yet thread-safe. In order to use WasmEdge in your own application or cloud-native frameworks, please refer to the guides below.

Community

Contributing

We welcome contributions from the community! Please check out our:

Contributing Guide for how to get started
Governance documentation for project decision-making processes
Code of Conduct for community standards

Want to become a maintainer? See our Contributor Ladder.

Roadmap

Check out our project roadmap to see the upcoming features and plans for WasmEdge.

Contact

If you have any questions, feel free to open a GitHub issue on a related project or to join the following channels:

Mailing list: Send an email to WasmEdge@googlegroups.com
Discord: Join the WasmEdge Discord server!
Slack: Join the #WasmEdge channel on the CNCF Slack
X (formerly Twitter): Follow @realwasmedge on X

Adopters

Check out our list of Adopters who are using WasmEdge in their projects.

Community Meeting

We host a monthly community meeting to showcase new features, demo new use cases, and a Q&A part. Everyone is welcome!

Time: The first Tuesday of each month at 11PM Hong Kong Time/ 7AM PST.

Public meeting agenda/notes | Zoom link

License

appwrite

Fri, 23 May 2025 15:28:13 +0800

appwrite/appwrite

Get started with Appwrite Join the Init kick off event 19th of May: The future of Appwrite with Founder & CEO Eldad Fux

Appwrite is a backend platform for developing Web, Mobile, and Flutter applications. Built with the open source community and optimized for developer experience in the coding languages you love.

English | 简体中文

Appwrite is an end-to-end backend server for Web, Mobile, Native, or Backend apps packaged as a set of Docker microservices. Appwrite abstracts the complexity and repetitiveness required to build a modern backend API from scratch and allows you to build secure apps faster.

Using Appwrite, you can easily integrate your app with user authentication and multiple sign-in methods, a database for storing and querying users and team data, storage and file management, image manipulation, Cloud Functions, messaging, and more services.

Find out more at: https://appwrite.io.

Table of Contents:

Getting Started
Self-Hosting
One-Click Setups
Getting Started
- Products
- SDKs
  - Client
  - Server
  - Community
Architecture
Contributing
Security
Follow Us
License

Getting Started

The easiest way to get started with Appwrite is by signing up for Appwrite Cloud. While Appwrite Cloud is in public beta, you can build with Appwrite completely free, and we won’t collect you credit card information.

Self-Hosting

Appwrite is designed to run in a containerized environment. Running your server is as easy as running one command from your terminal. You can either run Appwrite on your localhost using docker-compose or on any other container orchestration tool, such as Kubernetes, Docker Swarm, or Rancher.

Before running the installation command, make sure you have Docker installed on your machine:

Unix

docker run -it --rm \
    --volume /var/run/docker.sock:/var/run/docker.sock \
    --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
    --entrypoint="install" \
    appwrite/appwrite:1.7.2

Windows

CMD

docker run -it --rm ^
    --volume //var/run/docker.sock:/var/run/docker.sock ^
    --volume "%cd%"/appwrite:/usr/src/code/appwrite:rw ^
    --entrypoint="install" ^
    appwrite/appwrite:1.7.2

PowerShell

docker run -it --rm `
    --volume /var/run/docker.sock:/var/run/docker.sock `
    --volume ${pwd}/appwrite:/usr/src/code/appwrite:rw `
    --entrypoint="install" `
    appwrite/appwrite:1.7.2

Once the Docker installation is complete, go to http://localhost to access the Appwrite console from your browser. Please note that on non-Linux native hosts, the server might take a few minutes to start after completing the installation.

For advanced production and custom installation, check out our Docker environment variables docs. You can also use our public docker-compose.yml and .env files to manually set up an environment.

Upgrade from an Older Version

If you are upgrading your Appwrite server from an older version, you should use the Appwrite migration tool once your setup is completed. For more information regarding this, check out the Installation Docs.

One-Click Setups

In addition to running Appwrite locally, you can also launch Appwrite using a pre-configured setup. This allows you to get up and running quickly with Appwrite without installing Docker on your local machine.

Choose from one of the providers below:

_DigitalOcean

_Gitpod

_{Akamai Compute}

_{AWS Marketplace}

Getting Started

Getting started with Appwrite is as easy as creating a new project, choosing your platform, and integrating its SDK into your code. You can easily get started with your platform of choice by reading one of our Getting Started tutorials.

Platform	Technology
Web app	Quick start for Web
	Quick start for Next.js
	Quick start for React
	Quick start for Vue.js
	Quick start for Nuxt
	Quick start for SvelteKit
	Quick start for Refine
	Quick start for Angular
Mobile and Native	Quick start for React Native
	Quick start for Flutter
	Quick start for Apple
	Quick start for Android
Server	Quick start for Node.js
	Quick start for Python
	Quick start for .NET
	Quick start for Dart
	Quick start for Ruby
	Quick start for Deno
	Quick start for PHP
	Quick start for Kotlin
	Quick start for Swift

Products

Account - Manage current user authentication and account. Track and manage the user sessions, devices, sign-in methods, and security logs.
Users - Manage and list all project users when building backend integrations with Server SDKs.
Teams - Manage and group users in teams. Manage memberships, invites, and user roles within a team.
Databases - Manage databases, collections, and documents. Read, create, update, and delete documents and filter lists of document collections using advanced filters.
Storage - Manage storage files. Read, create, delete, and preview files. Manipulate the preview of your files to perfectly fit your app. All files are scanned by ClamAV and stored in a secure and encrypted way.
Functions - Customize your Appwrite project by executing your custom code in a secure, isolated environment. You can trigger your code on any Appwrite system event either manually or using a CRON schedule.
Messaging - Communicate with your users through push notifications, emails, and SMS text messages using Appwrite Messaging.
Realtime - Listen to real-time events for any of your Appwrite services including users, storage, functions, databases, and more.
Locale - Track your user’s location and manage your app locale-based data.
Avatars - Manage your users’ avatars, countries’ flags, browser icons, and credit card symbols. Generate QR codes from links or plaintext strings.

For the complete API documentation, visit https://appwrite.io/docs. For more tutorials, news and announcements check out our blog and Discord Server.

SDKs

Below is a list of currently supported platforms and languages. If you would like to help us add support to your platform of choice, you can go over to our SDK Generator project and view our contribution guide.

Client

:white_check_mark: Web (Maintained by the Appwrite Team)
:white_check_mark: Flutter (Maintained by the Appwrite Team)
:white_check_mark: Apple (Maintained by the Appwrite Team)
:white_check_mark: Android (Maintained by the Appwrite Team)
:white_check_mark: React Native - Beta (Maintained by the Appwrite Team)

Server

:white_check_mark: NodeJS (Maintained by the Appwrite Team)
:white_check_mark: PHP (Maintained by the Appwrite Team)
:white_check_mark: Dart (Maintained by the Appwrite Team)
:white_check_mark: Deno (Maintained by the Appwrite Team)
:white_check_mark: Ruby (Maintained by the Appwrite Team)
:white_check_mark: Python (Maintained by the Appwrite Team)
:white_check_mark: Kotlin (Maintained by the Appwrite Team)
:white_check_mark: Swift (Maintained by the Appwrite Team)
:white_check_mark: .NET - Beta (Maintained by the Appwrite Team)

Community

:white_check_mark: Appcelerator Titanium (Maintained by Michael Gangolf)
:white_check_mark: Godot Engine (Maintained by fenix-hub @GodotNuts)

Looking for more SDKs? - Help us by contributing a pull request to our SDK Generator!

Architecture

Appwrite uses a microservices architecture that was designed for easy scaling and delegation of responsibilities. In addition, Appwrite supports multiple APIs, such as REST, WebSocket, and GraphQL to allow you to interact with your resources by leveraging your existing knowledge and protocols of choice.

The Appwrite API layer was designed to be extremely fast by leveraging in-memory caching and delegating any heavy-lifting tasks to the Appwrite background workers. The background workers also allow you to precisely control your compute capacity and costs using a message queue to handle the load. You can learn more about our architecture in the contribution guide.

Contributing

All code contributions, including those of people having commit access, must go through a pull request and be approved by a core developer before being merged. This is to ensure a proper review of all the code.

We truly :heart: pull requests! If you wish to help, you can learn more about how you can contribute to this project in the contribution guide.

Security

For security issues, kindly email us at security@appwrite.io instead of posting a public issue on GitHub.

Join our growing community around the world! Check out our official Blog. Follow us on X, LinkedIn, Dev Community or join our live Discord server for more help, ideas, and discussions.

License

This repository is available under the BSD 3-Clause License.