With 21w15a snapshot, a new entity was added as replacement for using armor stands in datapacks, and it is faster and has far more potencial.

Why we used to use armor stand?

Armor stands are very useful while making datapacks. They can be placed anywhere in the world with NBT such as {Marker: 1b, Invisible: 1b, Tags: ["my_armor_stand"]} to mark a certain point so we can find it later using @e[​tag=my_armor_stand]. No more! Now, the new minecraft:marker entity can be used.

What is a Marker?

The marker is a new entity that can be used instead of an armor stand. It can be summoned via a command like this:
summon minecraft:marker ~ ~ ~ {Tags: ["my_marker"]}It is basically the same as an invisible marker armor stand, but has some differences. Let's look at them.

Markers aren't client-side

To understand this we need to understand how the game works. There are two parts of the game - one is called the server, and the other is called the client. When playing singleplayer this normally doesn't matter since both sides are in the same computer, but if we play multiplayer, the server is inside a computer which belongs to the server owner (or host), and there can be many clients - one for each player, and every one is inside its player's computer. When player 1 punches a zombie, his/her client sends the server a message - "I want to punch the zombie". The server checks if it's legal. for example, if you can't see the zombie, you can't punch it (this is to prevent bugs and hacks). If it decides it's legal, the server sends all the clients a message, telling them player 1 punched the zombie, so they can all update the zombie's health. This is how most actions are made in the game. Notice that the zombie exists in several places - it exists in the server, and it also exists in each client and is updated per changes in the server.

With markers, this is defferent. Instead of existing inside each client, the marker only exists in the server. This means the client doesn't even know the marker exists, unless you ask the server directly via something like @e[​type=minecraft:marker] (in this case, the client will send a message to the server asking for the marker's information). Note that data packs are server-side. What does that mean? It means you can put as many markers as you want in the server, and there would be no lags in the client-side. It also means it's not possible to see the marker - not even if you give it glowing, go to spectator or activate hitboxes (F3+B). It is not counted towards the entity count when using F3+H and basically doesn't exist.

Markers can store any data

This is probably the main reason markers are so much better than armor stands, despite the facts that they are not client-side (less lags) and don't update anything (less bugs), markers can also store any NBT data you want. Mostly, if you try to write anything into an entity it just vanishes - for example, if you have a [​tag=my_armor_stand] armor stand and you type the following:
/data merge entity @e[tag=my_armor_stand] {NBTTagThatDoesNotExist: 42b}Nothing happens. You can't just store anything you want inside the armor stand, only boolean value via tags (e.g. giving it the tag "yes" if it's true and remove it when you want it to be false, and then use [​tag=yes] to determine). Markers can store anything, from bytes to arrays and even objects. How does this work? Simply insert it inside the data tag.
/data merge entity @e[tag=my_marker] {data: {NBTTagThatDoesNotExist: 42, myArray: [17, 100, 5], longString: "I am long!!", brain: {exists: 0b, name: "null", iq: 0}}}RIP armor stands