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

I would like to tell you a story about going into microservices architecture. This will be also the story about why JLupin Platform has been created. I believe that this the best way to tell you what JLupin is and why it provides some functionalities and tools.

Let’s start !

At first you should ask yourself the basic, but very important question:

Do I need microservices architecture at all ?

If you are not already convinced to design distributed applications I recommend to ask yourself a set of additional questions:

  • Do I need scalability in ma app ?
  • Do I need flexibility in terms of implementing changes ?
  • Do I need high performance and reliability ?

If the answer for at least one of these questions is YES, definitely it means that YOU NEED MICROSERVICES ARCHITECTURE and you should keep reading :)

.

.

.

OK, so you need microservices, I’m happy about that :)

Distributed architecture assumes that groups of services, usually built around different business capabilities (there are other possibilities, but I will discussed it another time) individually developed, deployed and managed in the environment. In practice it implies that each group of services is an independent application running as a separate process in the infrastructure.

JLupin Platform runs each microservice (application) on separated JVM processes so each of them are developed, implemented and managed individually. Java Virtual Machine has a strong set of capabilities of managing resources and acts for JLupin as a container for user's applications.

Those groups of services are in relation with each other (before splitting into microservices it was an one big application – a monolith) to provide a consistent set of user services (like https://netflix.com). This is a kind of challenge for design and development to keep communication patterns known and manageable. Some support coming from development tools would be very valuable, don’t you think ?

JLupin provides Development IntelliJ Plugin that organizes (but allows also to customize it through editable templates) project space where microservices are developed. What’s more and probably most important it visualizes all microservices with communication patterns between them.

Let’s go back to microservices, each of them is a piece of code that needs runtime environment. Whatever language you choose - Java, Groovy, Scala, Kotlin or Java Script – you need application container to configure and run it properly.

JLupin Platform provides its own application server - JLupin Microserver used for NATIVE microservices. It runs Spring IOC container to configure your code, it has new improved class loaders and the lowest runtime footprint. JLupin Platform also supports SERVLET microservices based on Spring Boot, with all it's features and benefits.

After you choose the language and the suitable for you runtime environment the coding is coming :) This part of the story will be skipped to the next one - deployment in the infrastructure. It should be easy and directly triggered from your development tools, am I right ?

JLupin provides Continous Integration Maven Plugin that helps a lot keeping project space configured and ordered properly but also is capable of deploying your microservices onto JLupin Platform locally as well as on remote nodes.

So you have a couple of microservices, ready to deploy on the infrastructure, you have even tool that is ready to do it for you but... you need the server-side peer that is ready to receive your piece of work and manage it's life cycle as a process in the infrastructure.

The heart of JLupin Platform is Main Server that is running on each node. It receives microservices from deployment tools and through internal process manager starts / stops (manages, in general) microservices in the infrastructure.

Finally you managed to deploy all your microservices in the infrastructure... but they are not just processes, they are service providers ! Did you remember to set your services as external ones through specific protocols ? What about asynchronous requests ? Binary vs. textual (HTTP) - which to choose and which right ?

The heart of JLupin Platform - Main Server automates providing services in the environment through automatic interfaces. Each NATIVE microservice is automatically, out-of-the-box accessible through (a)synchronous interfaces. SERVLET microservices (Spring Boot) provides their services by their own (HTTP interfaces) but under control of Main Server (ports, application properties).
JLupin Platform provides JLupin Binary Protocol for communication with NATIVE microservices. It's enabled by automatic interfaces and is used for synchronous as well asynchronous requests. Due to its little overhead it ensures high performance computing even in large distributed environments. You don't have to worry about number of interactions between microservices any more :)
JLupin Platform provides HTTP Elastic API that along with binary ones is enabled by automatic interfaces and is used for communication with NATIVE microservices with HTTP protocol. 'Elastic' word comes from ability of using JSON / XML format in different use cases, it's configured on the fly in HTTP headers. It's enabled by default and out-of-the-box with binary interfaces.

OK, so you have plenty of microservice running on plenty of servers in the infrastructure... each of them provides set of services, some of them communicates with each other and need addresses, ports, etc. ... how can they find each other ? You can configure it manually, but you feel that you need something more automated... service discovery.

JLupin Platform performs Service Discovery process to built complete and up-to-date database of service catalog in the environment - service repository. In case of JLupin Platform the service repository is distributed - each node builds its own vision of the environment. In that way we don't have single point of failure !

After implementing service discovery, those plenty microservice are able to communicate with each other without specific operational effort, but... how to deal with many instances of each microservice in terms of balancing and fail-over in case of an incident ? Yes, we need load balancers, we need to ensure high availability and reliability in the environment. Distributed, self-configured software load balancers would be perfect... don't you think ?

JLupin Platform provides JLupin Software Load Balancers included in every microservice and Main Server, which perform efficient load balancing in distributed, cascade architecture, with built-in customizable health checking, retrying mechanism and circuit breaker pattern handler.

Great ! Now you have almost all crucial component needed to run application in the distributed, reliable and high performance environment. As we agreed in the beginning (didn't we ? ...) microservices are the way of providing consistent set of user services. The question is how to do it, after splitting application into several distributed in the infrastructure, automatically managed, individual pieces ? You need a point in the infrastructure to easily access user services. You need something smart on the edge of your system, in other case the integration with the rest of your environment will be hard.

JLupin Platform embeds JLupin Edge Balancers on each node to ensure simplified and reliable access to services through HTTP. Due to Edge Balancer, JLupin Platform is seamlessly, out-of-the-box integrated with the environment at the edge of the system. You can access complex microservices system, just like a monolith.

I think, you are ready to deploy and run your app in microservices architecture, good luck ! If a couple of changes will be needed in the nearest future in your app and you wonder how to do it online, without interruption you should keep reading :)

.

.

.

OK, the time of changes is now and the constant flow of business requirements is active :) Yeh... I know... but there can be a little help from the environment. You need 'Zero Downtime Deployment' mechanism which ensures that an upgrade is online even if the newer version will fail. You can prepare it by yourself, it's a lot of work to do it properly, fortunately there are different options too :)

JLupin Platform performs True Zero Downtime Deployment which takes all kind of processing into consideration - synchronous, asynchronous and initiated on dedicated, custom thread pool. You can even perform 'True Zero...' in case of stateful microservices (if you use HTTP session respoitory). The mechanisms is very safe, it start a new process and only after if it's started properly - it is activated and the previous one is destroyed.

Now we are very close to the system maintenance and anything that could suddenly and unexpectedly happen. Many processes on many servers, it's really hard to react to every single failure (even JVM sometimes crushes), I would be very useful if some mechanism will help us keeping it up & running, even if well-known JVM erros occurs (OutOfMemory, Stackoverflow).

JLupin Platform performs Self-healing actions to take care of microservices. If one of them disappears, it will be recovered automatically. If OutOfMemory or StackOverFlow exception occurs diagnostic data will be collected while another instance of failed microservice will be started and activated. The point is to keep service up & running as long as possible.

Usually, systems in microservices architecture are under heavy development, because they are critical for many business processes (their functional capacity are much bigger then monoliths). A lot changes, especially implemented concurrently means a lot of opportunities to make mistakes in code... we are just humans, it's normal, but we are supposed to find and fix them as fast as possible. That's a kind of challenge for distributed environment - how to find the source (root cause) of the problem ?

JLupin Platform provides built-in Remote exceptions tracking that help to identify the source of the problem. In the final exception stack trace you will find IP address and name of the microservice - the origin of the error. It significantly shortens the process of identifying those components of the environment that need a fix.

Our journey through microservices architecture in action is going to the end. I will be very grateful if you remember one thing - JLupin is focused on comprehensive solving DEV problems while simplifying OPS activities. That's our mission. Would you like to see if we are succeeded ?