Rebuilding core components into microservices.
Domain is “attacking the core” of its .NET-based website in order to rebuild it with a microservices architecture and more modern front and back-end technologies.
The real estate listing site moved its entire infrastructure into the AWS public cloud in 2015, shutting down more than 200 servers in the process.
The DevOps darling threw itself in headfirst, adopting as-a-service for software and platforms as well as infrastructure.
But where it has since moved to more modern front-end technologies for newer parts of the website like its ‘find an agent’ function, the core components – such as its homepage, listings and search results – are still largely powered by a .NET application and SQL Server.
“We basically decided it was time to attack that core and smash it really hard,” Domain CTO Mark Cohen told iTnews.
“The aim is to go to microservices and microsites for the whole thing,” Cohen said.
“Instead of chipping away at the edges we’re driving a bulldozer into the big rock that’s left.”
There’s around 100 microservices already running, which puts the team around a quarter of the way through the effort – alongside rewriting the core Domain website, it’s making all its new components reusable across its other web properties.
“Imagine if a single prop change can set the brand colours, or switch between which component to render, or even result in local cached data being used over a JSON AJAX request. That’s what we’re working towards,” Domain said in a job ad.
But it’s not standardising on any one technology, instead opting to let its developers select their favoured tools.
“We’ve discovered that people that know a lot of different languages are the best developers. We’re not prescribing anything, but we also don’t want to end up with a lot of different languages,” Cohen said.
“We’re asking the guys to use more diverse technology, but we’re not going to say use whatever you want.”
Languages will be adopted for components that best suit their attributes – Google’s Go language, for example, might be used in a service that needs to scale massively given it’s better at preventing memory leaks, Cohen said.
“Different microservices lend themselves to different environments.”
The side benefit this approach has is the more the team rewrites Domain into microservices, “the better we get at continuous integration and continuous deployment”.
Cohen’s team is releasing changes into production once or twice an hour now; two years ago that figure was once every three weeks.
Cohen sees the microservices overhaul as an “interstitial architecture, not the final destination”.
That future, he says, is a serverless one.
Serverless compute – like AWS’ Lambda, the platform Domain is eyeing off – allows customers to pay only for the time they need for their code to execute, rather than for server instances.
It takes away the traditional scability, availability, and security concerns of the infrastructure server layer so developers can focus solely on building their application without worrying about deployment.
It’s a key enabler for microservices-based applications for this reason, and it’s why Cohen sees his new environment as a “stepping stone” to a serverless state.
“The logical architecture stays the same, but the physical architecture changes,” he said.