Prakash Prasad

A tale as old as time - as companies become successful, their application landscape becomes very large, and often complicated. This means there’s great value in the existing systems, but building on top (or making changes) gets more and more difficult. The mythical “technical debt” rears its head - business is confounded why changes are so slow (and costly), and developers are miserable because they do not know where to start with the changes.

The good - life goes on, things work, and companies make money.

The bad - each new improvement, or development gets harder and more time-consuming; people find it complicated to build improvements (where does one even begin); development silos that make the company less and less “agile”.

If’s claims organization, is trying to approach this with a new strategy (actually not so new). It involves improving service boundaries of our existing applications, encapsulating our technical debt in a more manageable form, setting up a data strategy to seamlessly integrate with old and new core systems alike, and enabling microservices through an event-sourcing platform.

For a company like ‘If’, the focus is on developing homogenous solutions to simplify processes and lower operating costs. This meant a focus on decomposing the company’s legacy monolith applications into a more flexible and maintainable architecture. My role in this mission statement is to:

• Assess the existing code for service boundary issues

• Plan continuous refactoring of the domain to help with technical debt related issues

• Designing new, cloud native applications and microservices

Fullstack development:

• C# backend (.NET Framework, .NET core)

• React frontend

Software development responsibility following DevOps philosophy:

• Full lifecycle handling of a user story

• Continuous integration everything

• Continuous deployment everything (with heavy usage of feature-flags)

• Infrastructure as code for Azure resources (using ARM, Bicep)

• Application Monitoring (Application Insights and Message Queues)

The Future Group develops tightly coupled products for television broadcasting using Unreal Engine 4. Their products vary from content for broadcasts, to second screen mobile apps augmenting those broadcasts. Their first show, Lost in Time, aired in April 2017 in Norway. While working there, my duties were:

• As technical lead my role was to liaise with various stakeholders in production of the games (for the TV show as well as for mobile phone) - workflow (setting up Perforce SCM, and Jenkins build pipelines), architecture, QA, etc.

• When getting closer to the delivery deadline, my focus shifted to performance testing, and optimizations for PC and mobile platforms (iOS and Android).

• Architect of a event-driven platform providing data connectivity for several internal and external integrations using a pub/sub architecture.

Heroes & Generals is a free-to-play, MMO game that combines real-time strategy (RTS) with first person shooter (FPS) gameplay. The game’s framework is built as a Service Oriented Architecture (SOA) using Protocol Buffers for communication.

At the core is the game’s “War Server”, which handles most of its events, such as - login, matchmaking, statistics, metrics, transactions, handling results of games, etc. These event handlers are used by various parts of the game - web client, FPS game, and mobile client.

Some of the tasks I’ve been involved on the project are:

• Implementing event handlers that service game clients. For eg: buying soldiers, mounting/demounting items, execute unit movement orders, starting a mission, etc. The game logic for the strategy game is also implemented through these event handlers.

• The architecture is based on an in-memory key-value data storage. However, one issue with such a system was handling multiple updated to the same object before a transaction is finalised. I implemented a data cache which would allow this functionality by storing intermediate results and fetching the appropriate object when requested.

• The game’s immutable data had to be accessed through the in-memory data storage system. This was a very naive data access method, which would load data from the static store on each event handler execution. I modified the above mentioned data cache system to load this immutable data once on server start, which greatly improved execution times for the handlers.

• Data Management – Handling tasks related to management, upgrade, upkeep, and trouble-shooting on the game’s persistent dataset, which is stored on a SQL database server (PostgreSQL).