Prediction: Docker moves from dev and test into production
What will the next six months hold for Docker? “It’s evolving extremely quickly. I’m hoping that at DockerCon we’ll see more production-ready case studies,” said Battery Ventures’ Cockroft. “People running Docker in production, they’ve hand-crafted a lot of things. But it’s a matter of months to having more tooling: Products making it easy for test and dev workloads to switch over to production.”

Docker’s own ecosystem tools include Swarm, Machine and Compose. “They’re near 1.0 versions,” said Cockroft. “Mesos announced Mesosphere 1.0. Amazon’s EC2 container service is becoming a solid product. You have Google’s container service coming out and [Docker coming on] Azure. So the public cloud services are moving from evaluation to production phase. HP, IBM, the people that support OpenStack, they are all rolling out containerized ways to do it. They’re just coming together. By the end of year, we should see them. People should be using Docker for test and dev all the way to deployment.”

Will the drawbacks of containers slow them down? Not likely. Yes, the container abstractions add some network overhead, but the productivity gains are worth it. Yes, security is an afterthought, but the industry will patch that. Yes, microservices are harder to herd, but Continuous Delivery demands them. Docker’s utility seems guaranteed to last.

Microservices: ‘SOA for hipsters’?
In all the excitement around containers, the question of what defines a microservice has an elusive answer. While a number of executives were hard-pressed to make a distinction between microservices and components, they may be reassured to know that even software architecture guru Martin Fowler notes in a 2014 paper entitled “Microservices,” “While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.” He goes on to describe microservices as suites of small services that communicate via lightweight mechanisms such as an HTTP resource API to comprise a single application.

But haven’t component-based development, and later service-oriented architectures, been software development’s goal for decades?

“I see it as next-level SOA, for sure—SOA for hipsters. Because it’s a useful way to architect things if you need it, but not necessarily a new, new badge,” said ActiveState’s Smithurst.

Fowler is optimistic about the new term, however. In the paper, he explains SOA’s spotty record: “When we’ve talked about microservices, a common question is whether this is just service oriented architecture that we saw a decade ago. There is merit to this point, because the microservices style is very similar to what some advocates of SOA have been in favor of.

“The problem, however, is that SOA means too many different things, and that most of the time that we come across something called ‘SOA,’ it’s significantly different to the style we’re describing here, usually due to a focus on ESBs used to integrate monolithic applications. In particular we have seen so many botched implementations of service orientation—from the tendency to hide complexity away in ESBs, to failed multi-year initiatives that cost millions and deliver no value, to centralized governance models that actively inhibit change, that it is sometimes difficult to see past these problems.”

As a result, Fowler writes, microservices might finally mean “service orientation done right.”

Five security tips for container-crazed coders
To avoid kernel exploits, denial of service attacks, cracked database passwords, poisoned images and more, these basics are a must (but by no means a complete security strategy):

  1. The usual rules of Internet hygiene apply: Verify image quality and provenance.
  2. Set boundaries: Containers are safest when segregated within VMs.
  3. Check your privilege: Don’t run containers with the “—” privilege flag, and drop privileges ASAP.
  4. Stay lean: Containers shouldn’t include anything the application doesn’t need to run.
  5. Protect the host: Run as non-root whenever possible.