What is SiteMinder?
The official marketing is: a hotel commerce platform that helps hotels to sell, market, manage and grow their business from one place. The practical version: hotels have inventory i.e. hotel rooms, and limited hours in the day, so they need a mechanism that puts them in front of guests: channels, and ensures they are operating efficiently and intelligently online.
A channel for a property could be someone who phones up, could be your own website with a booking engine embedded into it, or Google when searching for a particular location. We write different software, features, and components to push the inventory to all these various channels and fulfil the bookings.
We’ve also built a holistic range of other tools that help hotels to operate smarter, and ensure they are meeting the changing expectations of their guests, too.
How did you decide to start this business?
It was kind of a weird coincidence. When I moved to Sydney, I interviewed for a small healthcare insurance SaaS company. During the interview, I had a chat with a development manager, also a South African like me, who went to the same primary school as I did. We became friends, and I learnt about his experience doing a side job for a backpackers on Sydney’s Northern Beaches.
Essentially, they were spending a lot of money managing their online inventory. Various staff members had to spend hours on various channels like Expedia, typing room data, then going to the next website and duplicating the information. He came to me and mentioned that there must be a way to automate this whole process. We started building prototypes, dropped out of our day jobs, took part-time contracts to pay the bills, and built the original version of SiteMinder’s distribution platform.
Screenshot from Siteminder.com
So you were both technical?
Mike, my co-founder, has a background in data warehousing. He is technical enough, which is probably why we go so well together. He pretends to not understand the tech sometimes, but he does. In the beginning, he was the one doing the business development, and I was head-down coding. With no seed capital, we had to do everything ourselves, including cold-calling and support.
How has your role as CTO evolved over time?
It has gone through a few phases: from very technical and hands-on, to more people-focussed as the team grew, to more of a mentor who is still deeply engaged on the front line. For the first five to seven years, it was 100% coding and infrastructure architecture, which is still my passion today. After years of managing a growing headcount however, about three years ago we hired a chief engineering officer who is running the team now, as he loves working with people. I like mentoring, but we can’t do both, so we’ve been able to create a nice balance.
You’re a big company and still manage to do some coding, that’s interesting.
You have to do what you love. When I programmed for the first time, I knew it was my passion and that it was what I wanted to do. It makes it easier to connect with engineers.
I think the CTO role is a funky role: there are so many different types. Sometimes it’s a jack of all trades, sometimes it’s someone who is more people-oriented. There is no cookie-cutter for what a CTO should be. I would be more on the architectural side of it.
Could you please describe your tech stack?
In a nutshell, we’re fully cloud-native. We pre-date AWS, and migrated from our own servers to AWS nine years ago. However, lifting and shifting into the cloud is not actually embracing cloud technology, and we moved to a microservice architecture ultimately. For core languages, we use Kotlin on the Java side and Node.JS.
Lots of Aurora, DynamoDB, and Vue.js on the frontend. Also, we use some graphQL and elasticsearch. Our core approach is asynchronous. We learnt the hard way that asynchronous is the way to go.
Bunch of queues and cron schedulers?
Yes, we actually call them systems, not microservices. A system is a domain that broadcasts on streams as events change. As they are processing whatever they are doing, they broadcast events and listen for new events. As an event occurs, it will hit several APIs to transfer the state across. We try not to have point-to-point microservices.
How do you broadcast these messages?
The actual event will be broadcast on Kinesis, the streaming service, as a JSON payload. They will all have traditional APIs too.
Screenshot from Siteminder.com
Are you not too worried to be dependent on all these AWS services?
Not terribly. It’s true there is vendor lock-in versus being agnostic — for example, it would be complex to swap Kinesis for Kafka, but it’s a cost-benefit approach. We’ve always been very happy with AWS and I don’t think there is a massive risk of a crazy price hike suddenly. Our code is in Node.JS and the database Aurora, which is MySQL ultimately.
What are you looking for when hiring?
It really depends, but stereotypical answers are true. Engineers who are curious and humble are important. You realise, as an experienced developer that you don’t know a lot, and there is so much out there, so these character traits are key.
Not being dogmatic is a really great character trait. You need to be able to have a debate, have an opinion and be able to back down in the face of evidence. There are many ways to skin a cat in software engineering. Ultimately, we are writing code that will go in front of customers, so you also need to be able to interact with product people, making interpersonal skills important.
What is your level of interactions with platforms like Expedia or Booking.com?
We’re partners with them in every sense of the word. We provide them with reliable inventory feeds, so it’s definitely a partnership arrangement.
Any fun fact or horror story that happened in your career?
We had one story a few years ago, pre-AWS, when we were a small company. We had done a MySQL upgrade in one area well and without issue. Then we went to a different region for the upgrade.
We did all the due diligence as it was a forward-only move, however we had pushed MySQL to the point where it couldn’t process what we needed to process. In the end we spent 5 days, with no sleep, as all the engineers figured out how to do the rollback. It wasn’t supposed to be doable according to MySQL but we managed, and it was the most stressful event in my life. The customers didn’t notice too much as manually on the backend we were managing everything. I never deleted a production database, luckily!