Ashish Sehra

Checkatrade, a popular directory of vetted tradespeople, has operated as a self-hosted collection of monoliths for a decade. They decided to embark on a cloud-native microservice transformation journey in 2019. I worked with the back-end, and cloud delivery teams tasked with redesigning and migrating to the new platform.

During my engagement, we rewrote the website's consumer-facing pages that allow people to search for services in their locality and browse service providers' profiles. The new search system was much faster than the old system. In addition, all the APIs were thoroughly tested via end-to-end integration tests, contract tests, code-coverage tests, and hundreds of unit tests. As a result, the team was extremely confident in making changes to the codebase since many faults were discovered before we tried to deploy the app.

Along with the code best practices, we put a lot of emphasis on release automation. Any changes we merged into the main branch would automatically get their own integration and staging environments, allowing customer representatives like the product owner and QA teams to verify and accept the stories. The changes could be deployed to the production environments via pipelines upon approval.

As part of Armakuni, I have worked with two high-street banking clients that were at an early stage of cloud adoption, and they had decided to offer Cloud Foundry as a platform for the development teams. The resident operations team had extensive experience managing Datacenters via Click-Ops and rudimentary shell scripts. These practices however can not scale beyond a certain point.

We built a release engineering team to manage all their clusters via code. This included setting up the clusters using standard tools like Terraform but also modeled the entire upgrade and maintenance process into CI/CD pipelines. The pipelines ensured the system was fully tested and the upgrade process was as close to zero downtime as possible.

The engagement was focused on delivery as well as enablement. This meant that we created several workshops to up-skill the resident operations teams in both the technology toolchain as well as effective processes for fast flow and making work visible (eg, Kanban).

Pivotal London formed a short-lived tactical team to address a few common problems many of its customers face while managing their Cloud Foundry installations. As part of the team, we built two tools written as Go CLIs.

The first one allowed reporting the health status of several key components of the Cloud Foundry system while the system was being upgraded. The tool would monitor the impact on the availability and reveal to the operators exactly what operations can still be performed during upgrades. This would help them plan their maintenance windows more efficiently.

The second tool was an audacious experiment allowing us to recover from a disaster scenario by restoring a backup and tracking the effect on mean-time-to-recover. We tried a few different recovery strategies, like spinning up a partial cluster and scavenging on data nodes of the old cluster.

Both the tools had an elaborate test suite containing unit and system integration tests.

Built a cloud-account delivery release pipeline that would cut down the delivery time from weeks to two days, including building the CI pipelines with a completely different design philosophy from what was already in place. The existing system required a series of pipelines manually operated by a group of engineers. In the new world, each commit would run through the entire pipeline from end-to-end, performing only the changes necessary to reach the desired state with minimal manual intervention.

This radically changed the team's capacity to deliver and allowed them to work on design changes more confidently, as every change would be thoroughly tested before rolling out. We also visualized the build process via a building dashboard (lambda) that would show exactly how far a change has been rolled out, allowing us to report on delivery timelines more effectively.

The new design also ensured we used other serverless offerings rather than managing virtual machines, reducing the maintenance overhead like patching.

The customer engagement and retention team at Sky builds and manages the online estate of Sky that helps millions of its customers take control of their accounts and subscriptions. The customer retention project helped customers remove parts of their TV subscription bundles.

We built several microservices for different customer journeys that allowed the marketing team to present customers with deals and offers to change their minds.

The microservices are integrated with several back-end APIs to present accurate information to appropriate customers. We built a CMS to allow modifying the deals and the content of user journeys. The front-end is integrated with analytics to build funnels, tracking the user activity and drop-off rates on various pages and providing insights into where we need to change the journey.

We built the ability to A/B test different experiences to experiment with variations in the UI and copyright content and assess if they would increase the uptake. The A/B testing framework would allow traffic partitioning so that only a small subset of visitors would experience a new variation.

Customers who have recently subscribed to Sky TV and broadband services must schedule appointments with engineers to install their new connections. The engineer appointments application allowed the customers to do this via the website and the mobile app. This necessitated the UI being fully responsive with specific customizations for the targetted environment. For example, the standard website header and footer should not be shown in a mobile app but must be visible to customers using the website.

The front-end application was written test-first in AngularJS, and the back-end API was written using Sinatra. The back end would have to integrate with other systems like a SOAP API to determine engineer availability. The front end would render that in a calendar, making it easy for customers to confirm a suitable time.

The application would follow the build and release principles set out by the team, where both the front and back end were written test-first. The behavior was tested using Cucumber and BrowserStack to give confidence that the app works in different environments. The UI was integrated with the analytics libraries to track how easy a customer finds navigating the calendar UI.