Green on Red - Discovering Energy Efficient Containers with Tide on Appsody

TL;DR; Tide Appsody Stack Code

Introduction

Recently I have been working with Appsody an open source development and operations accelerator for containers.

Appsody is targeting a classic problem in software adoption.

How do organisations leverage new technology while keeping a reasonable set of guard rails in place?

In short appsody allows you to create predefined and configured software stacks to enable teams of developers to create, run, build and deploy production ready cloud native apps in an incredibly short space of time when compared to normal app life cycles.

appsody

So I thought I would take appsody and mix it up with another topic that I am intrested in - simple but high preformance webserver development. This led me to work on an appsody stack for the async Rust HTTP framework Tide.

The instructions for using the Tide stack are in the README and I'll be diving into more in later posts but today I got a baseline Tide implementation up and running on the recently announced RedHat OpenShift 4.3 Kubernetes Service (ROKS) on IBM Cloud.

OpenShift

Working with appsody is nice and simple so I also spun up the node.js express stack and the spring boot stack stack to compare developer flows.

Both runtimes went very smoothly from zero to deploy in minutes but as I investigated the deployments I was struck that the resource consumption between the more established frameworks and Rust-Tide in an idle state.

Example Pod Overview

chart

The consumption metrics charts and the new OpenShift 4.3 UI are in the (ScreenShots Below) but I have summarised them in this table.

RuntimeMemCPUProcesses/CPU
Java Spring Boot~87Mb~20m50
Node.JS Express~47Mb~10100
Rust Tide~1Mb~1m1000

This comparison would suggest that Rust is an order of magnitude more efficient than Node.js or Java.

It's not surprising Rust is more efficient as it's natively compiled.

But I hadn't considered that there would be such a difference given that none of the applications were performing work.

As there may be a "slight lack of rigour" in the data and methodology above I went to surf the net to see if there has been any formal research into the area of green applications.

I was delighted to discover a group called the Green Software Lab who do a lot of work in this area. Specifically they published a paper that considers this topic.

The Normalized Global Results:

results are interesting

The results are interesting with Rust closely following C in terms of energy efficiency and Java placing respectably too. It is should also be noted that python one of the worlds most popular runtimes places very poorly.

Reflecting more on the results I noted that Javascript placed lower than Java. This likely due to the tests being based on CPU intensive tasks and not on I/O tasks that Javascript is perhaps better suited for.

As a practioner who also cares about energy efficiency it would be useful to see this type of analysis performed against end to end workloads such as those available on realworld.io.

Green applications are a new topic for me but I am going to continue reading up and will checkin with any findings.

Screen Shots

java java

node.js node.js

rust rust