Blue Cloud Mirror Architecture Diagrams
Blue Cloud Mirror Architecture Diagrams
For the visual learners, take a look at these diagrams of the serverless technologies behind the user and score's services in the Blue Cloud Mirror game.
Join the DZone community and get the full member experience.
Join For FreeLearn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Blue Cloud Mirror is a game where players need to show specific emotions and do specific poses. In this article, I describe briefly the technologies used.
You can play the game online. All you need is a webcam and a Chrome browser.
The game uses key technologies of the IBM Cloud and has three main parts:
- Core game: Implemented as a serverless web application since it is primarily used during conferences only
- User's service: Implemented via IBM Cloud Private to avoid storing the personal data in a public cloud
- Score's service: Implemented via Cloud Foundry Enterprise Edition to highlight easy changes via the "cf push experience" (for example, theme adoptions for different conferences).
Thomas, Harald and I have planned to write more articles about the different parts of the application. This article gives a high-level overview.
The first diagram gives an overview of the key components.
Note that there are two different versions per diagram. One version describes what we use in the GitHub project. That version uses Minikube for the user's service and Cloud Foundry Public Applications for the score's service so that even IBM Cloud users with a free Lite account can run it. The other version uses the enterprise technologies IBM Cloud Private and Cloud Foundry Enterprise Environment.
The next diagrams add more details about the three main parts.
The core game is a serverless application hosted on the IBM Cloud via Cloud Object Storage and IBM Cloud Functions. The users, scores, and Twitter APIs are invoked via Lite API Management. With Lite API Management and App ID user authentication and authorization can be implemented.
The score's service has been implemented via the Cloud Foundry Node.js buildpack. A second buildpack is used to host the web resources of the web application which displays the highscore list.
The user's service has been implemented via Node.js running in Kubernetes. The data is stored in Apache CouchDB. The service can be invoked from the public cloud via Secure Gateway.
Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.
Like This Article? Read More From DZone
Published at DZone with permission of Niklas Heidloff , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}