Microservices Or Monolithic Architecture?


Microservices are a mystical evolution to APIs.  You won’t find a concrete definition in books and there’s no accurate architectural model for reference.  So why is this concept shrouded in mystery?

For years developers have become accustomed to ‘monolithic’ applications.  These applications contained all the necessary functionality and integrations to be considered ‘stand alone’ and for the most part represent how many APIs are being designed today.   In properly designed applications there is little to suggest that there is anything wrong with this approach for most uses.

Recently some of the big names in the industry such as Amazon, eBay, Netflix, Twitter and a raft of Government websites have taken an evolutionary journey from monolithic APIs to microservices.

What Are Microservices?

You won’t find a concrete definition anywhere on the web and every vendor of API or integration technologies gladly offers their own marketing hype opinion on the matter.

Microservices ArchitectureOn the left is the YourAPIExpert architectural model and description of microservices.  In broad terms a microservice is an API but one with very different design goals and architecture.

The purpose of a microservice is to decouple functionality from the main application.  As opposed to a monolithic application where functions are integrated in to the application a microservice seeks to disintegrate this functionality.  In doing so the microservice presents a modular architecture which can be distributed and reused by other applications.The modular nature allows developers to place sometimes singular functions within a microservice.  Generally developers would design a microservice to provide coverage for a range of related functions (such as sending and receiving SMS’ via HTTP and SMPP).

Because of this microservices are simplistic in nature.  They do not concern themselves over their function or purpose in the grand scheme of the application.  They know only their immediate function.  It is up to the architect and developer to purpose the microservice and make use of it in their design.

However because the microservice is an API, albeit of a different design, it presents a standard interface for use by upstream callers.  In enterprise applications microservices are bound to a common message bus or are accessible from a  standard interface.  On the left I have architected both although the preference is to make use of a message broker (bus) which is a whole topic in itself.

Depending on the type of message broker you will be faced with a different protocol such as JMSAMQP or any number of other variants.  Suffice to say being a different protocol type it does not lend well to native access by HTTP which is the underlying transport of RESTful APIs.

With careful planning, design and implementation a microservice can be directly integrated in to an API but my preference is to facade the northbound interfaces with a ‘microapi’ integrating to the southbound microservice.  In doing so a microapi provides a number of useful beneifits including the orchestration of one or more microservices as well as required security and policy enforcement mechanisms.  Albeit an API the design of a microapi is somewhat different requiring interaction with the message bus and one or more messaging patterns in order to provide true distributed and robust functionality.

Microservices evolve your API architecture to the next level and provides means to distribute and scale your application in any number of directions.  Beware however of subscribing to vendor definitions and transparent attempts to sell technology to solve the ‘problem’.  Monolithic applications are not a problem if designed properly so buyer beware.

Was This Helpful?
All of the content on this site is presented without advertiser support and is produced exclusively by me. If you find any of this information useful please consider it against the cost of a course or book.

I gladly accept donations of any amount which goes directly towards producing more quality content and videos for this site.

[wpedon id=119]
Written by YourAPIExpert