As is the case with many enterprise applications, business process management (BPM) has evolved over several decades....
Once a monolithic solution with baked-in user directories, rules engines, messaging backbones and the like, modern installations are more modular assemblies of Web services and interoperability mechanisms that let you mix, match, leverage, and extend their capabilities -- even as you leverage those provided by your various other software stacks.
Perhaps the latest incarnation of this trend involves so-called "microservices," which today are capturing the imagination of many IT professionals as the newest key to enhancing the efficiency, flexibility and cost-effectiveness of application development.
Many people -- me among them -- believe the growing ruckus around building microservices is much ado about something that has been around for a while. Others, meanwhile, swear it's the next, next big thing. Either way, microservices do promise to take BPM componentization to the next level and enable the wringing of extra benefits from what by all rights should be a tired technology by now.
Microservices in a nutshell
Broadly speaking, microservices are highly specialized versions of the "regular" services that are at the center of our familiar cloud- and SOA-based apps. Crafted to provide only one capability each, they are carefully aggregated and orchestrated in order to deliver a specific collection of functions. This is why, to me, they represent but the logical next step in the journey from monolith to module.
From a development standpoint, the list of advantages associated with building applications by building microservices is rooted in the isolation of individual capabilities within individual microservices. This opens the door to a number of notable improvements, including the following:
- Each microservice can be developed, tested and deployed independently of the others, potentially shortening the project's critical path and, thereby, saving money.
- In similar fashion, application fixes and updates can be applied in one functional area without affecting any of the others, thereby simplifying lifecycle maintenance.
- Further, particular developers can be assigned to work on particular microservices, allowing them to cultivate distinctive sets of expertise and facilitating the deployment of their skills across projects as needed.
If you've been around long enough to remember the advent of object-oriented programming, then you may well be thinking that these benefits sound awfully familiar -- in which case, you'd be right. The difference, such that it is, is that the objects represented by specific microservices are a lot "cleaner" than programming objects generally are, which is to say that they are intended to do one thing, do it well and then move on.
So, what does building microservices mean for BPM?
Benefits for BPM
BPM applications typically are highly complex, as they often need to accommodate wildly different user devices, several generations of database and document technologies, multiple media types and uncertain bandwidth capacities (to name just a few of the myriad considerations). Further complicating matters is the fact that they also have to do this while constantly being adapted to address changes in your business environment.
As noted, the move toward modularizing BPM has already paid great dividends by loosening the bonds that connect the various capabilities, and the intelligent use of microservices promises to make them even more pliable than they are today. For instance:
- Microservices may enable what in a practical sense may be thought of as the "streaming" of functionality on demand. Unbundling specific functionalities from one another can open the door to anticipating and preloading process next steps in the same way that Web pages get queued up. As with airplanes approaching a major airport, which ones are actuated in what order depends upon the conditions on the ground (or in the workflow), but they are there ready to move as soon as the word is given. (See my recent article on single-page applications for an interface-related take on this.)
- Insulating the moving parts from each other also promises to mask process interruptions. For example, online storefront packages often "hardwire" their back-end transaction processing capabilities to their customer-facing front ends. In these scenarios, a problem in the back typically cuts off the ability to accept information from the front, thereby closing the store for business. However, deconstructing the capture and processing functions into two independent microservices would allow customer information to be collected even if the processing piece goes down. As such, the store would appear to be operating as usual, and the back-end issues would remain a dirty little inside secret.
- One of the givens of modern life is that nothing is constant except change itself. In business process terms, this means that no matter how carefully you have mapped out your workflows, you probably will have to do it again every so many years as, say, new laws require that new forms of audit information be collected, or merger/acquisition activity changes your process landscape. Building microservices as an approach to BPM development means you can add new capabilities without having to amend the core application, a flexibility that reduces the technical difficulty and risk of regulatory noncompliance even as it reduces cost.
Sound good? Well, it is. But no innovation comes without at least a few caveats, so let's take a quick look at some of these.
What's the catch?
Competitive pressures today mean BPM has to do all it does more quickly and efficiently than ever before, a reality that can cause organizations to rush to embrace what they see as the "latest and greatest" without really thinking their situations through. Although microservices are chock full of potential, there are several qualifications to consider before jumping on the bandwagon with both feet. For instance:
- Standards are still emerging to govern how microservices talk to each other. Web services experienced this same dynamic back in the early days of that technology, so this is not unexpected and it isn't really problematic. However, making a premature commitment to an approach that ends up falling by the wayside can be unpleasant; so, if you like the idea, it may be worth getting involved in some standards-oriented activity.
- Separating strands of functionality into individual microservices is appealing for the simplicity each strand embodies. However, the need to call a greater number of them to accomplish a particular task means that if something goes awry, there are that many more places to look in order to find the one at fault. Here is where the ability to test each one on its own can be helpful, for it may help isolate problems before they arise. But there is a more complicated flip side that needs to be considered as you proceed down this path.
- And finally, the nature of this particular beast makes it even more critical to think through what your process is, who engages with it, and what tools and systems it needs to interoperate with. Your theoretical goal here is to distill each function into an independent microservice, although I suspect there is a practical limit to how granular you can get before you run into the law of diminishing returns. But you still have to make the effort if you want to reap anything near the level of benefit that attracted you in the first place.
Whether you consider them to be outright revolutionary or merely evolutionary, microservices clearly are emerging as the next step on the journey from monolithic to modular BPM application development. As was the case when Web services and SOA-based applications burst on the scene, you have to figure out how useful they may be to you, and where that utility may be maximized. Only then can you determine whether it should be your next, next big thing.
Find four reasons you should consider leveraging microservices
Learn how microservices is brining agility to SOA
Learn what the heck microservices really is
Understand the challenges of testing microservices, RESTful APIs in the cloud