https://bytes.grubhub.com/how-we-build-services-fast-a-look-at-the-grubhub-service-framework-181ae2091391

When developing around a service-oriented architecture, the engineers at Grubhub had to roll a lot of code for all the technology, providers, and infrastructure choices we made. Datadog requires a client library invocation any time you want to increment a metric. Splunk must be configured for every new service to ensure it includes appropriate tracking and instance information. Moreover, should we want to leave ourselves open for changes to these integrations, we could incur the cost of adapting our 100+ services to a new integration pattern. The situation can easily spiral out of control, and we wanted to avoid that before it affected our business.

At some tech companies, especially early stage ones, tech teams aren’t eager to enforce many standards around their code and the teams are given free reign over how they integrate with their chosen technologies. While they might restrict their organization to a few languages, database, and cloud provider choices, more is left open to exploration. Libraries to integrate in the chosen language with a given database or cloud provider might be up for grabs; creating new libraries to integrate with a specific function of a given cloud provider could also be on the table. This has several benefits: less time to test out new technologies and smaller up-front development cost.