I am incredibly excited to be joining such a talented, diverse group at Rancher Labs as Vice President of Business Development. In this role, I’ll be building upon my experience of developing foundational and strategic relationships based on open source technology. This change is motivated by my desire to go back to my roots, working with small, promising companies with passionate teams.
I joined Docker, Inc. in 2013, just as it started to bring containers out of the shadows and empower developers to write software with the tools of their choice, while redefining their relationship with infrastructure. Now that Docker is available in every cloud environment, embedded in developer tools, and integrated in development pipelines, the focus has shifted to making it more efficient and sustainable for business. Read more
Each time a new software technology arrives on the scene, InfoSec teams can get a little anxious. And why shouldn’t they? Their job is to assess and mitigate risk – and new software introduces unknown variables that equate to additional risk for the enterprise. It’s a tough job to make judgments about new, evolving, and complex technologies; that these teams approach unknown, new technologies with skepticism should be appreciated.
This article is an appeal to the InfoSec people of the world to be optimistic when it comes to containers, as containers come with some inherent security advantages:
Containers may be super cool, but at the end of the day, they’re just another kind of infrastructure. A seasoned developer is probably already familiar with several other kinds of infrastructure and approaches to deploying applications. Another is not really that big of a deal.
However, when the infrastructure creates new possibilities with the way an application is architected—as containers do—that’s a huge deal. That is why the services in a microservice application are far more important than the containerized infrastructure they run on.
Modularity has always been a goal of application architectures, and now that the concept of microservices is possible, how you build those services end up dictating where they run and how they are deployed. Services are where application functionality meets the user, and where the value your application can provide is realized.
That’s why if you want to make the most of containers, you should be thinking about more than just containers. You have to focus on services, because they’re the really cool thing that containers enable.
Services v. Containers
For conversation’s sake, using services and containers interchangeably is fine—because the ideal use case for a containerized application is one that is deconstructed into services, where each service is deployed as a container (or containers).
However, the tactics cannot be synonymous. Services are an implied infrastructure, but more importantly, an application architecture. When you talk about a service that is part of your application, that service is persistent. You can’t suddenly have an application without a login page or a shopping cart, for example, and expect things to go well.
Containers, on the other hand, are designed to live and die in very short time frames. Ideally, with every deployment or revert, the container is killed as soon as the new deployment is live and the traffic is routed to it. So containers are not persistent. And if the delivery chain is working correctly, that should not matter at all.
Microservices, as both an application and an infrastructure term, does have some unique elements associated with it, which diverge the relationship even further. Read more
Since Docker launched in 2013, it has brought a level of excitement and innovation to software development that’s contagious. It has rallied support from every corner—enterprises to startups, developers to IT folk, plus the open source community, ISVs, the biggest public cloud vendors, and every tool across the software stack. Since the launch of Docker, many major milestones have served to advance the container revolution. Let’s look at some of them.
Container Orchestration Options
Getting started with your first container is fairly simple. All it takes is your laptop and a Docker client. However, running a microservices app is a whole other beast. The most difficult part is in creating, managing, and automating clusters of ephemeral containers.
The first major tool to address this challenge was Mesos with its Marathon orchestrator. Having powered distributed infrastructure even before Docker, Marathon is in use in production workloads at Twitter, and in other large-scale web applications.
The next orchestration tool to gain prominence was Kubernetes. In fact, today, Kubernetes leads the pack of Docker orchestration tools because of how extensible it is. It supports a broad list of programming languages, infrastructure options, and enjoys tremendous support from the container ecosystem. It isolates the application layer from the infrastructure layer, thus enabling true portability across multiple cloud vendors, and infrastructure setups. Read more
For anyone working in IT, the excitement around containers has been hard to miss. According to RightScale, enterprise deployments of Docker over doubled in 2016 with 29% of organizations using the software versus just 14% in 2015 . Even more impressive, fully 67% of organizations surveyed are either using Docker or plan to adopt it. While many of these efforts are early stage, separate research shows that over two thirds of organizations who try Docker report that it meets or exceeds expectations , and the average Docker deployment quintuples in size in just nine months. Clearly, Docker is here to stay. Read more
This week, the Moby Project was introduced with the idea of componentizing Docker into a series of assemblies. At DockerCon, a neat demo was done using the moby tool to assemble various components into customized Linux operating system images. While very cool, this seemed to have confused people – we’d like to provide some more background and explanation about the Moby Project and how it affects Rancher, RancherOS, and our users.
Some background on the Moby Project
The transition to the Moby Project actually started a couple of months ago, with a discussion among the Docker Project maintainers, about the dual nature of Docker as both a product and a project. This dual nature served Docker (the project and the company) well in the beginning, but at the end of the day, Docker, Inc. must make hard decisions about what their product should and will be. As a group of maintainers, we agreed that the product and project should be split. Read more