Computer Weekly met Dimitrov following his presentation at the Amazon Web Services (AWS) Summit in London, where he described to delegates how the taxi booking app uses cloud services on AWS.
What is significant about Hailo is that the back-end application is engineered in a fundamentally different way to traditional enterprise software.
By combining microservices with a DevOps approach to software development it is able to roll out new functionality to the Hailo service continually, which is of growing importance as more taxi apps become available.
This approach would have been unheard of a few years ago. Apart from the likes of Google and Facebook, few businesses would have had the resources to keep adding functions and services to software to remain ahead of the competition.
Even if it was the CEO's ambition, few IT departments would have been able to keep up with the relentless pace of innovation this would have required.
In the past, a traditional enterprise application, such as a back-end banking system, would have been developed as a monolithic piece of software.
Such an approach may have suited large enterprises, but, according to Dimitrov, there are inherent problems.
“The logic in a banking application is quite easy to follow. But the challenge for enterprise applications is that they are massive and require work split across teams in a way where release cycles are in a weekly order,” he says.
Read more about microservices
- A microservice architecture promotes developing and deploying applications composed of autonomous, self-contained units.
- DevOps will shift from being a niche approach to application development and deployment and move into the mainstream.
- IT departments should prepare to change working practices to support cloud-first computing.
Dimitrov says monolithic applications pose a big problem for the business because the software can only be released every few months. “This may be fine for a bank, but a startup needs to keep adding features to the business as quickly as possible,” he says.
When Hailo's taxi app business started four years ago, the company built its software development team traditionally. But this was holding back the business, according to Dimitrov. “We could not increase our velocity. It was harder to add new features because everyone in the team was working on the same code base,” he says.
So instead of programming for a big, monolithic application, Hailo dissected the software into smaller chunks – what the industry now calls microservices. A complete team of software engineers and quality assurance testers were then assigned to the component.
“We got people to work on individual components, such as the service that runs customer registration or the service that tells customers how quickly their cab will arrive,” he says.
Working with microservices
According to Dimitrov, each of the constituent components of Hailo are relatively straightforward, in terms of coding work. “Each of these small components can scale independently, and have their own software development lifecycle,” he says. This means they can be released to production at different times, ranging from several times a day to once every few weeks.
The essence of the approach Hailo has taken with software development is that each of its software teams takes full ownership of the components, right through the development, release, refresh and, ultimately, the decommissioning process.
“It is such a small building block that people can take ownership of it. When there is a problem, they have to fix it,” says Dimitrov.
This makes quality control far easier than with traditional monolithic applications, where identifying the individual problem code can be difficult.
From development to production
The architecture diagram for Hailo is a mass of components that are intricately interconnected. Dimitrov says this mass of complexity would be impossible to manage without automation.
“Our developers provision their components and the system takes care of placing the service where it needs to be running, routing traffic to it and bringing feedback to the developers, who can control how much traffic is routed to the new service,” he says. This allows the development team to see if they have built something that does not work.
“It is important for us to get the services we develop into production as quickly as possible, so we have automated testing, starting with the Hailo application and going back through integration testing of all its constituent components,” he says.
One of the challenges a traditional software development team faces with DevOps is how testing and quality assurance fits in with continuous development and rollout.
Hailo uses a system to generate robot customers based on an island in the South Pacific. “You basically see cabs driving round and people trying to hail them,” says Dimitrov. “As long as this works and people can hail a cab, it shows that the components in our system are working.” But if it breaks, such that people are unable to hail a cab, the simulation shows there is a problem.
For the future, Dimitrov says Hailo is also creating systems to enable developers to push the components they develop straight through to production, without the need for a staging step. “We will be able to deploy straight to production and do testing directly on the production systems,” he says.
In effect, new software components will run side-by-side with existing components, allowing developers to compare how well the new service performs. “Testing will be entirely transparent to our customers. We will be able to verify if it works and the system will throw it back if it doesn't,” says Dimitrov.
It is relatively easy for Hailo to test a new function on a single microservice by redirecting 20% of customers to it for comparison. But Dimitrov says it sometimes needs to make changes to five or more microservices at a time, which means if there is a problem with the new functionality, it is extremely difficult for Hailo to test which microservice is at fault.
We build in redundancy and systems that can tolerate failures, so if one component goes down we can still work
Boyan Dimitrov, Hailo
One of the major challenges in microservices architecture is that some services are provided externally, so they are not directly controlled by Hailo. So how does the company maintain quality of service given that it does not have end-to-end control?
“The application services are decoupled in a way that allows us to identify critical services, which are then prioritised,” says Dimitrov.
“External services absolutely contribute to our uptime. We build in redundancy and systems that can tolerate failures, so if one component goes down we can still work. There are fall-back mechanisms all the way up the software stack,” he says.
Even the client app on a smartphone has a reconciliation system built in to make sure there is a good customer experience in the event of a problem with the back-end Hailo system.
The taxi app uses an Amazon Web Services back end. Its approach to software development means the back-end components can be updated independently. Each component can scale independently and works as part of a highly distributed system that make up the Hailo service. For Dimitrov, this is the future of software development.
“In the world we live in we have to be able to execute quickly. Decoupling is the only way to achieve this because it overcomes heavy operational processes that prevent you from releasing software quickly enough,” he says.