What is an Extreme Startup
Extreme Startup
Extreme Startup is a coding exercise game created by
Robert Chatley.
It is used in software engineering workshops and
the main goal of such games is to encourage developers to use CI/CD
by showing the benefits of quick-release iterations.
During a workshop session, the facilitator,
the game admin,
uses his computer to send HTTP requests with questions or riddles to players’ computers.
Participants should write code
that figures out how to solve the puzzles and sends HTTP responses to the server.
Correct answers give points; incorrect answers or timeouts result in a points deduction.
The key factor to succeed in that game is to set up a working deployment pipeline
that enables them to deploy new versions of their player application quickly.
The list of people who conducted Extreme Startup sessions can be found on the
original repository's GitHub page.
Scaling
Extreme Startup
Scaling Extreme Startup Project
is a recreation of the original game and an extension of its functionality,
as well as the architecture behind it,
that enables it to scale horizontally and support more games on demand.
It is built in Python using Flask Web framework and React for the front end.
The app has been later enhanced with AWS technologies,
such as AWS Lambda, DynamoDB and Simple Queue Service.
The tool was developed as an Imperial College Computing Year 3 Software Engineering Project
by a team of six students.
The project has been successfully submitted and presented,
as well as applied by Robert Chatley
at the CI/CD workshop in the London office of
Deutsche Bank
and at Imperial College London.
Our Objectives
Extreme Extension
The figure above briefly shows the idea of separate apps for the front end and back end.
Communication via HTTP requests in JSON formats enables independent implementation
of the two software system components.
(Hidden) Extreme Extension
The project itself was not just an extension but a remaster.
The original implementation
had been viable and was used in workshops already.
However, the problem with the old version was the lack of convenience
when running configurations and moderating the game.
For instance, the Extreme Startup game includes a warmup round and the actual game.
To proceed to the first round of the game that follows the warmup,
the game facilitator had to restart the application with a different environment variable.
There also needed to be more functionality for the admin and helpers to administer the game.
The most important goal of the remaster was to address that problem.
That was done by creating a Flask web server application
that stored a game session details in its internal state
and therefore, it enabled users to pass the warmup and proceed to the first round.
The app could also support multiple games, as all objects now had unique identifiers.
New UI and Features
Another way to address the convenience was the modern approach to User Interfaces on the Web.
React App was used for the front end, and the user could communicate with the game via control elements
such as buttons and switches.
Rest API achieved the communication between the two apps.
The Front-end app accessed the server with one of the permitted URLs
and added a JSON as a payload.
The backend replied with a status code and response JSON.
The JSON data was transformed and displayed in different UI elements.
When it comes to the Visual components,
there was a massive improvement compared to the previous minimalist design.
A screenshot of the App homepage.
It is an interactive and engaging way to create or join a game with a fancy dark theme.
A screenshot from the game. The leaderboard is represented as a chart of scores against time.
The green and red markers represent the correctness
of participants' answers to the requests.
The new version of the application has been modified and extended in various ways.
First, the minimalist UI was replaced with a range of React and Mantine components
that enabled responsive design and easier control over visual appearance.
Second, the facilitator got admin features and the ability to add moderators.
A dashboard could show the players' assistance state and many more.
In addition, new updates made it possible to create games, choose settings,
and add players without hardcoding or restarting the app with new environmental variables.
Finally, the game chart, the leaderboard line graph
that shows the score against time, is fully recorded and
saved into a game report with different stats.
Overall, the application was enriched with new features
and new ideas were sparked frequently at different stages
and the only limitation of the extension was time.
Extreme Monolith
The replication and extension stages
had an application deployed on a single server on one machine.
The main disadvantages of such an approach
significantly affect the app’s usability and maintenance costs.
Having a single point of failure, all current game data is lost if a server goes down.
That also implies that deploying new updates when games are played is impossible.
Another disadvantage is that the usage rate of the application is not constant.
Many requests are made when a game is played, and much computational power is required.
Meanwhile, the app is not used at any workshop,
it is idle, and the powerful CPU of a rented VPS is underutilised.
That may lead to a problem when the game becomes popular.
Which leads to the attractive option of migrating to the cloud.
An overview of the system components interaction and journey of game logic.
The dashed boundary outlines the components in a server machine, including the frontend that acts as a gateway.
Extreme Scaling
The figure above shows a list
of three main AWS services employed for the scaled version of Extreme Startup
Extreme Scaling (Hidden)
The scaling of such a project is achieved with such services as follows.
Simple Queue Service receives messages and is used as a Schedule for events
that invoke AWS Lambda
that handles it.
There are two main types of messages.
The first one is a player question event that requires sending the request,
receiving an answer,
assigning a score,
and scheduling the next check and sending it to SQS.
The second one is the monitor Lambda
which can stop further scheduling of player FaaS invocations
that belong to a particular game session.
DynamoDB was used as a fast persistence storage
that contained the state of the games and supported many quick games.
The main reason for choosing DynamoDB is NoSQL's speed and schema flexibility.
It worked very well for games that included one hundred players,
and the supporting evidence is the automated tests with simple bots with their entry points.
AWS Approach — Detailed Picture
The Flask server did not go,
but now became the initiator of FaaS computation and did not execute any game logic.
Only queried DynamoDB to update the React App that the user sees.
That reduced the server’s responsibilities
and it enabled its redeployment during the game session.
It has been successfully demonstrated in one of the weekly meetings
of the development team and project supervisor.
The AWS Lambda computations persisted during the Flask server redeployment
because once the game has been initialized, it is maintained by AWS alone.
It becomes a read-only process that can be observed or killed by the host server.
The core component,
AWS Game Manager object,
is the one that orchestrated the process of starting the game computations
and queried the game state stored in DynamoDB.
The two Question Factory components represent the shared code
that lives on both Flask and AWS.
The Rate Controller is the object that makes sure
the players who perform poorly get fewer requests as a part of market demand simulation.
It controls the duration of a delay until the next request.
An overview of the AWS enhanced scalable architecture.
There are now two main areas.
The grey box indicates the single-core server that has minimized workload.
The orange box indicates the main computation and storage that can scale on demand.
Live Tests
(Hidden) Live Tests
The year three academic project went beyond the scope of assessment.
It has been successfully applied in the United Kingdom and the United States.
The
source code
of the project got published under GPL-3.0 License
and anyone can host it and apply it in their teaching.
There are two honourable mentions of demonstrations that we are proud of.
As follows:
Deutsche Bank
The live test at Deutsche Bank was the first attempt to run the game with real players.
Our team was invited to the London office, which was an honour.
Overall, the game sessions were successful.
A few bugs discovered during the game did not ruin the experience and were fixed afterwards.
Participants learned the importance of CI/CD from the game.
They saw the advantage of the fast deployment, which allowed them to respond quickly and get more points in the game.
Some participants even implemented unit tests as a part of their pipeline.
That prevented them from losing points after accidentally pushing new code
that broke some cases.
But the most significant accomplishment was that people had a good time.
Imperial College London
Starting the new academic year after the project,
Robert Chatley included the Extreme Startup workshop in the curriculum.
The academic module is called Software Systems Engineering
and it is a new course for MSc Computing.
Me and other project members had the pleasure of moderating the game
and helping participants with the setup and the game experience.
Many students enjoyed the experience and had fun.
Unfortunately, a fire alarm interrupted the session,
but participants returned to play.
Luckily, Robert paused the game when it all started,
which made me proud of us for implementing that functionality.
Future of Extreme Startup
The project is alive; there were some feature suggestions after live tests.
It might take some time for them to be implemented
and with continuous feedback from future workshops, there might be more to add or fix.
There is no limit to getting better.
My Extreme Contributions
As a team of equally experienced individuals,
we had a shared leadership that had some downsides
but gave me a chance to take the first step.
I designed a REST API between the Backend and Frontend with my colleague Mihhail Sorokin.
I was responsible for maintaining the REST API spec and ensuring the Flask and React apps communicated properly.
As a result, when we split the work for the first two stages, Recreation and Extension,
I had mixed responsibilities of a ratio of 60:20:20
of Frontend, Testing and Backend respectively
and whenever we had to extend the set of REST entry points,
I was the one who updated the PDF and kept everyone aware of the changes that happened across the components.
In the latter stage of the project, Scaling,
I was the AWS account holder, implemented the Lambda, and created a pipeline that created a lambda archive to share repetitive code between the Flask and AWS components.
Overall, I was pleased to be a part of the Scaling Extreme Startup Repository.
Key outcomes of the project include new React experience,
extended and tuned AWS management skills,
expanded my horizon in web development and learning how to work in a larger team of six.
Extreme Acknowledgements
Thank you, Oscar, Johnathan, Jamie, Mihhail, and Devendra for working with me
and thank you, Robert,
for giving us the great opportunity
to work on that project, included
not only invaluable practical components,
but also real-world applications.
I would like to add that as an AWS account manager,
I am also glad that we managed to stay in a free AWS tier during the development process
(wink).
Andrey Popov
2023
