Blue Cloud Mirror is an online game based on multiple IBM Cloud technologies. It has two levels, in level one you need to show five facial expressions like happy, angry, etc. In level two you need to show five body positions. Have a look at it and play it here.

I created the game together with my colleagues Niklas Heidloff and Thomas Südbröcker. Niklas desribed many aspects of it in his blog, starting here.

Basically, Blue Cloud Mirror has three parts:

1. Game, can be played anonymously or as a registered user
2. Scores Service keeps the highscore list for registered users
3. Users Service keeps the user data of the registration

My part of this project is the Users Service. It does not run in the Cloud for several reasons:

• Users may not be comfortable with having their data stored on the Cloud.
• We wanted to deploy part of our microservices on Kubernetes, for example on IBM Cloud Private.
• We wanted to show how easy it is to securely connect a local backend with an application on the Cloud. Instead of the Users Service the connection could be to any application running on-premise.

I really started to develop on a IBM Cloud Private but since we wanted as many people as possible to use our game I decided to switch to a local instance of Minikube because it is simple, has a small footprint, and if you like you can carry it around on your notebook.

You can find our code in the IBM directory of Github at https://github.com/IBM/blue-cloud-mirror and you will find the User Service in the users directory of the repository.

I will describe the Users Service in follow on blogs. Stay tuned!

Last Thursday night was the Stuttgart Kubernetes Meetup, hosted by CGI in Echterdingen (thanks!!!). I got the chance to talk about “Project Eirini”.

There is Kubernetes and there is Cloud Foundry. Both are Cloud PaaS platforms, both offer container orchestration and scheduling, and both are available on the IBM Cloud. While Kubernetes is all about container orchestration, Cloud Foundry is a developer experience where the concept of containers is pretty much hidden from the developer. Both have their strengths and weaknesses: You can do almost anything with Kubernetes but it has a steep learning curve, as a developer you have to know a lot about orchestration. Cloud Foundry is limited to stateless or 12-factor apps but as a developer you only focus on your code, Cloud Foundry takes care of the rest.

A while ago, SuSE started a project in the Cloud Foundry Incubator called “Cloud Foundry (CF) Containerization”. It converts the VMs running CF Management or backplane functions into containers and deploys them on Kubernetes. It uses a component called “fissile” to do that. There is a Github repo for this. This has been around for a while and works quite well. IBM uses this technology for “Cloud Foundry Enterprise Edition” to run a Cloud Foundry for one customer on top of a Kubernetes cluster.

Cloud Foundry has a container orchestration component called “Diego”, Kubernetes is a container orchestrator. With the CF Containerization approach, Diego cells — the equivalent to Kubernetes worker nodes — are deployed as Pods. That way, Cloud Foundry apps run as containers within containers (nested). They are not visible to Kubernetes. If you deploy Kubernetes apps via kubectl into the Kubernetes cluster that hosts Cloud Foundry Containerization, those apps are not visible to Diego. Diego and Kubernetes then work against each other instead of together. This is where Project Eirini starts.

Eirini is the greek goddess of peace 🙂

Eirini replaces Diego with Kubernetes (actually it gives you a choice between the two). When you deploy an application to Cloud Foundry (native), Diego uses a buildpack — a runtime that matches the programming language of the application — and combines it with the application code and dependencies to form what is called a “droplet”. The droplet is then placed into an empty container end executed, this forms the running application.

Eirini uses a mechanism published by buildpacks.io, it creates a container image instead of a droplet, plus it creates a helm chart, and deploys the application as stateful set directly into Kubernetes. The application is visible in Kubernetes and the Kubernetes cluster can be used to run other Kubernetes native applications as well.

This is the Eirini repository on Github, it contains information on how to run CF Containerization and Eirini together. In December 2018, Eirini has passed the Cloud Foundry Acceptance tests and should be production ready in a while.