OpsLevel / opslevel-go

A Go client for interacting with OpsLevel
MIT License
5 stars 13 forks source link

Change aliases from list to map #64

Open jan-ludvik opened 2 years ago

jan-ludvik commented 2 years ago

Hi,

While working with opslevel, teams and aliases, some problems we are trying to solve right now would be solved (or it would help significantly) if we had option to not have aliase as a list but as map. This article actually summed it up quite well: https://www.opslevel.com/blog/service-aliases/

And even when you do settle on a name, a microservice can often pick up a number of “nicknames” as well. Maybe your Terraform code refers to your service one way, your deployment system another way, and your AWS tags a third way. We don’t want these nicknames causing confusion or slowing you down.

For exactly this use case it would be great if we could have aliases for example as this (in this example for services):

aliases = {
  aws = "cart"
  k8s = "cart_service"
  terraform = "shopping_cart"
}

In any kind of code, terraform included, I could then get this aliases map and find aliases for specific purpose. For example I could in terraform lookup alias for k8s label and use that in helm chart. Or in AWS Tag Policy I could get list of all services and their aliases with aws and automatically add it into Tag Policy. With teams I could have short name for k8s labels or aws tags while keeping long and human readable format of the team in opslevel. Now I can have the alias in aliases but I don't know which one is the one I want to pick and use and validate against. Now I can't really know which aliases from the list is the one I want. There might be better way how to do this, not with a map (maybe tags for aliases?).

rocktavious commented 2 years ago

@jan-ludvik - Thanks for writing this up this definitely gives me a deeper understanding of the ask. There are a couple of questions I have.

current the data in opslevel on a service or team for Aliases is an ordered by creation datetime list. In your above example each alias now has a "key name" and the actual alias is the value. Question: What prevents you from having these be tags and looking at those to find what the "aws" alias is?

As proposed this would likely cause us to change our data model on the API side since someone at some point will have to set the "key name" for each alias value. Today if this service was in an account it would just have the list

["cart", "cart_service", "shopping_cart"]

We would need someone to define what is the "key name" for each of those to move it to a map. Question: If we did this how would we migrate the database list of aliases to a map? What would the default "key name" be?

{
"alias_1": "cart",
"alias_2": "cart_service",
"alias_3": "shopping_cart",
}

?

Lastly the point of Aliases being a list is that they are a waterfall catchall for looking up a service. IE given a string - find a service by that. It sounds like you are trying to go the other way. IE given a service - name a thing with the same alias Question: Is this understanding correct?

With answers to the above I will take this back to the product team - since its a pretty base level change to the way our aliases are stored and defined I have no timeline for you on this. Thanks again for the insight and request.