In addition to kitchen appliances Twitter could largely be serving as the messaging backbone for hundreds of the most popular apps and games if it had opted to embrace the Open Web. Sure serving as a messaging backbone for the whole world would have put additional burden on their server infrastructure, and it would have allowed third parties to monetize tweets, but it also widens Twitter's on-boarding funnel dramatically because it locks myriad diverse products, games, and services into their API.
Instead Twitter chose to lock down their API and focus instead on monetizing what traffic they had already captured. They turned it into an content discovery portal when it could have been a content discovery portal *and* the defacto Internet architecture primitive powering diverse social communities and integrated into just about every network-enabled device on Earth. After all even the TV news networks were embracing both the @name and the #hashtag. But then the executives at Twitter somehow decided to dig a moat around the platform, and then a swamp, and then fill it with alligators I mean lawyers, and now in 2015 Twitter has of all things a growth problem.
I believe that the true hidden potential of the platform lies in Twitter's potential role as the world's ubiquitous identity and reputation broker.. In other words the @name was more valuable than the tweet.
I think that if somehow the iron fist is relaxed so that the tweets flow open and free then the world at large would learn to embrace the @name as their preferred way to establish digital identity & reputation in place of the fragmented email+linkedin+website that people use today.
However for early stage web startups especially ones that use the JVM there are only really likely to be a handful of diverse technologies in play. A typical example: nginx, jruby, redis, kafka, <primary persistence tech goes here>. Now at first glance you might look at this and see 5 diverse systems and think "these guys could probably benefit from docker", and perhaps some could, but I personally think that a growing number of shops feel like it's a waste of time and resources, and here is why:
Although there are five separate systems in the example above the truth is that developers are not sitting around writing nginx config files all day, nor kafka config, nor redis config, nor Mysql config files. Those are things that you only have to setup correctly once and then you only change gradually, a few lines here and there over the lifetime of the business until you settle in on the most optimized configuration for your workload.
99.9% of your team's changes will only touch the "application layer" which in this example resides on a single runtime environment (the JVM). Teams who utilize the JVM in this way usually don't feel "pinned in" by it since after all the performance is there, the mature profiling tools are there, the library ecosystem is there, and there are diverse programming languages, frameworks, and multiple programming paradigms all of which ride atop the JVM. examples: (Java, JRuby, Scala, Clojure, Vertx.io (non-blocking io/javascript), Lift, Akka, spray.io, Play, Immutant, Wildfly, etc)
What I'm getting at is there's really no good excuse for a team who standardizes on the JVM to ever need to go outside of that paradigm unless perhaps they're writing a C extension to optimize some tight loop, but these days the JVM's optimizing bytecode compiler is getting pretty decent at doing that for you.
If 99% of your application code (the code that is updated continually) runs on the JVM then even if you have a micro-services architecture with several different programming languages in use you don't really need to lean on a containerization technology to standardize deployment because all of it is already under the same runtime environment roof anyways. From an operations standpoint all your build/deploy step really needs to do is ship jar files around over the network irregardless whether it's a clojure service, or a scala, or ruby app. And all of it can be monitored in a clean way thanks to the monitoring support built into the JVM called JMX.
To use docker in such a situation is to just waste system resources and to increase network IO (moving heavy disk images around) for no reason. Instead you can just use shell scripts or Ansible to provision an instance and then rely on the JVM's own venerable mini-containerization primitive (the jar file) as the standard way to deploy apps across your fleet.
To each his own though..