In his most recent post Anthony Ferrara talks about service containers, the cousin of dependency injection containers (DIC) that he argues aren't much better than global variables.

I am a firm believer that service containers are not a form of Dependency Injection, and are only slightly better than global variables. That led me to make a few comments that elicited a reply from two Fuel developers. That led to a rather interesting debate that just couldn't fit into 140 characters [on Twitter]... So I'm going to go into topics that are tightly related: variable scoping and service locators.

He starts by defining what global variables are (including the requisite Wikipedia definition) and how they're commonly use "everywhere" in the application, both set and read from. He contrasts this idea against a static variable from a class and redefines the scoping a bit when talking about objects and their properties.

So how does this apply to service locators (aka service containers or dependency injection containers)? Well, all state that's managed by a service locator immediately becomes global state to the objects that use the locator. So why is it all the rage? It's simple. It seems simple on the surface. If your object needs another dependency, there's no need to adjust how it's constructed, just pull it from the locator. Sounds great, right? Well, not quite.

He points out some of the main issues with using service locators namely difficulty in unit testing them, dependencies within the container, how it violates both the Law of Demeter and the Single Responsibility Principle as well as causing "hidden coupling" issues.