Much has been discussed about Docker, the tremendously popular (and justifiably so) open-source project that automates the deployment of applications inside software containers. At New Relic’s FutureStack14 Conference, Solomon Hykes, Docker project progenitor and CTO of Docker, Inc., delivered this keynote address, in which he describes the context within which Docker arose and grows, the reasons for its creation and advancement, and the greater need to build on its momentum in order to help developers as a whole. Summarizing the key conditions that brought about Docker, Solomon observes that the distributed applications of today “are not distinguishable from the Internet, really.” They’re expected to always be available and always work, and to be accessible from anywhere at any time, no matter how many different users and types of devices are using them. Applications must be elastic, massively scale-able and completely interoperable. End users have come to expect no less, and developers not only must meet the current demand but also build the next generations. This is hard work, especially in an environment where old platforms no longer meet these challenges, and when a developer hits a snag it’s no longer enough to simply phone an iOS friend or an Android friend. The tooling solution must address the biggest problem facing developers: the application is not running on only one computer, but it has to seem that way in order for the developer to deconstruct and reason it. This solution “requires independence between the logical software component and the underlying infrastructure, so that when machines go down, or are upgraded or deployed somewhere else, somehow the service is always there, independent of one machine.” Large tech shops such as Amazon, Apple, Google and Microsoft have invested considerable time and resources in their own, in-house stacks, and this has left everyone else to cobble together open source tools and persevere. “The general feeling,” Solomon laments on behalf of all developers, “is that the whole thing lacks a cohesive answer. Developers can’t point to something and say, ‘That’s what I’m building on; that’s my platform.’ That’s really the urge that, collectively, we’ve felt for some time: to come together and just build it, just define what the hell this platform is and just make it meet the requirements, and then we can go on to the interesting stuff…”
Much has been discussed about Docker, the tremendously popular (and justifiably so) open-source project that automates the deployment of applications inside software containers.
At New Relic’s FutureStack14 Conference, Solomon Hykes, Docker project progenitor and CTO of Docker, Inc., delivered this keynote address, in which he describes the context within which Docker arose and grows, the reasons for its creation and advancement, and the greater need to build on its momentum in order to help developers as a whole.
Summarizing the key conditions that brought about Docker, Solomon observes that the distributed applications of today “are not distinguishable from the Internet, really.” They’re expected to always be available and always work, and to be accessible from anywhere at any time, no matter how many different users and types of devices are using them. Applications must be elastic, massively scale-able and completely interoperable. End users have come to expect no less, and developers not only must meet the current demand but also build the next generations.
This is hard work, especially in an environment where old platforms no longer meet these challenges, and when a developer hits a snag it’s no longer enough to simply phone an iOS friend or an Android friend.
The tooling solution must address the biggest problem facing developers: the application is not running on only one computer, but it has to seem that way in order for the developer to deconstruct and reason it. This solution “requires independence between the logical software component and the underlying infrastructure, so that when machines go down, or are upgraded or deployed somewhere else, somehow the service is always there, independent of one machine.”
Large tech shops such as Amazon, Apple, Google and Microsoft have invested considerable time and resources in their own, in-house stacks, and this has left everyone else to cobble together open source tools and persevere.
“The general feeling,” Solomon laments on behalf of all developers, “is that the whole thing lacks a cohesive answer. Developers can’t point to something and say, ‘That’s what I’m building on; that’s my platform.’ That’s really the urge that, collectively, we’ve felt for some time: to come together and just build it, just define what the hell this platform is and just make it meet the requirements, and then we can go on to the interesting stuff…”