The microservice concept has something in common with services oriented architecture (SOA), but that was often about about presenting a particular functionality of a larger program so that it could be readily consumed by other pieces of software. For example, a 'get customer address' service might be implemented to extract an address from the CRM. If the CRM is subsequently replaced with another vendor's product, the service can be updated to access the new system and (in theory) all the software that calls the service will continue to function correctly without modification.
In contrast, microservices are built from scratch to deliver the required functionality and nothing else. So each microservice is independent, with its own data storage and API.
Among the benefits of this approach are that it allows work to proceed in smaller chunks, the largely self-contained nature means easier testing and therefore better quality, isolation of functions means more people can simultaneously work on different aspects of a system, microservices are readily reusable (though that's just the icing on the cake, according to Raik-Allen, even though it can result in "massive savings"), each microservice can be scaled independently, and the most appropriate technologies can be selected for each.
Even if it's necessary to access another computer's memory via a network connection, that's still faster than accessing a disk drive, he said.
He conceded that having a query language can be useful, but pointed out that "there's this thing called a For loop."
The point is that different microservices can use whichever database is most suitable, or none at all.
The architecture isn't without drawbacks.
"You've got a discovery problem," said Raik-Allen, but this can be addressed with service catalogues as well as informal tools used by developers such as wikis or simply conversations among peers.
The code does need to be resilient, as individual services operate in a relatively dynamic environment, and it is somewhat harder to achieve transactional integrity when that is required.
There are also some maintenance issues. While the API may remain constant, it is possible that implementation changes may adversely affect software calling the service, especially if it makes unwarranted assumptions. So it is necessary to keep track of what software uses the service and how, and to test accordingly.
And there's the question of whether to allow multiple versions of a service's API. Some organisations do while others don't, he said, but either way it is important to ensure that everything keeps working.
Microservices and DevOps go together well, he suggested. Microservices fit into a DevOps environment, and they need DevOps to work well as developers need to understand the operational impacts.
"We're about 20% in," Raik-Allen said. Some microservices have already been built, but he's still working on awareness issues. "It is a big shift in the way you build applications," but the people that are using microservices wouldn't do it any other way.
MYOB has built a microservice called Glass (general ledger as a service) that is already used by MYOB Essentials Cashbook, and Raik-Allen expects the general ledgers in all of the company's products will be migrated to it over the next five years.
Similarly, a logging microservice has been developed and will be widely used by MYOB software. This saves application developers having to worry about the details of logging or managing the required disk space. It also provides a central repository for log data, making it easier to analyse with BI tools.
Work is underway on an invoicing service which will identify new invoices in AccountRight, ask the client if they should be paid, and if so perform the transaction and otherwise generate a reminder a few days before the due date. This is being built from scratch from six microservices, including one for sending emails that has already been reused elsewhere.