The Reality of Microservices in the Enterprise
Microservices are nearing the peak of inflated expectations according to Gartner. Every organization has this word on the top of their vocabulary, but few understand the implications. This trend is far more pronounced than any other application paradigm I’ve seen in the last decade. The most worrisome part of this latest fad is the lack of understanding as to how leveraging this new design pattern affects every part of your culture, people, organization, and processes.
Most organizations have been experimenting and moving toward DevOps teams owning specific services throughout the lifecycle. These new initiatives focus on new products which are more so green field that can be designed, built, and run with a modern DevOps mindset. The biggest challenge is having the right people and skills and ends with culture. That means shared responsibility, everyone being on call, and sharing the ownership and pride of the product.
The Miniservice-stepping stone makes a lot more sense for the enterprise that isn’t ready to restructure its data environments to build decoupled Microservices.
Even with these trends becoming pervasive, most enterprises stay far away from re-architecting their data platforms. Microservices require that data is coupled with services, and not in a large shared central repository. If your service relies upon a system of record (Mainframe, Oracle database, SAP system, and others), then your Microservices do not fit the definition.
The challenges of data re-architecture, reliability, and having to be compatible with legacy and modern systems are hurdles for most. Tight coupling creates elevated risk making the strategy far from smooth or safe. Many times when this accomplished it’s via the use of message queues and massive amounts of moving parts to keep the data repositories synchronized.
Gartner has been seeing this trend throughout the rise of Microservices hype, and have coined and began writing about Miniservices. These are SOA done right. Most end up building service wrappers, add discovery, governance, and other capabilities top of smaller services without the burden of an SOA framework to provide the best of both worlds without the burdens attributed to SOA projects in the past.
The Miniservice-stepping stone makes a lot more sense for the enterprise that isn’t ready to restructure its data environments to build decoupled Microservices. Although Miniservices users do not get all the benefits of being decoupled, building services on top of legacy systems can at least help part of this. The downside is that the complexity will continue to increase, which will add cost and quality issues as these two paths continue to diverge. Most likely bimodal teams have differing strategies around application and infrastructure architectures, which ultimately also cause a bimodal approach to infrastructure and cloud. The new result is a lack of clarity around IT strategy and direction.
By not truly decoupling services there are implications to an organization. There has been no shortage of critical discussion of Gartner’s bimodal IT strategy and research. The goal of bimodal is not to keep operating in that mode forever, but it’s a step of progress on a solid foundation. A phased approach can be beneficial in making progress toward Microservices and DevOps. Although the concept of moving to a pure agile and DevOps organization sounds great on paper, most organizations cannot do this; they lack the talent, funding, or requirements to change many of the legacy systems which currently operate the day to day business.
The consequence of these strategies is the complexity involved both technically and within the organizations. Communications, standards, and culture will suffer. Having the right visibility across both modern and legacy systems is critical. Although bimodal makes it seem that these teams are independent, they are extremely dependent on one another. Enterprises operating bimodally need to have the right data to identify and isolate issues quickly. Having flexible monitoring technologies which work with both the new and the old is essential.
Monitoring systems must also support both sides of the application and infrastructure architecture. They must be open and extensible, yet offer support for traditional packaged applications. The teams must share and communicate consistently, which is next to impossible when they are using different technologies to monitor and provide visibility. Sharing the current service levels and architectures are required to enable the governance necessary when operating an agile business.