How a seamless Rails modernization enabled automated cloud scheduling and multi account AWS protection

PROJECT OVERVIEW

ABOUT THE CLIENT

This case study is based on a real VNEXT project. The client's identity and certain project details have been anonymized or generalized for confidentiality purposes.

The customer looks after other companies' cloud environments. Its own customers run their systems on AWS, and it watches those systems, switches servers on and off on schedule, takes backups, and raises the alarm when something goes wrong. That work depends on a single internal platform, and the platform is its working tool every day. It is the same kind of service that sits behind managed IT services, where the quality of the tooling is felt by every customer who relies on it.

THE CHALLENGE

A programming language does not stand still. Keeping a platform on a supported version of Ruby is part of looking after it, but an upgrade touches everything that was built on the old version, and a monitoring platform has little room for surprises. If it behaves differently after the change, the customers who depend on its alerts are the first to notice.

The platform itself was broad. It manages many AWS accounts from one place, controls the servers inside each account, watches servers, databases, and load balancers, runs scheduled operations, records events, and sends alerts by email and by telephone call. An upgrade had to carry every one of those functions across intact.

The requirements arrived incomplete and in places unclear. The customer knew the platform well, but the details of what should stay the same, and what could change, had to be drawn out through conversation.

PROJECT OBJECTIVE

The customer wanted its platform brought up to a current Ruby version without losing any of the behavior its own customers rely on: centralized account management, monitoring, scheduling, and alerting, all continuing to run well on AWS.

APPROACH AND METHODOLOGY

Meeting often enough to settle every doubt

Since the requirements were not complete, our team held frequent meetings with the customer and asked it to explain each unclear point in more detail. Each meeting turned a doubt into a decision, and it meant that when development began, the team was working from a shared understanding.

Working stage by stage

The project followed a stage by stage plan, with design, development, and testing in a clear order. For an upgrade where the aim is to preserve behavior, that order kept the team honest: first agree what the platform does, then change what runs underneath it, then check that it still does the same thing.

Putting the right strengths in each seat

A communicator who knew the platform's business translated documents and carried information between the customer and the team. A development lead who was comfortable with Rails on both the frontend and the backend led the technical work. A tester with project experience checked behavior against what had been agreed, and a quality assurance member watched the way the project was run, drawing on our software testing practice.

Staying on after release

The engagement did not end at delivery. Our team continued to support the platform in maintenance afterward, so that anything found in real use could be put right by people who already knew the code.

TEAM SCALE

Five people worked on the project: a project manager, a communicator, a development lead, a tester, and a quality assurance member. The team was small enough for everyone to understand the whole platform, and each role had a clear purpose.

THE SOLUTION AND TECHNOLOGY STACK

The upgrade was part of our legacy modernization work, which keeps systems current without discarding what already works, and the platform it covers is a useful picture of how much a single application can carry.

What the platform covers

• Central account management: brings the customer's AWS accounts together in one place, with sign in handled through AWS's identity service
• Server control and monitoring: manages and watches the servers inside each account, with graphs of how they are performing
• Database and load balancer monitoring: tracks the health of databases and of load balancers
• Scheduled operations: starts and stops servers, runs monitoring, and takes machine image backups on a schedule
• Alert thresholds and statuses: lets the customer set the levels at which something counts as a warning or a danger, and shows each server as normal, warning, danger, or not monitored
• Events and notifications: records what happens in the system and sends email, with groups of recipients for email and for mobile numbers
• Phone call alerts: places a warning call to a customer's phone number through Twilio
• Customer information: keeps each of the cloud company's own customers' details alongside their accounts

Technology Stack

The platform runs on AWS, which places it within our wider cloud practice.

THE RESULTS

• A platform that stayed itself through an upgrade: the upgrade dealt with some complicated problems and the platform continued to work well on AWS.
• Central control that feels simple: the platform shows how many AWS accounts can be handled easily and professionally from one place.
• Information that is quick to reach and reliable: the customer can see and control information conveniently, quickly, and accurately.
• A customer that is pleased: the customer is satisfied with the product it has today.

The customer's platform now rests on a current foundation, ready for whatever it is asked to monitor next.