vadim yerofeyev - Fotolia
Inside PropertyGuru’s DevOps journey
The online property search firm is at ease with microservices, containers and serverless computing, even as it grapples with legacy applications that were developed earlier on in its history
Even born-digital company Singapore-based PropertyGuru has had to transform its technology DNA to keep up with the times.
Just ask Manav Kamboj, a banking and e-commerce veteran who last year took over the reins as chief technology officer (CTO) at the online property company that helps more than 25 million people to rent or buy a property in major Southeast Asian markets each month.
In an exclusive interview with Computer Weekly, Kamboj talks up PropertyGuru’s growth story, the firm’s move towards a more agile software development culture and its thinking around the use of artificial intelligence (AI) to help property seekers find their dream homes.
Tell us a little more about PropertyGuru.
Kamboj: PropertyGuru was started 12 years ago in Singapore by Steve Melhuish and Jani Rautiainen, our co-founders. They were looking for properties and realised how difficult it was to find properties by looking at classified ads in newspapers. That was when the idea of a transparent marketplace for property-seekers came into being.
Since then, PropertyGuru has expanded to Malaysia, Thailand and Indonesia, and we also have an investment in Vietnam. At the same time, we’ve introduced many industry-first innovations in this part of the world. Things that look very normal right now – like mobile apps or even floorplans – did not exist and we were the first to introduce them.
In recent years, we’ve focused a lot on being relevant to our customers – by helping them to make confident property decisions through actionable insights and relevant content. For example, we now use drone videos to show people the view of a property unit on a 10th floor.
Manav Kamboj, PropertyGuru
What has been the technology framework that has supported the company’s growth?
Kamboj: Without getting into too much detail, we started off as a simple PHP application and things have since evolved. In the past few years, we focused on getting our architecture ready for the future. Today, most of our new functionalities and features are deployed as microservices and Docker containers, with Kubernetes as our orchestration engine.
Once you have a modular, microservices-based architecture, the reliance on one specific technology does not bother you that much. So, we encourage our engineers to use the best toolsets, technology frameworks or programming languages for their particular use case. Our data science team primarily works with Python and R, and our core application continues to be in PHP. But most of our new services are written in Node.js. We also have some services that are on serverless architecture in cases where we have to deploy something quickly.
In terms of the deployment methods, do you make use of cloud-based tools and services to support your work?
Kamboj: In 2017, we moved from a private datacentre co-hosted by a telecoms provider to Amazon Web Services (AWS). That marked our journey to a DevOps mindset, which comes before processes and tools. Today, close to 100% of our infrastructure is available as code, and we use frameworks like Terraform, Puppet for configuration management, and Jenkins for our continuous integration/continuous delivery (CI/CD) pipeline.
Were there challenges in getting people to adopt the DevOps mindset, given that PropertyGuru has been around for quite some time?
Kamboj: I wouldn’t say there haven’t been challenges. There are some basic guiding philosophies that drive our DevOps thinking. Being able to ship fast and deliver value to consumers is very, very important. But that doesn’t mean we give complete autonomy to developers.
Instead, we give developers the right tools. Developer self-service is a big focus area for us, because we want to make sure developers get the infrastructure and development environment they need to build a service.
Manav Kamboj, PropertyGuru
Once you’re in containers, it becomes a lot easier – you can take your Docker images to production fairly easily once your tests have run. But from a DevOps mindset point of view, developers always need more control. And systems teams – for the sake of stability and reliability – do not always allow full control. We try to find that balance, which boils down to processes and tools.
For example, one thing we talked about internally is that if our systems team gets the same request over and over again and they keep saying yes to it, they should just automate it. And if they keep saying no, they should also look to automate it.
That’s what drives our DevOps thinking. But as a team, we’re very collaborative and that allows us to be more flexible in our thinking and helps us in getting into the right DevOps mindset.
Did you have to grapple with legacy applications that were developed early on? As you’re moving to a microservices-based environment, did you have to rewrite any of those applications?
Kamboj: That is always a challenge for any organisation with legacy systems. But one thing we’ve done well is align business projects with our re-architecting roadmap and identify monolithic applications that we can break into microservices as we build new features.
In April 2018, we went through a rebranding exercise and launched a new look and feel for our products. A rebranding exercise is primarily a marketing initiative, but we took the opportunity to address some of our legacy issues, clean up our code and introduce new platforms to our customers.
You talk about deployment time and frequency of launches. Did you take a lot longer to release features prior to adopting DevOps?
Kamboj: Like traditional companies, there was a time when you would ship only when you were ready. That could be two weeks or two months. While we talked about the DevOps mindset, part of the solution is also how you engineer your processes to speed up delivery of incremental changes.
And when we started thinking about DevOps, automation and CI/CD, we also started following agile methodologies for development. We now have fully empowered, self-contained Scrum teams, and they own very clearly defined pieces of architecture and work on specific problem areas.
That has, along with automation and the DevOps mindset, allowed us to move away from shipping large chunks of code to shipping features – like small button changes that make it easier for customers to do something. If it is a two-line change, we should be able to test it very quickly and take it live.
How is PropertyGuru using artificial intelligence to improve the customer experience?
Kamboj: From 2016, we also started focusing on building AI-driven solutions, particularly around property recommendations. These new solutions were built from scratch as microservices, which is relatively easier than working with legacy applications.
But recommending properties is very different from recommending shoes on an e-commerce platform. We have a limited inventory – and one house can only be sold to one person – while the inventory for Adidas shoes can be fairly huge. For Netflix, the inventory is almost infinite.
Our goal is to put the right set of properties in front of customers, so they can make informed decisions. We also give them insights, such as pricing trends, that are backed by machine learning. We also do some natural language processing of the content to put the right property in front of customers.
The other thing we started working on was the quality of property listings. When we first started in 2006, the focus was to make the listings transparent. And we did that really well. The challenge now is to make sure our listings have the right content and images.
We have another product called the Quality Photos Guide where we use deep learning techniques and computer vision to make sure property photos meet quality standards, such as whether the image set has enough coverage and whether there are unwanted watermarks, text or collages on top of an image.
We also deploy techniques and tools to detect objectionable content. We also try to detect if the images are genuine because one could just pick an image of any building and put it out there.
I presume it’s not just content about the property. I’m sure you have content about neighbourhoods and transportation options that property seekers will consider.
Kamboj: Absolutely. We have content about neighbourhoods. We leverage on proprietary content that we create, as well as third-party data available from Google or any other party that we may partner with. And we put all of that together and present it to the customer in a format where it’s consumable and, more importantly, actionable.
I tell my team that we’re not a content site – we need to help customers make better property decisions. For example, for pricing trends, we have a price widget where customers can look at past transactions. We also have interactive maps for customers to get a better idea about a neighbourhood.
Can you elaborate more on the data model you use to make recommendations, given that people don’t buy properties as often as they watch movies on Netflix?
Kamboj: We started off with very basic collaborative filtering-based recommendations, where the recommendations are guided by what people who are displaying similar behaviour are doing. Because people who saw one particular property also saw this other property is the reason why you should be looking at those same properties works to some extent.
But then, like I said, property recommendations are different. The inventories are limited, especially in the resale market. That’s when we started leveraging deep learning. Our current recommendation models don’t just rely on behaviour of customers who are looking for similar properties. The models also leverage, for example, image similarity, to figure out what you might be interested in, whether it’s big rooms or high-rise units.
Manav Kamboj, PropertyGuru
Unlike in e-commerce where you can learn about a customer over a period of time and continue to get better with your recommendations, property buying is a limited period experience – albeit one that gets very high levels of involvement from customers. That property buyers often do very focused searches gives us a lot of information.
Typically, when you look for a sports shoe, you might start with running shoes as a query. But when you’re looking for a house, you may not always start with a condo. You would already have some idea about your budget and which areas work for you. In case of property searches, consumers are more willing to share this information, because those are important criteria.
So, we don’t always have to rely on implicit browsing behaviour. We can rely on explicit interest of users, based on their search terms and filters. Sometimes, we ask them a guided set of questions to learn more about their preferences.
How big is your team right now, and are you looking to expand at some point?
Kamboj: We have about 100 people in product and technology, including 80 in the engineering team. As we expand, we continue to look for new talent but we don’t hire for roles – we hire the right talent.
And that’s the reason why we’re almost always hiring and we continue to look for the right kind of people who are motivated to solve interesting problems. We want to help customers make that one big decision and it’s a very different challenge from e-commerce which was my background. I’ve come to appreciate how challenging and rewarding it is when you deliver the right insights to customers.
How do you maintain a constant talent pipeline? Do you conduct hackathons, for example?
Kamboj: We do a lot of hackathons, both internal and external. Our hackathons are not restricted to technology and product teams. They are open to everyone and we welcome ideas from our business teams like sales and marketing. They have the option to join various hack-teams and work on ideas.
We also have a mid-year hackathon where we partner with a university and get good ideas from young people who view problems very differently. While they have come up with ideas related to property, we haven’t really thought of those ideas from a property tech perspective. If there are ideas that we believe can be taken to market, we will invest engineering resources to put them in front of customers.
I’m sure there are ideas about blockchain and smart contracts
Kamboj: Almost always, right? One of our hackathon winners was a blockchain solution where rental deposits can be kept in an escrow, so a tenant knows he will get his money back at the end of his lease. There was also a tokenised property buying idea that the teams worked on.
Blockchain, fortunately, is past the hype stage, with real solutions emerging. We continue to look at this space very closely, and we will be among the first to jump on any opportunity to introduce a blockchain solution ourselves or work with regulators and partners.