Microservices: first break down monolithic thinking, then monolithic applications

Microservices shake up older ways of thinking as they dissolve monolithic applications,
Written by Joe McKendrick, Contributing Writer

There is sure and steady momentum building toward microservices architectures. And not a moment too soon -- organizations can no longer afford to be held back by rigid systems that require weeks of rework to support a new business process.

Photo: Joe McKendrick

The latest sign of the microservices wave comes from Microsoft, which announced it opened up its Service Fabric microservices platform. As described by fellow ZDNet contributor Mary Jo Foley, Microsoft's Service Fabric operates in the same space as Kubernetes in terms of its capability to act as orchestrators, packaging, deploying and maintaining microservices and containers.

Connectivity and communication between microservices is also critical in assembling this new architcture, esepcially since services will be both on-site and out in the network. Last year, IBM, Google and Lyft teamed up to form Istio, an open technology that provides a way for developers to connect, manage and secure networks of different microservices, regardless of platform, source or vendor.

This shows movement to the proliferation of microservices architecture development, seen as the path to breaking down monolithic systems and applications into flexible, bite-size services that can be assembled and disassembled as business processes require.

However, to a large degree, the move to microservices architecture requires assembling and dissambling the ways businesses and their IT departments have operated. Red Hat's Cesar Saavedra recently provided guidance on overcoming challenges with microservices.

Prepare for changes in corporate culture. Microservices architecture requires more of an Agile organization in terms of the way teams are organized -- meaning more interactive and incremental approaches to rolling out software. "The old waterfall technique and the organization of teams by function go away, replaced by smaller teams working on microservices," Saavedra observes. In addition, there will be an elevation of developer and IT roles. The technology-agnostic nature of microservices -- in theory, they should be swappable and pluggable on any type of environment -- means development shops can focus more on the business problems at hand in their design.

Look to platforms that support microservices architectures. As an organization's catalog of microservices grows, so does potential complexity in managing all the services and keeping them updated. Saavedra advises "looking to acquire a platform whose capabilities include microservices management" to complement in-house development.

Monitor and measure. It's important to stay on top of how microservices as performing, especially since many processes and adjoining services depend upon this performance. Again, Saavedra advocates tapping into a platform "that can provide built-in capabilities for the diagnostics and monitoring of microservices, such as logging, metrics, tracing and message correlation."

Editorial standards