What is a Docker Image? (And how do you use one with IronWorker?)

What is a Docker image?

Love them or hate them, containers have become part of the infrastructure running just about everything. From Kubernetes to Docker, almost everyone has their version of containers. The most commonly used is still Docker. IronWorker was among the very first to combine serverless management with containers. In this article we will give a high-level overview of what a Docker image is, and how IronWorker uses them.

So, What is a Docker image?

To start, we need to have an understanding of the Docker nomenclature and environment. There is still not a clear consensus on terms in regards to containers. What Docker calls one thing, Google calls another, and so on. We will only focus on Docker here. (for more on Docker vs Kubernetes, read here).

Docker has three main components that we should know about in relation to IronWorker:

  1. Docker file
  2. Docker image
  3. Docker container

1) Docker File

A Docker file is the set of instructions to create a Docker image.

Let’s keep it simple. Docker files are configuration files that “tell” Docker images what to install, update, etc. Basically the Docker file says what to build that will be the Docker image.

2) Docker Image

A Docker image is the set of processes outlined in the Docker file. It is helpful to think of these as templates created by the Docker files. These are arranged in layers automatically. Each layer is dependent on the layer below it. Each layer then becomes more abstracted than the layer below.

By abstracting the actual “instructions” (remember the Docker files?), an environment that can function with its resources isolated is created. While virtual machines relied on calling OS level resources, containers have eliminated this. In turn, this creates a lightweight and highly scalable system. IronWorker takes these images and begins the process of creating and orchestrating complete containers. What exactly is the difference between a Docker image and a Docker container? Let’s see.

3) Docker Containers

Finally we come to the containers. To simplify, we can say that when a Docker image is instantiated it becomes a container. By creating an instance that draws on system resources like memory, the container begins to carry out whatever processes are together within the container. While separate image layers may have different purposes, Docker containers are formed to carry out single, specific tasks. We can think of a bee vs. a beehive. Individual workers carry out asynchronous tasks to achieve a single goal. In short, containers are packages which hold all of the required dependencies to run an application.

After the container has been run, The Docker image is inert and inactive. This is because Docker image has carried out its purpose and now serves only as a meta reference.

IronWorker and Docker

So, you have your containers configured and everything is ready to go. What next? While Docker containers can function on their own, things like scaling workloads is much faster, more reliable, and easier with an orchestrator. IronWorker is one such container orchestrator, with some unique properties. 

An orchestrator adds another layer of abstraction to implementing and running containers. This has become known as “serverless” in recent years. While there is no such thing as a truly serverless, the term simply means there is no server management involved. By this point in the configuration, we have likely all but forgot about our original Docker image.

Forgetting about managing a server to react to spikes in traffic or other processing needs greatly simplifies a developer’s job. Tasks and other processes are scaled automatically. At the same time this allows for detailed analytics. Because the containers are managed by IronWorker, whether they are short lived or take days, the jobs are completed with minimal developer input after the initial setup.

What about migrating to other clouds or on-premise?

Traditionally, containers have been cloud based. As new options develop beyond just Amazon Web Services, the need to deploy flexible tools increases. Obviously devops changes frequently. Sometimes it even changes daily. One of the key benefits to IronWorker is that exporting your settings (as Docker images) and continuing on, either redundantly or in new iterations, in varying environments is the easiest in the marketplace. This includes deploying fully on-premise. This ability to maintain freedom from vendor lock-in and future needs is what separates IronWorker from the rest.

Start IronWorker now with a free 14 day trial here.

Introducing: Computerless™

Iron was one of the pioneers of Serverless, so we’re excited to announce that we’ll also be one of the first companies to offer the next generation of compute:  It’s called Computerless™.

Unlike Serverless, this technology removes the physical machine completely.  Our offering piggy-backs off the recent developments in fiber optic technology developed at the University of Oxford.  If you haven’t heard about this breakthrough, we’ll do our best to explain:

Researchers have found a way to control how light travels at the molecular level, thus being in complete control of the resulting attenuation.  Molecular gates can then be created, and state stored in finite wavelengths. It’s somewhat equivalent to qubits in quantum computing, but in the case of optical fiber, it’s a physical reality.

The end result of this technological release allows for computers to be fully encapsulated in fiber optic cable.  The usual components needed are now mapped 1-to-1, via light. This has allowed Iron’s infrastructure to completely change.  While we’ve run our infrastructure on public clouds like AWS and GCP in the past, we’ve been able to leave that all behind. We’re now able to push our entire suite of products into optical cable itself:


Iron’s new and improved infrastructure on a cheap plot of land in Arkansas

In the next few months, we’ll be pushing all of our customer’s sensitive data into the cables shown above as well as running all Worker jobs through them.  We’re pretty sure the cables we purchased are for multi-tenant applications, so you can probably rest assured that we’re doing the right thing. In fact, NASA has already expressed an interest in licensing this technology from Iron. Other interested parties include the government of French Guiana and defense conglomerate Stark Industries. 

Researchers have kind-of concluded that this technology is ready for prime time, and also are quick to state the fact that in 1998, The Undertaker threw Mankind off Hell In A Cell, and plummeted 16 ft through an announcer’s table.

Hybrid Iron.io – On-Premise Job Processing with the Help of the Cloud

Hybrid_IronioHybridOne of our main goals for the Iron.io platform is run anywhere. This means we enable customers to use our services on any cloud, public or private. With Hybrid Iron.io, we’re making it drop dead simple to get the benefits of the public cloud, with the security and control of a private cloud. 

Using Iron.io’s public cloud service is easy, you just sign up and start using it. No servers to deal with, no setup and no maintenance. You can be up and running with a very powerful technology in a matter of minutes. It’s a beautiful thing. Continue reading “Hybrid Iron.io – On-Premise Job Processing with the Help of the Cloud”

Massive Content, Validation & Serverless: Cloud Expo 2016 Recap

Cloud Expo Banner

The Cloud Expo was held June 7-9, 2016 in New York City, and Iron.io sent a team to present our vision for the future, collaborate with other attendees and answer questions. Below is a summary of three technical sessions representative of the Containers track at the conference:

Continue reading “Massive Content, Validation & Serverless: Cloud Expo 2016 Recap”

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”

SAP TV Asks Iron.io to Explain Microservices

SAP TV

Recently, SAP TV asked Iron.io CEO and Co-founder Chad Arimura to explain mircoservices in 60 seconds. It was great to have Chad included in SAP’s “Meet the Innovators” series. We’re sharing the video with you here, not only because it is a concise explanation of microservices, but it’s clear from hearing Chad speak why all of us at Iron.io are so excited about a future with teams of developers using microservices.

Enjoy the video!

Get a Job, Container: A Serverless Workflow with Iron.io

This post originally appeared on DZone

My previous post, Distinguished Microservices: It’s in the Behavior, made a comparison between two types of microservices – real-time requests (“app-centric”) and background processes (“job-centric”). As a follow up, I wanted to take a deeper look at job-centric microservices as they set the stage for a new development paradigm — serverless computing.

Of course, this doesn’t mean we’re getting rid of the data center in any form or fashion — it simply means that we’re entering a world where developers never have to think about provisioning or managing infrastructure resources to power workloads at any scale. This is done by decoupling backend jobs as independent microservices that run through an automated workflow when a predetermined event occurs. For the developer, it’s a serverless experience.

Continue reading “Get a Job, Container: A Serverless Workflow with Iron.io”

Distinguished Microservices: It’s in the Behavior

This post originally appeared on DZone

Microservices is more than just an academic topic. It was born out of the challenges from running distributed applications at scale; enabled by recent advancements in cloud native technologies. What started as a hot topic between developers, operators, and architects alike, is now catching on within the enterprise because of what the shift in culture promises — the ability to deliver software quickly, effectively, and continuously. In today’s fast-paced and ever-changing landscape, that is more than just desirable; it’s required to stay competitive.

Culture shifts alone are not enough to make a real impact, so organizations embarking down this path must also examine what it actually means for the inner workings of their processes and systems. Dealing with immutable infrastructure and composable services at scale means investing in operational changes. While containers and their surrounding tools provide the building blocks through an independent, portable, and consistent workflow and runtime, there’s more to it than simply “build, ship, run.”

Continue reading “Distinguished Microservices: It’s in the Behavior”

The Next Frontier: Learning Microservices in the Classroom

working

As a Customer Success engineer here at Iron.io, I’ve been fortunate enough to see people using Iron.io in ways I never thought about. It’s actually one of my favorite parts of my job.

Recently, I was chatting with a customer who mentioned his students were using Iron.io in their final project. This peeked my interest, so I interviewed Soumya Ray, an associate professor at National Tsing Hua University in Taiwan, about his experience. Professor Ray’s  Service Oriented Architecture class is an 18 week course that takes students from idea creation to final product. And, as a cherry on top, the class has students create the building blocks of their own startup with zero dollars spent. Continue reading “The Next Frontier: Learning Microservices in the Classroom”