The Cloud Game - Design Time

Like that diet or healthy lifestyle you've been meaning to start, you know that you need to build Cloud skills. Studying the game or watching others play will get you to a point. In this series, I will guide you through building Cloud solutions simply to address real-world problems.

The Cloud Game - Design Time

Subscribe to get my newsletter and updates of new posts. Also, feel free to connect with me via email (rennay@rennay.dev), Twitter or LinkedIn.

The mission statement behind this series of articles is to get more hands on experience with Cloud Application development.  In my kickoff article - Get into the Cloud Game, I identified a use-case for an application which my family and I could use to keep track of badminton games.  The key problem statement items are listed below:

  • Scoring
  • History
  • Analysis

You may recall that the approach I outlined has the steps illustrated in the figure below.  Having covered the Background and Problem Statement, I will zero in on the the Requirements and Solution Design phase in this article.

Requirements

From examination of the Problem Statement, I have extracted the following key requirements which the application should satisfy - at least for a Minimum Viable Product:

  • Digital Scoring: scores should be captured and accessible electronically and importantly in an “open and accessible” format. If you recall, our current mechanism of sharing updates is via WhatsApp - which is “technically” digital - but is trapped within the application.
  • Remote Viewing: the score should be available for one or more remote viewers as near real-time as possible. It should be accessible via a desktop/mobile interface, preferably mobile.
  • Point Tracking: the application should provide as much insight into the game as possible and each point must be recorded. This is to encourage my wife to provide as comprehensive coverage as I do.
  • Game Analysis: the application should record point winners and unforced errors. Specific details of the win/error would be great (for example: smash, out of bounds) but is not required for the MVP.

Design

High-Level Design

Architecting pragmatically and simply, I have identified the key elements of the solution, listed and illustrated below. There are most likely experienced Solution Architects/Designers out there who are chortling in dismay. In my defense, I would contend that these components are the “atomic” building blocks of the solution.

Elements:

  • Database
  • Writer (Scorer)
  • Reader (Viewer)

Solution Design - Iteration 0

As much as it pains me to admit, the simplest “Cloud” based solution to remedy this problem would be a Google Sheet. Think about it. It satisfies every requirement -

  • Digital scoring: The data is captured on a spreadsheet, which is in an open, accessible format.
  • Remote viewing: Google docs allows multiple collaborators to work on a single document.
  • Point tracking: Data in the sheet can be formatted to indicate winners/errors.
  • Game analysis: Given that we’re in a spreadsheet, the data can be sliced/diced accordingly.

I was able to set up this spreadsheet in a few minutes. I have also highlighted key parts of the document - i) last edit, ii) view mode and iii) multiple collaborators.

You might be wondering why I have proposed this solution. My intention is to highlight that solution design need not be complex. From my experience, I have observed that it is often more difficult to show restraint and go with a simpler solution. Architects and solution designers often spend a significant amount of time and energy postulating over grand interfaces and designs to allow maximum extensibility and easy adoption by new consumers - to the point of analysis-paralysis.

A good friend of mine coined a great anecdote for a perfectly curated data model from a large enterprise customer he worked with. He jokingly remarked that it was so extensible that if aliens landed in the year 3000, they would have no trouble consuming it.

Start simple, then build on your solution.

Solution Design - Iteration 1

You might be wondering why we’re still here after solving the requirement with Google Sheets. As you will recall from the previous article, the objective was to build a Cloud solution to get hands on experience. With that being said, allow me to present the next iteration of the Solution Design for a custom web application -

Fans of Amazon Web Services (AWS) have most likely navigated to another YouTube video of Jeff Bezos talking about the Amazon Leadership Principles by now, muttering that this could have been built using AWS Amplify. Let me highlight at the outset, that I would like to keep this series as “Cloud Provider” agnostic as possible. Although this solution may use Google elements (Sheets and Cloud) and I may sound like a fanboy at times, I have selected the best technology elements from my personal experience.

If you have stuck around, let us examine the elements of the design:

  • 1 - Cloud Firestore: Since my first encounter with the Firebase Realtime database more than 5 years ago, till today, I still feel goosebumps when I observe the realtime updates - see screencast below. Firestore enables “push” updates to all consumers and does it elegantly and at scale. IMHO, this is Platform-as-a-Service at peak potential. Would love to hear if there is a similar platform or product out there that makes it as seamless as this. Facebook’s Parse Platform was the closest contender I could find.
  • 2 - Ionic/Angular Framework: The Ionic framework uses Angular (and more recently React or vue.js) under the covers to build web and hybrid applications. I particularly enjoy it as abstracts me from the complexity of Angular and provides great out of the box UI widgets and components. You can be up and running with an Ionic app in an hour or two. There are also great features like Capacitor which allows you to access the underlying device capability almost natively - like the GPS or accelerometer.
  • 3 - AngularFire: As the official Angular library for Firebase, this open source project brings the capability of the Firebase SDK to Angular. Super simple to set up and configure.
  • 4 - Firebase: This mobile and web application development platform allows Developers to focus on the Application by taking care of many “infrastructural” tasks. For example - it provides Authentication (to allow sign-in via social platforms), hosting (with a free SSL cert) and Analytics - to mention just a few of the features. Documentation is superb, developer advocacy and support is what I consider the gold standard. And best of all - due to the pricing, you can prototype and run an application for free. For me, this offering from Google shows concrete commitment of its support to the developer community.
  • 5 - Google Cloud Platform (GCP): The Firebase platform is backed by GCP and although offerings such as Storage and Functions are accessible via the Firebase console/platform, it is possible to accessible the elements directly from GCP.
There are incredible platforms, packages and solutions out there which you can use to accelerate your journey. From my experience, you can get started with most - for free!

Solution Design - Iteration 2 - Where’s the API?

As I have written a book about APIs, you may be curious about the absence of a dedicated API layer in the above design. For this solution, I have intentionally kept it as simple as possible and leveraged the capability afforded by Cloud Firestore. I could have easily crafted a multi-layer solution (as illustrated below) which used a “vanilla” datastore such as Mongo or even Postgres, abstracted by a microservices architecture which also leveraged an in-memory cache. This would be accessible via an API Gateway - which would service not only a native App or Web Channel, but also third-parties who wished to consume the data.

This too, could have been built with a wide array of Cloud PaaS services - from containers to functions to databases. But, as your guide on this Cloud journey that we are undertaking together, this would have been irresponsible of me to design a complex architecture to satisfy a simple requirement - which could have been achieved using Google Sheets! We will definitely use the technology elements in upcoming projects - but always try to practice restraint.

Another wise friend remarked that it is always fun to chase something new and shiny. It is more difficult to stay the course and build use the tools you have.

Keep in mind - there are “horses for courses”. As an Architect or Solution Designer, your primary objective is to ensure that a horse completes the course as quickly and efficiently as possible.

Quick Recap and Next Steps

In this article, we extracted the Requirements from the Problem Statement. By understanding the requirements, we identified the atomic building blocks of the solution. We then found an out-of-the-box application which can be used almost immediately. We went on to design a custom solution and identified the technology elements for each building block. As part of this process, we also got more insight into the Google Firebase and Ionic platforms. I also shared some of my design principles along the way - iterative and simple.

In the next post, I will move on to Prototyping. This is where the rubber hits the road and we get hands on with the code and technology. I hope you will stay tuned. If Analysis & Design is your forte and you really feel strongly regarding some of the above design decisions, please do not hesitate to send me your feedback.

Subscribe to get my newsletter and updates of new posts. Also, feel free to connect with me via email (rennay@rennay.dev), Twitter or LinkedIn.

Read more