According to a recent O’Reilly radar survey on the growth of cloud computing, one of the more interesting metrics stated that 52 percent of the 1,283 responses say they use microservices concepts, tools, or methods for software development. Of these, a large minority (more than 28 percent) have used microservices for more than three years.

This was the second-largest cluster among users of microservices. The largest group, at more than 55 percent, has been using microservices between one and three years. Moreover, just 17 percent of users are new to microservices, with less than one year of adoption and use.

O’Reilly also points out some evidence that interest in microservices might be at or close to peaking. Also, noted decomposition of service frameworks—at least to the degree of granularity prescribed in microservices architecture—is proving to be more difficult than anticipated.

The use of microservices is really a natural progression of service orientation and the use of cloud-based systems. The ability to decompose course-grained services to microservices is just a good idea. You’ll have more services that have more uses, such as an update inventory course-grained service that can be broken apart to read existing inventory data, modify existing inventory data to updated inventory data, validate updated inventory data, and write updated inventory data to storage.

Once this macro service is broken down into four microservices, you can use them within this macro service. Or you can reuse them in other macro services and composite applications (forgive the overly simplified example). The objective is to write a microservice once and use it many times.

You’ll be better off writing microservices in ways that make them more generic and general purpose, applicable within many different usage patterns (unlike the examples above that are not generic, focusing just on inventory data). This, however, is where the difficulty comes.

Copyright © 2020 IDG Communications, Inc.