We all know that naming things is one of the two hardest problems in computer science (along with cache invalidation and off-by-one errors.)
Naming your microservices is extra hard, as they’re almost like children: they’re practically these living, breathing things that you birth into the world and do your best to make sure they’re set up for success in life (i.e. in production.) Ok, perhaps people don’t agonize over the names of their microservices as much as the names of their children, but it’s still a big enough decision.
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.
So we’ve added something simple but powerful to OpsLevel: Service Aliases. Now you can enrich your services in OpsLevel with all of their various aliases / nicknames, and then use any of these as substitutes when referring to a service.
So, for instance, not only can you search for services by their alias, but you can also use the service alias when pushing deploys to OpsLevel, when sending Custom Check results to OpsLevel, or when hooking up your service info with your other tools via our GraphQL API.
You can find Aliases on the Service Details page. We’ll generate the first alias for you based on your service’s name. (And don’t worry, it’ll stay stable even if you rename your service.)
Go ahead and add all your service nicknames to OpsLevel, and send us an email at firstname.lastname@example.org if you have any questions!