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. These integrations were commonly compared to the connection between two Lego blocks.
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.
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. In other words, if integrations among monolithic systems are legos - limited and rigid, microservices are like string theory - numerous and flexible.
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.
Moving to Microservices
The move to microservices is not slowing. With the likes of Amazon, Netflix, and eBay, who historically used monolithic solutions, moving to microservices, many are following suit. Google Trends shows the terms “microservices” and “microservices architecture” only increasing in popularity over time. And, as many companies seek agility in implementation and change, you can expect to see a large portion of traditionally “Build it Yourself” companies taking a “Not From Scratch” approach with Microservices. For many, it has become clear that the Lego doesn’t cut it anymore.
Contact: JoAnn Martin, [email protected]
