At Trulia, we work to make finding a home easy and enjoyable. Buying a home is an inherently cumbersome process, so we prioritize building a best-in-class consumer experience above all else, in our web and native apps. Following this principle has brought us great success – today, Trulia serves tens of millions of users each month, with thousands of requests per second at peak traffic. Thus, we need to build products to grow as quickly as possible, and you can incur substantial technical debt as a byproduct of moving fast. Technical debt is not inherently bad, but it can spiral out of control if you don’t deal with it proactively. We’ve adopted best practices in managing our technical debt at Trulia by undertaking a few large initiatives with immediate impact on the products we create and how we create them.
Creating a library
The first large initiative we undertook was to create a library of the components we use in our user interface, enabling us to build attractive applications quickly and bug-free. Web developers at Trulia have always built products across the full stack: i.e., server-side code to fetch data and build output (e.g.: HTML), and client-side code in JavaScript and Cascading Style Sheets (CSS). After seven years of building and improving products like this, we started to notice variations in our consumer-facing user interfaces and their implementations. These differences were due to the methods we used to execute quickly, which included building new products independently, versus reusing preexisting modules. So, our engineering and design teams worked with CSS expert Nicole Sullivan to build a living style guide for our products, and then migrated our flagship products from their ad-hoc implementations to this well-tested user interface component library. Not only did the change to a component library immediately address the minor design inconsistencies in our product, it sped up our products’ performance and our teams’ velocity.
Moving to https
On the web, the only constant is change. One of the most impactful changes in the past few years has been the push to encrypted transport (https://) by default. As consumer expectations of privacy and security on the web become more apparent, and products like Google incorporate https into their ranking algorithms, websites are moving quickly from unencrypted transport (http://) to encrypted transport. Thanks to concerted efforts to support pervasive encryption like Let’s Encrypt and Is TLS Fast Yet?, setting up a site or component to support https is easier than ever. Upgrading a larger application, however, can be more complicated, due to implementation details like the content delivery networks it uses and the complexity and scale of internal and third-party integrations. In order for a page to be served securely via https, all components on the page must be served over https. So, in order to serve a site over https without browser warnings, every domain referenced on a page must support https. Common third-party integrations like Google Analytics and Twitter widgets use https by default. For older apps, you may need to update your integrations with the latest code snippets.
In September 2016, we moved our flagship web applications to https. The project entailed updating references to every domain from which we load assets (images, JS, CSS, fonts and more), and ensuring that each of those domains supported https. This meant checking and upgrading about 20 internal domains and numerous external service integrations. Besides the great benefit to consumer privacy that https offers, it also allows a site to support the newest version of http (HTTP/2), which supports substantial performance improvements over http thanks to optimization techniques like its binary protocol, header compression, and multiplexing.
Breaking up a monolithic application into services
Since launching in 2005, we’ve steadily built out new functionality on Trulia’s web app as part of one large codebase. This has been beneficial in ensuring a consistent consumer experience, and that every part of our product was using the correct code to integrate with any related systems. However, as our application has scaled, the benefit of having the entire application in one package – commonly referred to as a monolithic application – has been balanced by the constraint that a change to any of the applications could require a full deployment and regression verification for all of it. There are numerous ways to address this issue. The most popular way is to migrate to a service-oriented architecture (SOA), breaking an application into smaller, separately maintained pieces, a technique known as decomposition. Decomposition is what we’ve chosen to employ at Trulia, determining where we should split up the application based on the natural boundaries of functionality in our application.
We’re taking the opportunity to migrate our application from running in traditional collocated data centers to running on cloud services, as well. As we extract functionality from our monolithic app, we build out the replacement as web services in the cloud. This move can provide notable cost savings and flexibility in deployment going forward, but its benefit is actually more impactful from a maintenance perspective. As we break up our application into smaller parts, it is easier to test each piece independently (e.g., with automated testing scripts), and helps ensure that fewer things change unexpectedly with each deployment.
As we continue to modernize and refine the collection of products we’ve built throughout the past ten years, we are optimizing our execution by employing shared tools like our UI component library, and breaking up our products into smaller parts, like our project to decompose our colo-hosted monolithic app into cloud-hosted services. As we look forward to the next ten years, we expect to leverage these investments to allow us to move more quickly, without sacrificing the stability of our flagship products that our consumers have come to know and love.
This article originally appeared on CIOReview.com
