This article is not an attempt to explain containers in one go. Instead, it's a front-page for my multi-year study of the domain. It outlines the said learning path and then walks you through it, pointing to more in-depth write-ups on this same blog.

Mastering containers is no simple task, so take your time, and don't skip the hands-on parts!

But it turns out that Firecracker is relatively straightforward to use (or at least as straightforward as anything else that's for running VMs), the documentation and examples are pretty clear, you definitely don't need to be a cloud provider to use it, and as advertised, it starts VMs really fast!

So I wanted to write about using Firecracker from a more DIY "I just want to run some VMs" perspective.

I'll start out by talking about what I'm using it for, and then I'll explain a few things I learned about it along the way.

I don’t know about you, but I’ve always been uncomfortable with Jenkins’ apparent statefulness. You set up your Jenkins server, configure it exactly as you want it, then DON’T TOUCH IT.

Fortunately I now have a solution. With a combination of Docker, Python’s Jenkins API modules, the Jenkins job builder Python module, and some orchestration using docker-compose, I can reproduce my Jenkins state at will from code and run it in isolated environments, improving in iterable, track-able steps.

Mist.io helps you manage and monitor your virtual machines, across different clouds, using any device that can access the web.

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.

Otto is the successor to Vagrant.

...

Otto knows how to develop and deploy any application on any cloud platform, all controlled with a single consistent workflow to maximize the productivity of you and your team.

My goal in this guide is both to answer these questions, and, more importantly, provide an overall framework you can use to think about how to answer these questions.

Having gone through all the pain of polishing an OpenStack installation, I can see why it might seem like a better idea to grab a couple of beers in a local bar than spend additional hours fighting Nagios or Cacti. In the world of bare metal these tools seem to do the job—they warn about abnormal activities and provide insight into trend graphs.

With the advent of the cloud, however, proper monitoring has started getting out of hand for many IT teams. On top of the relatively predictable hardware, a complicated pile of software called “cloud middleware” has been dropped in our laps. Huge numbers of virtual resources (VMs, networks, storage) are coming and going at a rapid pace, causing unpredictable workload peaks.

Proper methods of dealing with this mess are in their infancy – and could even be worth launching a startup company around. This post is an attempt to shed some light on the various aspects of cloud monitoring, from the hardware to the user’s cloud ecosystem.

OpenDaylight is an open platform for network programmability to enable SDN and NFV for networks at any size and scale. The community’s second release “Helium” comes with a new user interface and a much simpler and customizable installation process thanks to the use of the Apache Karaf container.

...

OpenDaylight software is a combination of components including a fully pluggable controller, interfaces, protocol plug-ins and applications. With this common platform both customers and vendors can innovate and collaborate in order to commercialize SDN- and NFV-based solutions.

Open Platform for NFV (OPNFV) is a new open source project focused on accelerating the evolution of Network Functions Virtualization (NFV). OPNFV will establish a carrier-grade, integrated, open source reference platform that industry peers will build together to advance the evolution of NFV and to ensure consistency, performance and interoperability among multiple open source components. Because multiple open source NFV building blocks already exist, OPNFV will work with upstream projects to coordinate continuous integration and testing while filling development gaps.