The adoption of a micro-services architecture has two main advantages, according to ThoughtWorks technologist Sam Newman.

One is that micro-services increase the autonomy of individual development teams within an organization, as ideas can be implemented and deployed without having to coordinate with a wider IT delivery function.

This allows new or changed features to be delivered more quickly. Organizations that understand they make money through technology – Netflix is one example Newman cited – know they need to get new features out the door as quickly as possible.

The other main advantage is that micro-services aids the adoption of new technologies, although this is arguably a subset of the autonomy argument.

Since a micro-service is by definition a small, self-contained function, it provides a low-risk opportunity to try a new technology. That is definitely not the case where monolithic systems are concerned, Newman said, as greater care is required when all the eggs are in one basket. But where a less-critical element is concerned, there are fewer barriers to experimenting with a new programming language or database, for example.

So which organizations are setting the pace? “Netflix is a very good example,” said Newman, observing that the driver for its adoption of micro-services was to ship new features quickly, rather than handling scaling issues.

Locally, REA (the company behind realestate.com.au and related real-estate sites) “is probably a couple of years ahead” in the use of micro-services, he said, noting that REA has been a ThoughtWorks client for many years, and has also embraced DevOps and automation. Its technology architecture is aligned with its organizational architecture, so REA can readily absorb companies that it acquires and therefore grow more easily. Organizational issues are key to understanding the significance of micro-services, he said.

REA approached micro-services progressively. In the first three months it made sure the foundations were in place and put two micro-services into production. But in the second trimester it was able to deploy around a dozen more, and in 18 months more than 60 were live.

Other micro-services adopters mentioned by Newman included MYOB (see DevOps in Action: MYOB) and PwC (which is progressively migrating its system for handling expatriates’ tax returns and related issues from a traditional enterprise system to a finer-grained, more decomposed architecture using micro-services, to reflect the way some parts of the system are common to all geographies while others are country-specific).

There is a very real risk that building micro-services will lead to duplication, but that is not necessarily a bad thing, Newman said. Many SOA (service-oriented architecture) implementations have been hamstrung by efforts to optimize services for reuse slowing the pace of change, so organizations may choose to accept a degree of duplication in order to speed delivery.

An Australian bank is currently exploring this issue, realizing that it previously made a mistake by emphasizing reuse over time to market, he said. “It has to be a balance… [but] reuse in itself shouldn’t be the goal.”

That said, it can be beneficial to eliminate at least some of this duplication over time in order to improve the maintainability of the systems. Otherwise the result can be “quite a chaotic environment.”

“It’s a governance thing,” Newman explained – organizations need to detect any duplicate micro-services, and then make a deliberate decision to either continue as they are or to converge them. This is healthier than simply forbidding divergence and duplication as that can negatively affect time to market.

Allowing duplication – even if only in the first instance – also mitigates questions of ownership, allowing the team developing a micro-service to proceed without the need for ‘sign off’ from other parties that may be potentially affected.

In any case, developing a micro-service typically takes around two weeks, so there is no great loss if duplicates are retired. It is a different situation when monolithic systems are involved, as they are very hard to retire in an SOA environment – an enterprise application may be grossly underused, but it can’t be removed as long as other programs are consuming its services.

The idea behind SOA was good, he said, but it became dominated by software vendors rather than by consideration of what works well for their customers.

The micro-service architecture can be thought of as ‘SOA done well,’ Newman suggested, especially as it provides a mechanism for surfacing capabilities in multiple different ways, such as (in the case of a retailer) via web sites, native and web apps for mobile devices, and in-store software. When different capabilities are to be combined in different ways, working with smaller pieces is easier than larger ones.

Newman’s book Building Micro-services is published by O’Reilly Media. It is now available as an ebook and will appear in print shortly.