Author: Paul Thomas
In the not so distant past, enterprise computing relied on monolithic applications to provide access to business functions within an organization. These applications strove to meet all operational requirements through rich and ever-growing feature sets—think ERP systems.
To meet evolving and expanding business demands, developers of these applications continuously added features and functions. And, when the development cycle could not keep pace with demand, integrations among monolithic applications became the norm.
As the monoliths grew, so did their impacts on the agility of the businesses that relied on them. Often these systems, due to their nature, forced business to implement processes according to the software's capability, rather than the needs of the firm. If a process crossed an integration boundary, organizations could not implement changes that would negatively impact integrations. Further, once an integration was implemented, it was rigid and brittle. In other words, changes were difficult, if not impossible, to make without potentially breaking the integrations and the applications.
Organizations tolerated the inflexibility of monolithic applications because the technology of the time did not support an alternative. However, forward thinking technologists and business strategists consistently and diligently worked toward a better, more flexible approach that would allow technology to meet business functional requirements.
Making the move to microservices?
This overview of microservices in the financial services industry will light your way.
Exposing Business Functions as Services
More recently, the concept of Service Oriented Architecture (SOA) emerged as a means to fulfill the promise of business application flexibility. SOA leveraged the phrase “loosely coupled” to describe a solution that would provide critical business functionality while allowing for a less fragile and less rigid integration framework.
The combination of standards-based services that relied on Web technology allowed for less brittle integration while improving agility. Two of these standards, Service Oriented Architecture Protocol (SOAP) and Business Process Execution Language—the definition of a means of integrating and a language to implement the orchestration of these integrations—were adopted by many enterprises and software vendors to help implement loosely coupled integrations.
While these early implementations of Web Services offered a more flexible environment, it soon became apparent that they were relatively heavy weight and somewhat complex to implement and maintain, so the quest to find lighter weight services continued.
Emergence of Microservices
Recently, you have, no doubt, encountered the term “microservices.” Based on light-weight, fast, internet protocols, Microservices are starting to seem like the fulfillment of the SOA, loosely-coupled promise.
There is no standard, formal definition of microservices. Microservices, rather than being a definition of a standard or protocol, is a description of a concept. In general terms, the phrase 'Microservice Architecture' describes a business application developed by orchestrating a set of independent, small, modular services. Each of the services is discreet and is intended to run a specific business function. When called during orchestration, each service is reached using a lightweight communication mechanism (often an HTTP resource API), and each service is designed to serve a single business goal.
One design goal of a microservice architecture is to break down a monolithic application into its constituent, business-function parts. This simplification is referred to as "decomposition". The result is a set of discrete, reusable services.
Decomposition breaks applications down into, essentially, service end-points designed with one particular purpose. In the loan origination domain, for example, a scorecard service, an age calculation service, or blacklist checking service, is developed and exposed for use in building a decisioning process. These services can then be used as part of a larger overall flow as needed.
Benefits of Microservices
As stated, the largest promise a microservices architecture presents is agility. But other benefits are becoming apparent as well, such as scalability, ease of testing and deployment, and a relative ease of enhancement and maintenance. In a computing age where user demands and technological capabilities keep evolving and growing, the more flexible, responsive approach to building applications in this uncertain but rapidly-evolving tech future.
Additionally, the composed – rather than dependent – nature of a microservices architecture enables business analysts and developers to understand the functionality of a developed process or service better since they are isolated and discrete. The nature of microservices also improves “fault isolation,” meaning larger applications will not be affected when a single module fails.
Provenir Fully Supports a Move to Microservices
Future Provenir customers who choose to implement microservices make it a point to evaluate potential software solutions based on the software’s ability to support the conceptual architecture. When Provenir Platform is measured for fit, it becomes apparent that Provenir fully supports a move to microservices.
Provenir Platform has always supported the concept of modularity and reuse. It is core to Provenir’s approach to deployment generally – build once; reuse many times. In the past, the modularity has been within the Platform itself. But now, based on newly emerged technological advances, Provenir supports modularity exposed as lightweight services.
To support the provisioning of discrete services, Provenir provides the capability to create REST-based endpoints for all business functions developed using Provenir Studio. For example, when a user defines a scorecard in Provenir it can be exposed as a standalone endpoint, meaning the scorecard itself becomes a service. Simply pass the required data to the endpoint using REST and JSON, and receive the calculated score back in JSON via REST. Or, as another example, an entire KYC process can be defined within Provenir—including OFAC checks, blacklist checks, calls to third-party data providers—and this process can be exposed as a service. Just pass the customer’s identifying data to the service and get a “yes” or “no” back.
Overall, our prevailing mentality remains to build, but not from scratch. This approach comes from our knowledge and experience in system architecture and the understanding that successful companies should be afforded agility in implementation and change. In other words, our customers should be able to move the Lego blocks as they need to.
Build it Yourself, but Not From Scratch