Understanding micro-services architecture used in JarPlay class technology

published on 26 Dec 2021 written by Kyaw Zaw Win

In JarPlay, we see micro-services as a distributed development and deployment architecture of building strategically designed scalable software products.

Overview of our streamlined deployment and deployment process using JarPlay class technology

Overview of our streamlined deployment and deployment process using JarPlay class technology

The image is available as collectible item on Opensea NFT marketplace.

In the past, software was made on monolithic architecture which is tightly coupled between modules, during development and deployment process. The architecture itself is good, in the past of software development industry where Software As a Service was not popular and scalability was not an issue, beyond the limitation of vertical scaling, challenges of maintaining software and fast growing remote workplaces where short and effective communication plays key factor to success of delivering software that works as expected.

In short, micro-services architecture is used to make a software distributed and horizontally scalable, not only in deployment but also in development.

In addition, each micro-services are small enough compared to one big chunk of project and each service does its own purpose.

What does it mean?

It mean readability of the code has improved, code are more documentable because developer can solely focus on module which belongs to them and more importantly, clear separation of ownership and responsibility between modules.

So what is wrong with vertical scaling?

There is nothing wrong scaling a software vertically. However, there are 2 main things we find disadvantages of doing vertical scaling in JarPlay.

  1. Hardware is cheaper but it is not true for CPU and RAM which are most expensive part of a computer system. Every software needs better CPU power and enough RAM to operate efficiently on compute system as it scales. The cost factor of CPU and RAM for scaling between vertically and horizontally is quite different, even in cloud service provider pricing plan. In most cases, you may find buying 16x small instances with 1vCPU compared to one big instance with 16 vCPU is cheaper and easier to maximize the utilization of base line cpu and cpu credits with added advantages of auto scaling ability and reduced power consumption, i.e auto scale instances are not in operating mode when the demand is low. Moreover, we need to take into consideration of OS limitation, third party library limitation and application limitation to utilize available higher computing power and memory. The main point is that “doing one thing at a time is simpler and more effective than doing many things at the same time”.
  2. Development should be fast and effective. There is no excuse to make developers become angry waiting minutes for IDE to load because of the project size has grown, or making the same mistake and overwriting someone else's shared library code and breaking things and ends up finding and rolling back commits. All in all, the whole software system should not go unreachable if part of the system is down, which is totally up to deployment strategy that relies on flexibility of application architecture.

In JarPlay, we designed our software as modular services, built on top of micro-services architecture which has a seamless api based protocol to communicate with each other, known as JarPlay Class technology. Moreover, we can wrap all module services in one bundle and deploy as monolithic software in UAT staging deployment in order to avoid unnecessary cost, which infrastructure is designed almost similar to the production environment using lesser computes.