Tag: microservice

Micronaut java full stack Microservice Framework!!

Micronaut is a modern, JVM-based, full-stack microservices framework designed for building modular, easily testable microservice applications.

Micronaut is the latest framework designed to make creating microservices quick and easy.

Micronaut is a JVM-based framework for building lightweight, modular applications. Developed by OCI, the same company that created Grails. Micronaut is developed by the creators of the Grails framework and takes inspiration from lessons learned over the years building real-world applications from monoliths to microservices using Spring, Spring Boot, and Grails.

Micronaut supports Java, Groovy or Kotlin.

Features of Micronaut:-

One of the most exciting features of Micronaut is its compile-time dependency injection mechanism. If you know the spring-boot mostly using reflection API and proxies which is always at run time and that causing the spring boot application needs a more startup time as compared to Node application. 

  1. First-class support for reactive HTTP clients and servers based on Netty.
  2. An efficient compile time dependency injection container. 
  3. Minimal startup time and lower memory usage.
  4. Cloud-native features to boost developer productivity.
  5. Very minimal learning curve because Micronaut code looks very similar to Spring Boot with Spring Cloud.

What’s wrong with Spring Boot?

Disclaimer 

There is nothing wrong with spring boot. I am a very big fan of spring projects including spring, spring Boot, Spring Data, etc. Spring Boot is a good and very elegant solution and it makes developer job easier than anything, just add one dependency and magic will happen for you. 

When spring is providing things on your fingertip that means spring is doing so many things under the hood for you. Spring does reflection, proxy classes and injection and many more and for this, you have to pay the cost because spring does things at runtime. You have pay in terms of memory, CPU cycles and application bootstrap time.

Micronaut addressed some of these problems using ATC (Ahead of time compilation), GraalVM. Micronaut does major things at compile time that reduces memory footprint and CPU utilization this leads to reduce in application bootstrap time. Currently, spring is not supporting GraalVM and Micronaut is supporting this is also a big difference. 

GraalVM is basically a high-performance polyglot VM. GraalVM is a universal virtual machine for running applications written in JavaScript, Python, Ruby, R, JVM-based languages like Java, Scala, Groovy, Kotlin, Clojure, and LLVM-based languages such as C and C++.

Now we know what is and why Micronaut and a couple of features. Let us setup Micronaut and we will create one simple Hello world application. 

Setup Micronaut?

To install or setup micronaut is a very easy task. Go to this page https://micronaut.io/download.html

Either you can download binary, or use SDKMAN to setup micronaut on your favorite OS.

Using SDKMAN

Simply open a new terminal and start:

$ curl -s https://get.sdkman.io | bash

$ source “$HOME/.sdkman/bin/sdkman-init.sh”

$ sdk install micronaut

$ mn — version

Now installation is done let us create simple Hello world application

mn create-app hello-world

By Default Micronaut uses Gradle as a build tool you can also specify maven as well.

mn create-app hello-world --build maven

Using Homebrew

Before installing make sure you have the latest Homebrew installed.

$ brew update

$ brew install micronaut

Using Binary on windows

  1. Download the latest binary from
  2. Extract the binary to appropriate location
  3. Create an environment variable MICRONAUT_HOME which points to the installation directory
  4. Update the PATH environment variable, append %MICRONAUT_HOME%\bin

Now enjoy the coding.

Let us have HelloWorld controller 

import io.micronaut.http.MediaType; 
import io.micronaut.http.annotation.Controller; 
import io.micronaut.http.annotation.Get; 
@Controller("/hello")  
public class HelloController {  
    
@Get(produces = MediaType.TEXT_PLAIN)      
public String index() { 
        
return "Hello World";     
 
} 
}

Now enjoy the output:

$ curl http://localhost:8080/hello 

> Hello World

Conclusion:-

Spring boot and micronaut both have some pros and cons. As per my understanding if you are developing a new greenfield application start with micronaut but don’t rewrite existing application of spring boot to micronaut unless and until you are facing some serious performance issues. If you are migrating from monolith to cloud-native microservice then micronaut is the good option. Please let us know your thoughts on this.

Reference link:–

This is the performance comparison between spring boot and micronaut.

https://docs.micronaut.io/latest/guide/index.html

https://piotrminkowski.com/2019/04/09/performance-comparison-between-spring-boot-and-micronaut/

Micro service architecture for legacy code base.

Micro service architecture for legacy code base.

For more stories.

Refactoring the legacy code is art.

There is no prerequisite to understanding this article. But if you go through the below article it could be advantageous Manage Big Ball of Mud.

As new features and new functionality are introduced the complexity of this application can increase dramatically and harder to maintain code base and add new features too. This application becomes the Big Ball of Mud. Teams have been struggling to maintain the complex application and some suggest replace the complete application with new technology, new hosting and or new architecture pattern. Replace the complete solution is really hard.

There have been big buzzwords in the industry about micro service, serverless architecture. Starting the greenfield development is a quite easy task. What about legacy one?

Strangulation

Michiel Rook’s blog Gradually convert Monolith into micro-service app

Martin Fowler describes the Strangler Application:

One of the natural wonders of this area are the huge strangler vines. They seed in the upper branches of a fig tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.

This has been a long journey to convert your monolith application into micro-service or nano service architecture or any other architectural pattern that is well suitable for our application context.

Solution

In a 2004 article on his website, Martin Fowler defined the Strangler Application pattern as a way of handling the release of refactored code in a large web application. The fundamental strategy is EventInterception, which can be used to gradually move functionality to the strangler and to enable AssetCapture.

The Strangler Application is based on an inference to a vine that strangles a tree that it’s wrapped around. The idea is that you use the structure of an application — the fact that large apps are built out of individual URIs that map functionally to different dimensions of a business domain — to divide an application into different functional domains, and replace those domains with a new micro-services-based implementation one domain at a time. This creates two separate applications that live side by side in the same URI space. Over time, the newly refactored application “strangles” or replaces the original application until finally, you can shut off the monolithic application. Thus, the Strangler Application steps are

  1. Choose a particular specific piece of functionality which is solo within an application.
  2. Modify it or refactor and rebuild as a service.
  3. Deploy while deploying use proxy pattern to bypass the traffic. This will help us to run code for both legacy and new user. or Create simple facade to intercept or filter the requests going to the backend legacy system.
  4. Repeat above steps until an application is fully migrated.

The great thing about applying this pattern is that it creates incremental value in a much faster timeframe than if you tried a “big bang” migration in which you update all the code of your application before you release any of the new functionality. It also gives you an gradually approach for adopting micro-services — one where, if you find that the approach doesn’t work in your environment, you have a simple way to change direction if needed.

Strangler Pattern address the following problems

  1. Legacy code or Big ball of mud.
  2. complicated and complex architecture.
  3. Monolithic design
  4. Fragmented business rules
  5. Painful deployment process

There are certain aspects which are specific to those particular applications. If it is really old code then we need to figure out and refactor accordingly into some functional level separation and then apply the strangler pattern.

There are two sides either complain about the things and be a part of the problem or take this up find solution and be a part of solution.

For more ref:-

Application Strangler Pattern Experiences & Thoughts
The biggest problem to overcome is lack of will to actually finish the strangling (usually political will from non…stackoverflow.com

https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler

This is just simple idea. Apply and let me know.

For more stories.

Lets connect on Stackoverflow , LinkedIn , Facebook& Twitter.

Manage Big Ball of Mud.

Manage Big Ball of Mud.

Everyone wants to develop a project from scratch no one wants to manage the big ball of mud. This article is for those people who wanted to

” Leave campground cleaner than you found it”.

What is Big Ball of mud? Ref- Wikipedia.

A big ball of mud is a software system that lacks a perceivable architecture.A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.

Ball vs Blocks

Let us observe the picture to understand the difference between to manage the big ball & manage the block. Carrying the big ball is tedious instead of the blocks. When a ball is small we can easily carry and maintain. When its size increases it’s very difficult to manage. As we generally try to arrange the big balls to make some structure it is quite difficult? While If we try to arrange the blocks and structure them it is quite easy and maintainable.

How these forms?

Big ball of mud is an architectural disaster. This kind of systems has usually been developed over a long period of time, with different individuals are working on various pieces. The people who develop this kind of architecture with no formal training of what is software architecture or programming design pattern training.

There are many reasons

  1. No formal training of software architecture.
  2. No formal knowledge of design pattern.
  3. Financial or Time pressure.
  4. Throwaway code.
  5. Inherent Complexity.
  6. Change of requirements.
  7. Change of developers.
  8. Piecemeal Growth.

How to manage BBOM?

Sometimes the best solution is simply to rewrite the application catering to new requirements. But this is the worst case scenario.

The clumsy solution is that stop the new development and refactor whole system step by step. To do this

  1. Write down the test cases.
  2. Refactor code.
  3. Redesign & Re-architect the whole system.

To overcome this BBOM anti-pattern. You must have to follow below steps

  1. Code Review
  2. Code refactoring overtime period.
  3. Fallow best practices.
  4. Use design Pattern & architectural pattern.
  5. If you have time constraint while developing at least design code in a modular way (Single responsibility principle), so you can easily rearrange later.
  6. Use TDD(Test Driven Development).

Big ball of mud isn’t just absence of architecture rather its own architectural pattern, that has merits and trade-offs.

I am not saying here that this case is never gone happen, This happens many times with many peoples including me as well.

This article will give you a brief idea, How to manage & overcome this issue?

There is a will there is a way.

I have followed this path, love to hear from you folks.

How you are gone managing this big ball of mud?

For more stories.

Let’s connect on Stackoverflow, LinkedIn, Facebook& Twitter.