• Rating:
  • Views: 101
  • Author: JLupin
  • Comments: 0

Step 0 - entering the world of microservices...


If you reached this page you probably want to migrate your monolith to microservice architecture or your are approaching a big project and you know (or feel) that microservices are that you should take into consideration.

WELCOME ON BOARD !

There are plenty of different approaches, platforms and ideas regarding this architecture. From philosophy to technology, from Netflix, through Docker and cloud environments to application components. One thing in microservices is common - it is all about business agility and scalability as well as service availability. In our opinion, basing on mentioned technologies and solutions, the cost of entering into microservices is definitely too high.

From technological and architecture point of view the first steps into the microservices are:

  • divide your code into functional separated pieces,
  • configure new pieces of your code as separate applications, configure as services and run in the environment on separated processes,
  • establish reliable communication between your applications and provide access to clients.

We're going to show how to do it quickly and smoothly, on one consistent platform that provides necessary components for microservices as well as monolith (and that's the key !).

Heavy infrastructure stack is no longer needed on the path leading to microservice architecture implementation.


Step 1 - dealing with .war

I bet that you have at least one .war (let's call it app.war) with your application - your monolith, THE MONSTER !!! I'm joking :) Monoliths are cool, when functional complexity is low and there is little integration with other services in the IT environment. In case of any other circumstances think about your application in "microservices style" from the beginning.

OK, let's go back to app.war... the first thing you should do while preparing your application to be sliced is to "micro pieces" is migration on application platform that is capable of handling multiple applications (microservices) as separated processes, with reliable communication bus between them. With JLupin Next Server is very easy:

  1. embed your WAR into Spring Boot (our plugin can help with ease)
  2. archive the SpringBoot WAR file with microservice configuration (YAML file, detailed described here)
  3. upload it to JLupin Next Server ('microservices' upload will help, go here to read more about management capabilities)
  4. run it (microservice start <name>)
  5. enjoy it :)



Benefits of doing it on JLupin Next Server:
  • enhanced management
  • zero downtime deployment
  • professional support
  • powerful IDE enhancement


Step 2 - going back to good practices

A couple years ego, before Spring became so popular, large, enterprise systems where built in 3-tier architecture with separated presentation layer. In microservice architecture this approach has its second life, but now "presentation layer" is called "API gateway". So, the next step in process of slicing your application is: separate your client's API and resources from your business logic.




In that way your WAR (let's call it microApp.war) is becoming what it should be - web application performing the following functions:

  • API unification / transformation (if applicable)
  • Web resources (if applicable)
  • protocol translation
  • authentication
  • session management

On JLupin Next Server the business logic are deployed as set of POJOs configured by Spring IOC and archived as a microservice (let's call it microApp.jar) and exposed as services through Main Server. The communication between API gateway / Web layer and the new microservice is done through built-in load balancer and binary protocols (well, http is no longer necessary to exchange data between microservices).


This is the great starting point from which crucial part of splitting your application into microservice begins.

Another benefits of doing it on JLupin Next Server:
  • binary communication for high performance
  • distributed load balancers for high availability
  • automatic interfaces
  • queues
  • self-healing actions
  • multi threaded timers
  • asynchronous subsystem execution
  • enhanced monitoring


Step 3 - going into micro scale...

Now you are ready to go further and start gaining business benefits coming from microservices. The are plenty of ways of splitting monoliths into microservices and usually some of them are used simultaneously. We are going to show some basic examples to discover its advantages, but please remember that the best way of splitting your code depends on the complexity of your application and the goals that you want to achieve by going into microservices.

The first "split vector" is based on business domains. This is a classical approach that is applicable for most cases and is suitable for the first split. Let's assume It consists of three basic business domains:

  • BDom1 (ex. Product)
  • BDom2 (ex. Customers)
  • BDom3 (ex. Orders)

Let's split these domains and provide those into IT environment as separated applications (microservices).



At this point we should decide where aggregation functions are located (well, users usually request access not only to one of these domains, their view consists of the mix of raw or processed data from each domain). It could be centralized in microAppWeb.war or spread over business microservices - it's up to you.


Another benefits of doing it on JLupin Next Server:
  • communication is very similar as for local references - your work with microservices on JLNS is like dealing with modules in monolith - it's easy, it's transparent. It's possible due to built-in service repository in JLNS,
  • the whole development environment can be easily deployed on your workstation, no additional components are needed,
  • you can use asynchronous requests and queues to improve processing, without implementing additional components and mechanisms,
  • your code is exposed as services automatically, without additional programming effort.


Step 4 - from full mesh to multilayered microservice architecture

If you don't feel comfortable with "full mesh" communication patterns or putting business aggregations in web layer / API gateway or you are facing the challenge of providing services in additional distribution channels (web for clients, web for branches, partners or backoffice and mobile for clients) you probably need to separate this functions and run it as microservices.

We assume that some of the aggregations function are common for all distribution channels and there are also specific ones for particular channel. To provide flexibility in scope of changes in channels and operational separation we should reflect this "business streams" as independent applications - microservices, as shown om the following figure.


Another benefits:
  • This is the most important JLupin Next Server benefit from user's perspective - you can run as many microservices as you need without increasing the cost of environment and its complexity. With our IDE enhancement you will control the architecture from the stage of designing and development.
  • The prepared architecture can be easily deployed on production and spread over infrastructure, configured in zones and managed by JLupin Control Center.


Step 5 - the sky is the limit

There are many ways of splitting application into microservice architecture, choosing the best one for you depends on your goals and specific of the business. The most important thing is that with JLupin Next Server you can smoothly implement the most sophisticated microservice architecture without compromises. From running a monolith, through adding new functionalities to the system as microservices, to the final step - splitting the monolith. Go for it...

Go for Unreachable, with JLupin Next Server.