Fostering Growth

Introduction

Vivid Cloud was a newly formed company when they approached Big Room Technologies.  Their goal was to grow into a custom software services company, not dissimilar to us, but with a narrower focus on guiding large enterprises through cloud technology adoption.  Vivid Cloud had an opportunity to augment a team for a client in the financial services sector and help speed up their cloud adoption with AWS.  While they had the AWS/backend talent to do the work, we were brought in to provide the UI/UX frontend expertise.

Problem

The larger Big Room Technologies/Vivid Cloud team was trying to solve two problems and they both fell under modernizing the client’s technology stack with an AWS migration: the backend/architecture team was focused on moving complex infrastructure from on-premise servers into the AWS cloud (reconceptualized as microservices).  Meanwhile, the frontend/UI team was focused on making a framework for building single page applications that would all come together under one umbrella: a Portal. 

The client had a hard requirement that each team maintain its own deployment pipeline so they could autonomously release changes into production (previously a specific devops team managed deployments). They are a large organization with ~15 project teams, and ~8 platform teams that own specific components of their technology stack.  The platform teams build and maintain tools to enable the project teams to move fast and not break stuff. They also generally support the project teams within their domain.  (Spoiler alert: we ultimately became the platform UI team!)  The project teams, on the other hand, own entire applications including: front/backends, QA, deployments.  

Approach

While the project had ambitious goals to rethink technology at Vivid Cloud, in true Agile fashion we started small and iterated.  We first tackled building out a single cloud-based application as a proof of concept.  From there, we rethought the architecture of the UI, catering to their development team structure by splitting up responsibilities of the original application so multiple development teams could eventually own and maintain them.  We augmented one of the project teams, splitting off code specific to the application and transferring it to the other team, while keeping the code that is responsible for unifying the discrete applications (mainly authentication and navigation elements).

Solution

We chose to adopt front-end microservices to facilitate all teams owning their deployment pipeline while still bringing the application together as a single page application.  Specifically, we chose single-spa to implement the front-end microservices architecture, terraform to manage all infrastructure, and gitlab-ci for our pipelines.  We continuously maintain the central “Portal” application that allows a user to log in, navigate between available applications, and load them as necessary. As a function of initial implementation, we also successfully handed off the first application to a project team.  Meanwhile, in UI-land, we wrote everything in typescript/react, and leveraged Material UI for common UI components to speed up development and perpetuate a cohesive design language.