The state of microservices and cloud computing

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.

At the essence of leveraging microservices effectively is the ability to set up service decomposition frameworks where the maximum number of microservices are reused. This skill, however, has been difficult for most application architects to develop.

I’ve spent a good part of my time in the past several years pushing through microservices-enabled application designs and finding that most of them don’t have the necessary planning to fully take advantage of microservices. I’ve seen a hodgepodge of fine-grained services that are written once and leveraged once, missing the core benefit of what microservices are for: the reuse of hardened and tested small services.

As the survey points out, we’re finding that the proper decomposition of services to microservices—and service orientation in general—is a bridge too far for most application designers. The only resolution is to get some training, understanding that this is more art than science. Perhaps then we can push past the stall.