Technological complexity in a Micro Service App

Technological complexity in Micro Service architecture

The raise of Micro Service has increased Technological complexity outside of the pure, logical and real need. Real need really means – how much users or “calls” an app, web page, service or functionalities has. A site that is not accessed in an hour or in 24 hours more than 100/1000, sometimes even 10 000 users (for 24 period), doesn’t need any special care for scaling . It does not mater with what technology it is programmed with when logic complexity is minimal.

Finding Your Use Case

Many websites – especially that have static or close to static (rarely changed) web pages – does not have very much visitors. They does not really need scaling. That is why WordPress is so popular. The real scale hits after webinars and promotions. They could be resolved by the several levels of caches – HTTP Headers, Client Side (SW), CDN and many more.

Finding the Critical Module

Big and Fat apps start slower, are harder to scale, but have only internal complexity.

Very micro serviced app has less internal complexity and could easily scale any micro module, but – sometimes are harder to orchestrate. Some of the complexities come from the cloud provided features and their intermingle with the old approaches and the real business requirements.

It makes sense sense to separate features into modules and Micro Services that:

  • Are called a lot of times
  • Take more time to finish
  • Occupy a lot of resources
  • Are potential security doors (because of 3rd party module or feature)

Endpoints that are hit a lot could be scaled up horizontally, when they are architected properly and all of the optimizations and vertical scaling are depleted.

Features that take time could be isolated, so the main app does not suffer. The modern approach is also – having reactive back end, so neither the back-end nor the front end is blocked.

If your main app does not require a lot of resources, but some small feature will occupy a lot, it makes sense to externalize it. One such feature is the file storage.

Processing files in general is potential security hole. In some cases the work require using external libraries, so that is another risk.

Less often serving static files or read only databases require scaling. Many times, if the platform allows it, caching the data or processing results in memory minimizes the need for horizontal scaling and introducing the need for dev-ops. Managing containers, virtual servers, dev-ops is required for corporate software and business to business contracts. Some side of the negotiation already knows what are the scaling needs and pain points.

Leave a Reply

Your email address will not be published. Required fields are marked *