DEV Community: Hayden Rear

Decoupling Behavior and Data

Hayden Rear — Sat, 12 Jul 2025 18:33:10 +0000

-- written by ChatGPT - edited by me --

Intro

Extensibility of logic is always difficult. How do we add a particular case in an algebra? How do we handle the control flow? We can't use goto, and sometimes we end with callback hell with monadic styles. So what are we left with? We want a data-oriented programming design - this provides us with the ability to reason about the code easily, because of the fact that it's discrete. But then we always have the undefined nature of recursion, something Nasa thought is dangerous as it's hard to reason about stopping conditions. The AI is very good at math, and coding is getting there, but how can we make our code more logical, more algebraic, and get a recursive style for free, without the complexity?

At first I thought free monads another crazy idea from the academic side. But then, once you think about it within the context of what's been happening in databases, decoupling storage and compute, you start to realize it's more a natural extension of a paradigm shift that's happening. Once you understand what a free monad is, the intuition of it, you realize there are places where the ability to reason about and extend the code increases. It fits very nicely within the greater paradigm shift of code as data, and you get reusability at yet another level. In this case, maybe the experts are right!

Declarative Algebras, One-Step Execution, and the Hidden Free Monad

Describe first, act later.
Capture intent as data, postpone behavior to a pluggable interpreter—then watch extensibility emerge.

1. The principle

Across cloud warehouses, build pipelines, and micro-services, the winning pattern is:

Capture intent as plain data – inspectable, serializable, versionable.
Defer behavior to a separate phase – interpret, optimize, simulate, or replay whenever you like.

A fancy name for that pattern—one we won’t reveal until the very end—is the free monad.
But let’s get there step by step.

2. Build an extensible algebra

Start with zero side effects. Each constructor is frozen intent plus “what to do next.”

// Java 21 sealed algebra of document operations
sealed interface DocOp<A> permits Read, Transform, Store { }

record Read<A>(
    String path,
    java.util.function.Function<String,A> next           // carry on with file text
) implements DocOp<A> { }

record Transform<A>(
    java.util.function.Function<String,String> fn,       // pure transform
    java.util.function.Function<String,A> next           // carry on with new text
) implements DocOp<A> { }

record Store<A>(
    String dest, String content,
    A next                                               // nothing to pass along
) implements DocOp<A> { }

Need a new feature tomorrow—say NotifySlack? Add one more record; the compiler makes you handle it explicitly.

3. Stitch steps declaratively

We need a container that chains these atoms without running them.
Here’s a micro-“script” type (a tiny free monad):

sealed interface Script<A> {
  /* A finished program */
  record Pure<A>(A value) implements Script<A> { }

  /* One pending step followed by the rest */
  record Step<X,A>(
      DocOp<X> op,
      java.util.function.Function<X, Script<A>> cont
  ) implements Script<A> { }

  static <A> Script<A> pure(A a) { return new Pure<>(a); }

  /* Declarative bind */
  default <B> Script<B> then(java.util.function.Function<A, Script<B>> f) {
    return switch (this) {
      case Pure<A>(var v) -> f.apply(v);
      case Step<X,A>(var op, var k) ->
        new Step<>(op, x -> k.apply(x).then(f));
    };
  }
}

Write workflows as data:

Script<Void> build =
  new Script.Step<>(new Read<>("src/doc.txt", Script::pure), raw ->
  new Script.Step<>(new Transform<>(String::trim, Script::pure), clean ->
  new Script.Step<>(new Store<>("dist/doc.txt", clean, null), __ ->
  Script.pure(null))));

Still no I/O!

4. One-step interpreter: jump, return, repeat

interface Engine<F> { <T> F run(Script<T> script); }

/* Production engine using async I/O */
class IOEngine implements Engine<java.util.concurrent.CompletableFuture<?>> {

  public <T> java.util.concurrent.CompletableFuture<T> run(Script<T> s) {
    while (true) {                               // ← single tail-rec loop
      switch (s) {
        case Script.Pure<T>(var v) ->            // ① finished
          return java.util.concurrent.CompletableFuture.completedFuture(v);

        case Script.Step<Object,T>(var op, var k) -> {
          switch (op) {                          // ② match the case
            case Read(var p, var nxt) -> {
              return java.nio.file.Files.readString(java.nio.file.Path.of(p))
                  .thenCompose(txt -> run(k.apply(nxt.apply(txt)))); // ③ jump
            }
            case Transform(var fn, var nxt) -> {
              s = k.apply(nxt.apply(fn.apply("")));
              break;                             // loop continues
            }
            case Store(var d, var c, var nxt) -> {
              return java.nio.file.Files.writeString(java.nio.file.Path.of(d), c)
                  .thenCompose(__ -> run(k.apply(nxt)));
            }
          }
        }
      }
    }
  }
}

Peel one Step.
Handle the matching constructor.
Return the next Script (or tail-recurse).

That short “jump-to-next-step” loop never changes—add new cases, plug them in, done.

5. Recursive composition for free

Because every step returns another script, scripts compose like Lego:

Script<String> readClean =
  new Script.Step<>(new Read<>("in.txt", Script::pure), raw ->
  new Script.Step<>(new Transform<>(String::trim, Script::pure), Script::pure));

Script<Void> saveTwice =
  readClean.then(clean ->
    new Script.Step<>(new Store<>("out.txt",    clean, null), __ ->
    new Script.Step<>(new Store<>("backup.txt", clean, null), __ ->
    Script.pure(null))));

No matter how deep the graph, the interpreter still just peels one layer, does work, repeats.

6. Why step-at-a-time rocks

Benefit	Comes from “handle one step, return the rest”
Infinite pausing	You can pause, inspect, rewrite, or migrate mid-script.
Fine-grained billing/retry	Each node is an observable unit of work.
Hot-swappable engines	Same script runs on I/O, mocks, audit logs, …
Local reasoning & changes	Add/adjust a constructor; compiler forces local updates.

7. The hidden reveal

If the structure feels familiar—a functor of single actions wrapped in a bindable container—you’ve secretly rebuilt the free monad for DocOp.

So the next time you separate intent from effect, remember:
that jump-to-next-step interpreter is the categorical machinery that makes modular, recursive, endlessly extensible software almost trivial.

Happy decoupling!

Emergent Software Principles I've Learned

Hayden Rear — Sat, 11 Jan 2025 20:41:16 +0000

Code as Data and Data Structure as a Program

The best code is provably correct, and the most provably correct code is a data structure. Trying to write your program as a data structure makes it more testable and more provably correct. Moreover, using the best data structure for the job makes the code much more resilient and a source of great abstraction. Learn your data structures and then learn them again, always be learning your data structures! You can always start with an off-the-shelf version and then create a customized version as a performance optimization. Then you can compare the naive version to the custom version.

Example: using a trie for file paths, using a graph for program analysis.

MicroBench

Typically test based development (basically all development) leads to code that just barely passes. So then when you increase the load a little bit (or add just a little bit more data), it could break. This is the importance of micro-benchmarking.

Scalability as Smallest Units of Work Under Infinite Load - Theory of Constraints

Anything can break under sufficient load. Make sure that the bottleneck scales for the load you need.

Pascal's Triangle as Emergent Refactors

When I first learned recursion I spent hours banging my head against the wall implementing pascal's triangle. Later on I learned that much of emergent refactors resemble some n-dimensional version of pascal's triangle. As we refactor to add a needed emergent layer of abstraction, that layer of abstraction becomes the next layer in the base of this n-dimensional "pyramidal" structure. Make sure the layers are firm foundations for the next layer.

Result Type as Point of Coupling - Decoupling Away "Distributed" as Metadata

Typically developers depend on some stream or IO provided by some other developer, making it hard to decouple the implementation. As microservices are refactored away, result types will become more important.

The Weakest Chain in the System Should be You - Observability Matters

If you're system doesn't provide a mechanism to observe the issue before it becomes a problem, then there's something wrong with the way you deploy code.

Example: before you release your code, you look through all of the errors you had - from the perspective of structured logging. So then you see the error - you ignore it. But it's not an ignorable error! In this case you made a mistake. But the system for letting you know that there is a bug is good!

Defining things only in terms of the most complex case, the programmer's dilemma

The programmers dilemma is I want to do the least amount possible but I need an emergent design out of the most complex set of cases for the minimum viable product.

This is coming from a greater truth related to the resilience of a system being based on the maximum amount of testing done, and the way the testing relates to the provable resilience of the system... resulting in failures when you push just a little bit harder, just a little bit beyond what you've tested before, and specifically how that test relates to the provable resilience of the system.

The Single Unifying Thread

The most generic implementation, typically ByteBuf or something similar in IO, for instance. It should be the emergent data structure from the emergent design of your system.

Levels of Abstraction ~ Levels of Testing

Being able to replicate bugs quickly in some ways depends on testing capability. If I find a bug in the system and I have a testing architecture set up, then I can recreate the bug quickly and with minimal setup by running the test with a different input, or running the test a bit differently, or cloning a test setup and running it a different way.

Example: you find a bug in prod and it's one of these "difficult to replicate" issues. At the very least you should have a test harness that works a starting point for replication. So many developers everywhere just run the thing from beginning to end, resulting in these ridiculous turnaround times. Testing is all about creating tests at the layers of complexity to replicate bugs, hopefully replicating them at the time you first write the code, but if necessary being able to use the test setup to do so.

Everything Converges to Iteration and Validation

Especially today in the AI world. Consider that! If I have a complex system with many layers of hidden abstraction, and call a REST endpoint, the level of granularity of my response determines the quality of my feedback loop. And the feedback loop is everything in software, increasingly when you are trying to cost minimize with AI.

Good Code as a Data Structure

Hayden Rear — Sun, 08 Sep 2024 12:16:07 +0000

What do the frameworks have in common? How do you rectify the divide between object oriented and functional? How can we write code that can be provably correct, logically? One thing that has come up is modeling the "data", and even modeling a data structure.

So when we write code that performs some actions, we want to prove that it performs the way we want it to in all cases. But then the number of cases grows to be out of control, resulting in wild edge cases. How to simplify? We make it a data structure that satisfies the needs. So then we only have one of iterate, add, remove, etc, and then we can add hooks into this data structure, such as afterAdd, afterRemove, postConstruct, and then we can build out our program as nodes that get added and perform behaviors after being added, removed, etc.

One thing that's become viral is this idea of "hooks". We hook into the behavior in a way that we can prove. I argue that this is just that - a data structure that we hook into.

So putting this together, we have a data structure that we can prove, and then we add hooks into that data structures behavior that we can prove things about. The nice thing about this is that it allows for the logic to be refined at various levels of the hierarchy, allowing reuse of the code and the logic to be refined correctly.

10 Things You Should Be Thinking About Doing for the Coming AI Crisis: A Software Developer's Guide

Hayden Rear — Wed, 02 Aug 2023 12:04:26 +0000

10 Things You Should Be Thinking About Doing for the Coming AI Crisis: A Software Developer's Guide

Introduction

The rise of AI is heralding a new era in technology, one that holds promises of innovation but also challenges that could disrupt many professional careers, including software development. The future is uncertain, but by preparing for it, software developers can transition their skills and stay ahead of the curve. Here are the ten things you should consider doing to navigate the coming AI crisis.

1. Embrace Lifelong Learning

Subpoints:
- Understand the need for continuous education in the field of AI and machine learning.
- Participate in online courses, workshops, and AI-focused meetups.
- Stay up-to-date with the latest AI research, tools, and methodologies.

2. Focus on Human-Centric Skills

Subpoints:
- Improve skills that are difficult for AI to replicate, like creativity, critical thinking, empathy, and collaboration.
- Work on communication skills to bridge the gap between technology and business needs.

3. Diversify Your Skillset

Subpoints:
- Learn about adjacent fields like data science, cybersecurity, or UI/UX design.
- Pursue cross-disciplinary knowledge to enhance adaptability and resilience.

4. Build an AI-Ready Portfolio

Subpoints:
- Include AI-related projects and contributions.
- Show off problem-solving skills using AI and machine learning.

5. Network with AI Professionals

Subpoints:
- Engage with the AI community through social media, conferences, and local groups.
- Foster relationships with mentors and industry leaders.

6. Understand Ethical Considerations

Subpoints:
- Study the ethical implications of AI in various contexts.
- Commit to responsible AI development and usage.

7. Invest in AI Tool Mastery

Subpoints:
- Learn and practice with leading AI frameworks and tools.
- Understand how to leverage cloud-based AI solutions.

8. Prepare for New Roles

Subpoints:
- Identify emerging job roles that align with AI development.
- Consider shifting into specialized roles that require deep expertise.

9. Contribute to Open Source Projects

Subpoints:
- Engage with the global AI community through open source contributions.
- Enhance your skills and reputation by working on real-world problems.

10. Think Globally, Act Locally

Subpoints:
- Understand the global impact of AI on society and industries.
- Identify local opportunities and challenges and act accordingly.

Conclusion

The coming AI crisis is both an opportunity and a challenge. By taking proactive steps, software developers can not only survive but thrive in this new era. The future belongs to those who are prepared, so begin the journey today by considering these ten pivotal aspects of professional transition.

Temporal Differencing vs Markov Chain Monte Carlo to Understand Model-Free, Model-Based, and Inverse Reinforcement Learning.

Hayden Rear — Mon, 10 Jul 2023 13:48:35 +0000

Reinforcement Learning

I remember the first lecture I watched on reinforcement learning. It was an MIT lecture about using a robot to bounce a ping-pong ball using a paddle. The lecturer discussed how in order for the machine to learn, it needed to "remember" the experiences in order to update it's ability.

I had an AHA! moment, allowing me to realize how a machine could "learn". At the most extreme, it could be a table remembering each exact experience, and it could just try again and again until it succeeded, recording the successes and using the states previous to those successes to determine how to make the next second a "success". It could record a state and the action to take based on that state in order to maximize "success".

However much I thought I knew in that moment, I failed to understand the complexity. It was one of those moments where I understood some very basic thing and generalized it to every possibility. In fact, to use reinforcement learning, you don't even need to be able to create "successes", but can learn as we go along if we have a way of extracting reward from the environment. Then, there is one step further: dynamically learning the reward function. Taking this step is almost "creepy". Not only does the agent learn as it goes along, it also learns how to learn by learning "what" to learn! This would be called "Inverse Reinforcement Learning".

Markov Chain Monte Carlo

Monte Carlo methods are the foundations of a lot of important machine learning algorithms, including temporal differencing. I think that most machine learning algorithms can be understood in terms of Markov Chain Monte Carlo, such as Transformers. and Temporal Differencing. Markov Chain Monte Carlo is a model-based approach, meaning it extracts the "model" from the environment in the first step, and then samples from the environment to find the most desirable state based on the probability of retrieving a state from an action, and the reward of the states.

Temporal Differencing

Temporal differencing takes this a step further. In Monte Carlo, we start with modeling the environment. Temporal differencing is more towards the "online" learning side. We start by initializing our model of the effect of the decisions arbitrarily. As we go along, we update the function that predicts the reward of the next state, and by "next state" I actually mean every state that I might take based on that state, often discounted. I am a chessmaster that is looking ahead into all of the moves at this point, discounting them. Or I am a really bad chess player who has no idea how to determine the moves. Hopefully you move from bad to good as time goes on.

Really the model-based and model-free both have "models", but the definition of "model" is blurry in this context:

What is the "Model" in the context of model-based and model-free

We talk about "model-based" and "model-free". But what is this "model"? The model can be thought of learning how to estimate the states, actions, and rewards, and how they relate to each other. If I am in a particular state, then these are my actions and this is the reward. This distinction between model-based and model-free lies in the environment dynamics. Does the model maintain some explicit idea of the transition dynamics of the environment based on the actions? Does the model then sample from this idea of the environment in order to determine which action to take? In the model-free algorithms, we learn a policy based on the state. In the model-based algorithms, we model the environment directly. It's a bit confusing because of course we have models, but in model-free we have a model that models the model of the environment, or something like that.

Inverse Reinforcement Learning as a Step from Model-Free

If I thought of model-based as one step, moving towards "online", and then I took another step in that direction, model-free, then I would consider learning the reward function online as one step too far!

Effect Handlers in Functional Programming

Hayden Rear — Sun, 21 May 2023 13:49:51 +0000

What are side effects in functional programming? Why are they used?

What is FP

I am not going to bore you with the introduction you usually get. If you are reading this, then you already know about immutable state and pure functions.

What are side effects?

You probably know what side effects are, but I'll talk about them here. Side effects are something that is something that causes an effect to happen outside of the application. They are introductions of instability into your pure code. They are toxicity in the water. We must manage them well if we maintain reasonability in our code.

For example, let's say I am creating a new age database. This new age database is distributed, and says that it is consistent, but it's eventual consistency hinges on the fact that the interactions with the database are compiled WASM modules. The WASM modules are passed in, with an identifier for the component that is interacting with the database.

Every time that a new behavior is added to the database, query is pre-registered. Then, the component that interacts with the database sends the parameters to the query. The query sits in the databases stack and on a clock when all the nodes of the database confirm, they are committed.

But here's the thing: if the nodes disagree on the ordering of a transaction, the transactions can be reordered, and that means that the output of the transaction changes. So the user includes their transaction ID, and all is well. The transactions are re-ordered and re-executed on the stack, and everything is fine. And I make billions of dollars overnight because I used the acronym WASM DB.

Side Effects Ruin Everything

Unfortunately, there is something wrong with our WASM compiled distributed new-age ridiculous database. If the user receives a response, which is "eventually consistent", then that response is subject to change. Of course if they just continue interacting with the database with their component ID, then it will propagate up through the stack. Of course, if there is no question about the ordering of the transaction, then the result they ended up getting will be the result (and under normal circumstances they can trust the result), HOWEVER if they are to perform some action outside of the system with the result, and it turns out to be outdated, then - sorry - everything starts to fail. Let's say they write to a log with the result, and then some other component reads from that log, and performs some actions, such as locking a user account. The user calls in and says, "why did you lock my account?", or a thousand users call in all at once.

How to Properly Manage Side Effects

Side effects are a part of life, sort of like shit in the ocean. So how do you introduce the impure into the pure, without making it impure? Here are a few ideas:

Have a pure function describe the effect.
Have another function take the description of the effect and perform the actual side effect.

What does this mean? We take some behavior of the system and have a deterministic output. Determinism is key, because at this point we have all the different possible outputs. And then we can write test cases for each one, if we are good enough :).

Transformer Attention Mechanism Intuition

Hayden Rear — Sat, 13 May 2023 15:00:56 +0000

Transformers are very important to modern society. I, at one point, thought that transformers were here from the devil to transform the world into chaos. At one time I thought they would transform the world into utopia. In any case, the power they possess is alluring. Where does it come from? What is attention? How does it result in such amazing feats?

What is Attention?

Attention mechanism is effectively a way to extract features from the input data. Like convolutional layers extract features from an image, so attention mechanisms extract features from language, or anything else that you input into it. It is used in Transformer to compare the sequence to itself, to predict the next word, but you could compare other things as well, using the same attention mechanism.

Attention Heads as Information Channels

To understand the intuition behind a transformer, you can think of them as setting up information channels between different parts of the sentences. If you have ever heard or studied convolutional neural networks, they are like a convolutional neural network on steroids. Essentially, the attention heads move across the sentence, and then they are compared to each other to see how they relate. These attention heads picking out parts of the sentences to compare to each other is like setting up information channels between different parts of the sentences, so that information can get through. Like a CNN uses the kernel to extract features in a square, moving it across the image, so the attention heads move across the sentence. The difference is that there are multiple attention heads, each moving across the sentence, which each set up channels between different parts and then compare them to each other.

Key, Query, and Value Intuition

I like to think of things in terms of y = mx + b. For a neural network, this is like a recursive relationship, where the m contains more y = mx + b, but the basic idea is that the m is calculated to find the relationship between y and x. Key, Query, and Value can be thought of, intuitively, like this, where the Key = Query * Value. For example, in a transformer encoder for language models, the key, query, and value are all the input sentence, because you are trying to see how the sentence relates to itself. This is why it's called self-attention, because we use the attention mechanism in such a way to set the key, query, and value to the same "self", which is the language input.

The power of attention does not stop at self-attention, however. You can set the key and the query to the same, and then set the value to something else, to see how two inputs vary, to extract features from two different sequences. Effectively, attention is a way to extract features from sequences. The only problem is that when you set up that many channels, it can be costly. In fact, it is hard to imagine how badly the attention mechanism scales. This is why new ways to extract features that use or resemble attention mechanism are being created. It is difficult to do so well, however, because the power from the attention mechanism comes from the fact that there be a way for the information to flow through, and without having a "channel" set up for it to flow through, it will not be able to. This is why we use attention to set up multiple channels for each word, however in the future we will probably get better at predicting which channel to listen to.

MBeans

Hayden Rear — Tue, 09 May 2023 00:11:09 +0000

Java MBeans - how do you know which ones to scrape? How do they work? What in the world does this mean?

  - pattern: 'java.lang<type=GarbageCollector, name=(.*)><>CollectionCount'
    name: gc_collection_count

Scraping MBeans

The first thing to keep in mind is that MBeans use remote method invocation to get the metrics that the MBean exposes. One of the quarks of Java MBeans is the way that they are identified. Here is an example ObjectName:

java.lang:name=G1 Old Generation,type=GarbageCollector

And here is an example of some code where you create an MBean, and start to understand how they are indexed for a JMX Exporter with the ObjectName:

import javax.management.*;

public class Main {
    public static void main(String[] args) throws Exception {
        MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
        ObjectName name = new ObjectName("com.example:type=MyMBean,name=MyInstance");
        My mbean = new My();
        mbs.registerMBean(mbean, name);

        System.out.println("MBean registered. Press Enter to exit.");
        System.in.read();
    }
}

And so the question is - how can everything be identified by a string? Does the ordering matter? In fact, after the domain and the type and name, there is a list of key value pairs, and those are the properties.

Properties vs. Attributes

Properties are identifiers for the MBean. In the example, the properties are type and name. You can filter by properties using JMX in the above example. Attributes are the metrics we are exposing. In the example at the start, CollectionCount is the attribute. We can add a regex expression there as well, to expose all of the attributes. So you can also filter by attributes, in that you can only expose some of the attributes of an MBean. However, typically the properties are used to identify and filter the MBeans. You can do some cool stuff with MBeans, such as creating histograms with the different values that the attributes can have, and you do this using JMX Exporter type, which is completely different than the property "type" used to filter.

But where are the attributes?

If you look at an MBean, you will see your standard getters and setters, providing access to the attributes. These getters and setters would then be called with RMI to provide access to the data that is exposed via your favorite JMX exporter.

For the example at the beginning:

Here the collection count is exposed using the getter, getCollectionCount, and this method is called using RMI (remote method invocation) with JMX.

Finding MBeans to Scrape

The first aha moment, when it comes to Java MBeans, is having a nice user interface to look at them. And, fortunately, if you have Java JDK installed, you have that user interface installed, and it's called jconsole. So if you open up a terminal and type jconsole, and follow the prompts to connect to a Java process, then you'll see something like this:

Notice the attribute, collectionCount. And so you can see how to provide the previous pattern to access the metrics for the MBeans.

"Types" of MBeans

The last thing to keep in mind when it comes to Java MBeans is that there are two things called types. Welcome to a strongly typed language. In any case, when it comes to JMX exporter and Prometheus, there is not only the type of MBean, but there is also the type of value. Examples include counter and gauge. Counter would handle something like number of garbage collections, while gauge is some continuous value. Additionally, Java has attributeType in the MBeanAttributeInfo, which is a separate type of MBean. Quite confusing, however this attributeType is different from the type of value that Prometheus interprets.

What in the world was that?

The starting snippet is a JMX exporter rule. It matches on the MBean type, and all the various attributes. In JMX, you define these rules to determine which MBeans are exposed to the outside through the JMX exporting.

Kubernetes Services Evolution

Hayden Rear — Mon, 08 May 2023 23:46:43 +0000

Kubernetes is a complex piece of software. Over the years of learning about it, it seems to have become more complex - the more I learn, the more I realize I don't know. One thing that has become more clear, however, is networking. I was once confused as to how to allow pods to talk to each other, but no more. Here are the things that helped me understand Kubernetes Services.

Services - NodePort, Load Balancers, and ExternalName

Kubernetes allows communication in a number of different ways, and they are normally through a service, where we change the type in the yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 8080
  type: NodePort

I like to think of Services as being like Pokemon that evolve. NodePort is like the first baby pokemon before it has evolved. It is the simplest way to expose a Service. It forwards the traffic to a set of pods from a port. Then the poke-service evolves into a LoadBalancer, which provides an external IP address, load balancing, and other features. Normally LoadBalancers are used in a cloud environment, which leads to the Ingress, which isn't a service at all. The Ingress provides a way to provide access to multiple services on different paths.

Here is an example LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: service1
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector:
    app: service1
  ports:
    - name: http
      port: 80
      targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: service2
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector:
    app: service2
  ports:
    - name: http
      port: 80
      targetPort: 80

and Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: service1.example.com
    http:
      paths:
      - path: /service1
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              name: http
  - host: service2.example.com
    http:
      paths:
      - path: /service2
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              name: http

Load Balancer vs Ingress

The difference between LoadBalancer and Ingress is a bit nuanced, but both LoadBalancer and Ingress require external implementation, such as ElasticLoadBalancer or Istio's Ingress Controller. Ingress controller's provide more advanced routing, such as based on URL Path, while the LoadBalancer implements a load balancing algorithm. Additionally, the Ingress can be the plugin point for much other features of Service Mesh, such as mTLS. LoadBalancer can provide access to multiple services, but it doesn't use the path rerouting.

Communication

"But how do you make the service call?" - In order to make the service call, just use the name of the service!

In this case:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 8080

I could make the REST call like so, from the metadata.name:

http://**my-service**/v1/make/some-call.