Design

Breaking an App Apart into Microservices

At NUKU our technology architecture is made up of many microservices, which are separate, uniquely functional applications, each providing a specific service, each on its own cloud instance and inter- and intra-communicating via Restful JSON APIs. This decoupling makes for a fast, efficient development process, as each application is individually, and generally solely, worked on. It also simplifies debugging, and allows for more focused scaling where customer demands are the highest.

A microservices architecture is service-oriented, with loosely coupled, but functionally focused applications

I'm often asked, why not have a monolithic application, instead of a micro-services setup? Our experience has found that the microservices setup is far simpler to develop, manage, and deploy. Monolithic design worked in the past, but with ever-increasing technology changes and user demands, its design can't keep pace with development requirements of today.

When its comes to ongoing development, a monolithic application requires more coordination between developers, and code pushes often result in merge issues that have to be resolved, all of which takes time. Often, changes to a monolith have unintended consequences, with errors that need to be ferreted out. Tests may identify the errors, but the programmer then has to determine why their code impacted components elsewhere in an application.

At NUKU, clients access a front-end application to view their accounts, which pulls information, such as holdings, market prices and research, from internal microservice applications, all via Restful JSON APIs.

Monolithic design worked in the past, but can't keep pace with development requirements of today

With a microservices setup, each application that requires development has a clear purpose--a function that is not replicated elsewhere in the system. Designating a programmer to develop or fix a piece of code in an micro-services application starts with a clear-purpose, since its already well-understood what the application should be doing. A programmer can be asked to work in a CRM application, to develop outgoing emails.

With a microservices setup that relies upon APIs, a programmer needs to only pay particular attention to the API input and outputs, since those are the interactions with which the rest of the system depends.

How to move away from a monolithic application? Identify keep components that are significant enough to be a microservice. For example, user information, which would include everything about your users, such as name, address, login credentials etc., could be a separate service. Start by developing the microservice application, and design an API for accessing all of the information. In your monolithic application, add in the connectors where you will make an API call to your new User microservice for user information. All of the old code in your monolithic application related to user information will no longer be used.

Repeat this for other major components and you will be on your way towards a microservices architecture!


Carson R Cole