Docker, Inc isn’t Dead

Chris Short recently wrote up a piece entitled Docker, Inc is Dead, with a prediction that the company would no longer exist sometime in 2018.  It’s well written and he does a good job of running through some of Docker’s history in recent years.  Although I agree with some of his sentiments, I don’t think Docker, Inc will exit the stage anytime soon.  Here are some reasons I think Docker, Inc will live a healthy life in 2018.

Docker is Good Software

This was the first point in Chris’ piece, and he’s right.  Docker definitely helped widen the spotlight on *n?x kernels.  Discussions around namespaces, cgroups, lxc, zones, jails, etc… lit up across communities in different disciplines.  Dockers’ simple interface lowered the barrier of entry for non-administrators, and the developer community immediately added it to their workflows.  Docker released EE/UCP, and larger organizations jumped on board.  It “is” good software for developers, SMB’s, and large organizations, and Docker, Inc isn’t slowing down development efforts.

DOCKER HAS FRIENDS

“I’m really excited to welcome Solomon and Docker to the Kubernetes community”.  Brendan Burns (of Microsoft, Lead Engineer of Kubernetes) definitely made me do a double take when he said that on stage at DockerCon EU a few months ago.  Many people I spoke to at the conference referenced that statement and saw this as a big blow to Docker.  “Who’s joining who’s community? ”  The thing is, the real purpose of Brendan’s talk was about the collaboration between companies, and the effort to make our lives as developers and administrators better.  The whole “it takes a village to raise a child” saying.  This village is composed of some of the brightest engineers from many of the world’s largest companies, and they’re all striving to make things better.  Docker and Kubernetes worked together, and the Kubernetes integration into UCP made perfect sense.

Docker has business

They don’t have a lack of coherent leadership.  They’ve received a ton of money, their marketing is great, and they’re acting like what they are;  a rapidly growing company moving into the enterprise market.  Were some of their keynotes awkward at DockerCon EU this year?  Yes.  Were there fantastic sessions from customers who shared real-life Docker success stories?  Yes.  Have they made some mistakes here and there?  Yes.  Have they moved past those and grown?  Yes.  If you’ve been around the block and watched small companies rapidly grow into behemoths, this is all typical.  Growing isn’t easy.  Their “Modernizing Enterprise Applications” mantra is perfect.  There are countless technical budgets from Fortune 10,000 companies that Docker, Inc will capitalize on.  The best part is that they’ll actually be making a positive difference.  They are not snake-oil salesmen.  These companies will probably see real ROI in their engagements.

Conclusion

Docker, Inc isn’t going to be acquired (yet) or close their doors.  There is a lot going on at Docker, Inc right now but they aren’t signs of a company that is getting ready for a sale.

It’s a company that’s based on OSS with a lot of opportunity in the market.  While one of the products at Iron is Docker-based, we use a wide variety of software from many companies with roots in OSS.  We’re happy to pay for a higher level of support and features for OSS software backed by a business.  For other projects, we often donate through Open Collective to help maintainers and small development teams.  Docker’s donation of containerd was a great move and I think it is a project that fits perfectly into CNCF’s charter.

While Docker, Inc is moving upstream, they haven’t at all abandoned its real users;  developers.   We use Docker daily, contribute back when we can, and are optimistic about its trajectory as a business and a product.  Docker, Inc has a lot of room to grow, and in 2018, it will.

* These fields are required.


The Overhead of Docker Run

First published on Medium on 10/11/2016.

We use Docker a lot. Like a lot, lot. While we love it for a lot of things, it still has a lot of room for improvement. One of those areas that could use improvement is the startup/teardown time of running a container.

The Test

To test the overhead of running a Docker container, I made a script that compares execution times for various docker run options vs not using Docker at all. The script that I’m running is a simple hello world shell script that consists of the following:

echo "Hello World!"

The base Docker image is the official Alpine linux image plus the script above.

4 Things to Compare

  1. As a baseline, the first measurement is sans Docker. This is just running the hello.sh script directly.
  2. The second measure is just docker run IMAGE.
  3. The third measure adds the “rm” flag to remove the container after execution.
  4. The final one is to use docker start instead of run, so we can see the effect of reusing an already created container.

Docker for Mac

Server Version: 1.12.2-rc1

Running: ./hello.sh
avg: 5.897752ms
Running: docker run treeder/hello:sh
avg: 988.098391ms
Running: docker run — rm treeder/hello:sh
avg: 999.637832ms
Running: docker start -a reuse
avg: 986.875089ms

(Note: looks like using Ubuntu as a base image is slightly faster than Alpine, in the 10–50ms range).

Docker on Ubuntu

Server Version: 1.12.1

Running: ./hello.sh
avg: 2.139666ms
Running: docker run treeder/hello:sh
avg: 391.171656ms
Running: docker run — rm treeder/hello:sh
avg: 396.385453ms
Running: docker start -a reuse
each: 340.793602ms

Results

As you can see from the results above, using Docker adds nearly a full second to the execution time of our script on Mac and ~390ms on Linux (~175x slower than running the script without Docker).

Now this may not be much of an issue if your script/application runs for a long period of time, but it is certainly an issue if you run short lived programs.

Try it yourself

Feel free to try running the script on your system and share the results! You can find everything you need here:https://github.com/treeder/dockers/tree/master/hello

Just clone that repo, cd into the hello directory and run:

go run time.go

Buzzwords: Microservices, Containers and Serverless at Goto Chicago

Goto Chicago Dave Speaking

It was an honor to give a talk on the future of Serverless at goto Chicago, an enterprise developer conference running from May 24 to 25, 2016. As you can see from the full room, containers, microservices and serverless are popular topics with developers, and this interest extends across a wide swath of back-end languages, from Java to Ruby to node.js. Unfortunately, the talk was not recorded, so I’m providing these notes (and my slide deck) for those who could not attend.

The Evolution of Deployed Applications

Before we look forward into the future of Serverless, let’s look back. We’ve seen a historical evolution in deployed applications at multiple different levels. Whereas before the unit of scale was measured by how many servers you could deploy, we’ve moved through rolling out virtual machines to the current pattern of scaling our containerized infrastructure. Similarly, we’ve seen a shift from monolithic architectures deployed through major releases to containerized, continuously-updated microservices. This paradigm is Iron.io’s “sweet spot,” and we’re leading the enterprise towards a serverless computing world.

Continue reading “Buzzwords: Microservices, Containers and Serverless at Goto Chicago”

Gartner Names Iron.io on 2016 “Cool Vendor” List

vTime_Gartner_160512_150155

Here’s some cool news. Iron.io was recently named a “Cool Vendor” in the Cool Vendors in Platform as a Service, 2016[1] report by Gartner. The report puts Iron.io on an extremely short list with just three other vendors in the space: Clusterpoint in London, England; Flybits in Toronto, Canada; and Neoway out of Florianopolis, Brazil.

The Cool Vendors research by Gartner is designed to help CIOs and other top IT leaders stay ahead of the IT technology curve. It also helps them make better strategic decisions about technology and services. “The vendors in this report offer new platform opportunities for business and IT, in response to increasing demand for intelligent business operations with cloud levels of scale, agility and responsiveness,” the report states. Continue reading “Gartner Names Iron.io on 2016 “Cool Vendor” List”

Microcontainers, and Logging in Docker: Iron.io CTO speaks at Docker NYC

microcontainers-banner

Travis Reeder, the co-founder and CTO of Iron.io, spoke at last night’s Docker NYC meetup about Microcontainers. In addition, Hermann Hesse of Sumo Logic spoke about Logging in Docker.

Slack for iOS Upload

Iron.io is a big proponent of microcontainers, which are minimalistic docker containers that can still process full-fledged jobs. We’ve seen microcontainers gaining traction amongst software architects and developers because their minimalistic size makes them easy to download and distribute via a docker registry. Microcontainers are easier to secure due to the small amount of code, libraries and dependencies, which reduces the attack surface and makes the OS base more secure. Continue reading “Microcontainers, and Logging in Docker: Iron.io CTO speaks at Docker NYC”

GoSF: The 1.6 Release Party at Docker HQ

Go 1.6 Launch Party

Lightning, thunder, and even hail swept through SF yesterday. But, that didn’t deter hundreds from hustling to Docker’s HQ for the Go 1.6 release party! GoSF received over 470 signups, a nice sum for a relatively young language.

Yesterday’s launch party boasted trivia, stuffed gopher giveaways, and a limited run T-shirt from Iron.io’s Bruce Lu. Oh, and as always there were some great talks.

Video of the talks will also be online soon! For the impatient, we’ve also included summaries and slides of last night’s talks below. Continue reading “GoSF: The 1.6 Release Party at Docker HQ”

Microcontainers – Tiny, Portable Docker Containers

microwhale-vs-bigwhale

Docker enables you to package up your application along with all of the application’s dependencies into a nice self-contained image. You can then use use that image to run your application in containers. The problem is you usually package up a lot more than what you need so you end up with a huge image and therefore huge containers. Most people who start using Docker will use Docker’s official repositories for their language of choice, but unfortunately if you use them, you’ll end up with images the size of the empire state building when you could be building images the size of a bird house. You simply don’t need all of the cruft that comes along with those images. If you build a Node image for your application using the official Node image, it will be a minimum of 643 MB because that’s the size of the official Node image.

I created a simple Hello World Node app and built it on top of the official Node image and it weighs in at 644MB.

That’s huge! My app is less than 1 MB with dependencies and the Node.js runtime is ~20MB, what’s taking up the other ~620 MB?? We must be able to do better.

What is a Microcontainer?

A Microcontainer contains only the OS libraries and language dependencies required to run an application and the application itself. Nothing more.

Rather than starting with everything but the kitchen sink, start with the bare minimum and add dependencies on an as needed basis.

Taking the exact same Node app above, using a really small base image and installing just the essentials, namely Node.js and its dependencies, it comes out to 29MB. A full 22 times smaller!

 

pasted_image_at_2016_01_22_11_20_am
Regular Image vs MicroImage

 

Try running both of those yourself right now if you’d like, docker run –rm -p 8080:8080 treeder/tiny-node:fat, then docker run –rm -p 8080:8080 treeder/tiny-node:latest. Exact same app, vastly different sizes.

Continue reading “Microcontainers – Tiny, Portable Docker Containers”

Introducing Custom Docker Images, Private Docker Repositories and Environment Variables

customcontainer

We’re happy to announce three awesome new IronWorker features:

  • Custom Docker Images for all and Docker is now the default code packaging mechanism
  • Support for private Docker images on any Docker Registry, including Docker Hub
  • Support for custom environment variables

I’ll explain each of these features in more detail below.

Custom Docker Images for All!

Previously only available to customers on dedicated plans, this is now available to everyone! You can create custom Docker images and run them at scale on the Iron.io Platform. And as usual, you don’t need to think about servers or scaling or managing anything, you just queue up jobs/tasks. Jobs are executed using your Docker image + a message/payload that defines that job. 

To read how to make your own Docker Worker using the language of your choice, please see our Docker Worker GitHub repository for full documentation for most languages. 

There is a size limit to custom images on our small/free plans of 200MB so you’ll definitely want to use our iron/x base images that we use in our examples to keep them small. If you need bigger images, you can upgrade your account. 

Once you’ve pushed your image to Docker Hub, simply let Iron.io know about it:

Then you can start queuing up jobs for it.

You can see the full API here and client libraries for the language of your choice here.

Private Docker Repositories

Not only can you use your own custom images, you can store those images privately and still use them on IronWorker. Obviously you don’t want other people to access your code inside your image or any type of config files you might have put in the image (although we recommend using environment variables for that, see next section) so you can use a private Docker repository to keep it private.  

To use your private images on Iron.io, you need to login like you do with Docker:

Then just do everything else like normal.

Environment Variables

Instead of uploading a config file as json, we’ve added support for custom environment variables that will be passed into your Docker container at runtime. This allows you to set options that you don’t want to include in your Docker image, such as database credentials or variables that might change based on the environment (development vs production for instance). 

These are set by using -e flags on iron register, for example:

That’s it for Now

These new features give you full capability to use Docker to it’s full potential. Now that this is in place, there’s a lot of exciting new things to come that will build on this.

How To Build Your Own Docker Images

Build Your Own Docker Images

Thanks to Ugur Ceylan for the base image! CC BY 2.0

What’s with the Docker community’s love affair with Alpine Linux? Tiny containers means more compute resources left over for actual… computing! Alpine Linux is particularly tiny. It says so, right on the tin: “Alpine Linux is a security-oriented, lightweight Linux distribution based.”

Do you like saving money? I like saving money. Better resource utilization means happy bank accounts.

Let’s take a closer look at Alpine Linux on Docker. Heck, while we’re at it let’s build our own image.

Continue reading “How To Build Your Own Docker Images”

Running IronWorker on Docker + Node.js + Windows

docker-nodejs-windows

Exosphere champions best of breed cloud applications. In their own words, “We’ve set out on a mission, a quest if you will, to gather together the best small to medium applications in each class, and try to bolt them together in such a way that combined they form a powerful, user-friendly, complete core small business package.”

For the gnarly job of data synchronization exosphere found few options. Solutions for piping core application data certainly exist, but most vendors lock you down like lawn furniture.  Exosphere found IronWorker appealing, since it saved them the hassle of building their own out of the box solution.

Exosphere is built on a Node.js + Windows development stack. Today, they’ve agreed to let us share their recent post on getting IronWorker + Windows + Node.js humming in unison.

If you’re curious what twists and tweaks are required to get IronWorker going on Windows, read on!

Continue reading “Running IronWorker on Docker + Node.js + Windows”