Migrate from monolith to Micro service architecture

Question

We are on the initial stages of designing a micro service for my client from their standard monolith app that is sitting on 4 JBOSS servers in their own data center. Is micro service architecture target at only cloud based deployment? Can i deploy a micro service on premise production ready tomcat /JBOSS? Is that a good fit?

Answer 1

Sure you can. Microservice architecture is a concept of having many small interracting components, where each of them performing well defined part of work, but good.

It's extention of the Linux way and the concept of decoupling components.

In your case you can split your service to several smaller services. Each one with own development and deployment cycles, each one with well defined API.

Answer 2

Is micro service architecture target at only cloud based deployment?

no it's is an architecture for application development. basic idea of micro services is separate complex application function to small functions to reduce complexity and get high performance. there are few reasons you need to consider before moving micro services.

• 1.scale of you application.

if your application contain high number of complex functions its better go with micro services. and separate them and deploy separate, then easy to do changes and maintains.

• 2.performance of application

if some application function need high computing power. you can allocate separate hardware resources. if you implement it as micro services.

• 3.deploy and maintain

  if you use micro services you can deploy and maintain service separate without effect other services.

• 4.data migration

if your databases contain high data table relation it will little bit difficult remove for function databases(each micro services need each DB) so as a first step keep DB as monolithic and separate function to services. then start to reactor DB

• 5.call each services

  fronted end application keep clean and logic free. and wrap your micro services using API gate way and publish all the services as one service.

• 6.application security

each and every services running in separate no need to session tracking use JWT (oAuth2) API security.

• 7.multiple services & transnational

if you need to handle one business function but with more than one service you need to check each and every services function work correctly**(ex db operations ,rollbacks)** so need to developed transnational handler

• implementing micro services

there is no specific technology stack for it but there are free more technology available ex :

1. java spring boot for micro services (with inbuilt tom cat server )
2. zuul , eureka for API gate way

3. oAuth 2 and JWT for security

   • *Note

there is not fix way to implementation for micro services , use correct technology stack to get performance and implement small business function. and doesn't matter hosting in cloud or local servers. strong text

Answer 3

There is definitely no limitations whether you deploy your microservices on local, physical servers or in the cloud. Both approaches are valid, but they impose different advantages and disadvantages.

With local/physical servers, you will have:

• bigger operations overhead (it is better you have good DevOps in your team)
• manual scaling (when you experience bigger traffic, you need to manually fire up new instances, or use some management tool for this)
• manual fault detection - if a server goes down (this depends on your/company's server enviorenment) someone will need to fix this "manually"
• it is cheaper (a friend is buying old server instances on Amazon and running their semi-microservice architecture on them, he calculated they achieve quite big savings this way)

With cloud infrastructure, you get some of the below advantages (in contrary to above disadvantages):

• less operations overhead (the cloud will take care of most of operations)
• flexible scaling (when your traffic goes up, cloud can automatically fire up new instances, when it goes down, it will shutdown instances)
• error/fault handling - if there occurs a problem in the cloud, you do not need to worry

I did not mention all the advantages and disadvantages of given approaches, as it also depends on the project (will it receive different traffic on different times of day, does it need to keep data locally or can it be in a foreign country in a cloud, ...).