Mike  Kozey

Mike Kozey

1627035982

The Great Migration: Peculiar Complexities of Monolith to Microservices Migration

This article reviews the peculiar complexities that threaten the success of the monolith to microservices migration projects and offers a solution.

There are peculiar complexities that threaten the success of the monolith to microservices migration projects by making them difficult and costly to undertake.

Unfortunately, you cannot hide or ignore these complexities.

Even if, somehow, you manage to complete a migration project by evading the complexities, the party wouldn’t last long.

You will end up getting haunted by complex ghosts for years to come.

Let me explain why I am saying this, but before I do that, let us set the context right so that we are on the same page.

Let’s assume you want to migrate a monolithic ERP system to a microservices architecture.

  • You aspire to utilize the cloud-native infrastructure.
  • You hope to bring in latest infrastructure into play.
  • You want to go serverless.
  • You want to add more bells and whistles to microservices.
  • You believe in the promise that your costs of operations will come down once you have created these new services.
  • The new application will be easy to maintain and scale.

Fair expectations.

Nothing wrong with these.

But, it is not the curse of the shiny things where your problems will start.

Not that the promise of microservices was oversold, it is just that you did not prepare for the real complexities that you were going to face to fulfill the promise.

Enough of the scare.

Let’s see how you would typically approach a monolith to microservices migration of an ERP system and, then, we will see what exactly the complexities are.

The Typical Approach

Strangulate them.

Typically, if you have got it right, you will undertake the migration using what is called a strangler pattern.

You will start by analyzing the ERP system modules.

You will then design a logical breakdown of the modules into probable services.

Then, you will identify the first batch of modules that can be moved out. The obvious choice will be the ones with the least dependencies.

You will rewrite the features of these modules as microservices and, then, let microservices shadow the modules for some time.

Once the microservices are stabilized, strangulate/disconnect the original modules.

You will continue this process for other modules until all of them have been moved to microservices.

Easy-peasy-lemon-squeezy! Right?

Not quite.

#microservices #migration #monolith

What is GEEK

Buddha Community

The Great Migration: Peculiar Complexities of Monolith to Microservices Migration
Mike  Kozey

Mike Kozey

1627035982

The Great Migration: Peculiar Complexities of Monolith to Microservices Migration

This article reviews the peculiar complexities that threaten the success of the monolith to microservices migration projects and offers a solution.

There are peculiar complexities that threaten the success of the monolith to microservices migration projects by making them difficult and costly to undertake.

Unfortunately, you cannot hide or ignore these complexities.

Even if, somehow, you manage to complete a migration project by evading the complexities, the party wouldn’t last long.

You will end up getting haunted by complex ghosts for years to come.

Let me explain why I am saying this, but before I do that, let us set the context right so that we are on the same page.

Let’s assume you want to migrate a monolithic ERP system to a microservices architecture.

  • You aspire to utilize the cloud-native infrastructure.
  • You hope to bring in latest infrastructure into play.
  • You want to go serverless.
  • You want to add more bells and whistles to microservices.
  • You believe in the promise that your costs of operations will come down once you have created these new services.
  • The new application will be easy to maintain and scale.

Fair expectations.

Nothing wrong with these.

But, it is not the curse of the shiny things where your problems will start.

Not that the promise of microservices was oversold, it is just that you did not prepare for the real complexities that you were going to face to fulfill the promise.

Enough of the scare.

Let’s see how you would typically approach a monolith to microservices migration of an ERP system and, then, we will see what exactly the complexities are.

The Typical Approach

Strangulate them.

Typically, if you have got it right, you will undertake the migration using what is called a strangler pattern.

You will start by analyzing the ERP system modules.

You will then design a logical breakdown of the modules into probable services.

Then, you will identify the first batch of modules that can be moved out. The obvious choice will be the ones with the least dependencies.

You will rewrite the features of these modules as microservices and, then, let microservices shadow the modules for some time.

Once the microservices are stabilized, strangulate/disconnect the original modules.

You will continue this process for other modules until all of them have been moved to microservices.

Easy-peasy-lemon-squeezy! Right?

Not quite.

#microservices #migration #monolith

Adaline  Kulas

Adaline Kulas

1594166040

What are the benefits of cloud migration? Reasons you should migrate

The moving of applications, databases and other business elements from the local server to the cloud server called cloud migration. This article will deal with migration techniques, requirement and the benefits of cloud migration.

In simple terms, moving from local to the public cloud server is called cloud migration. Gartner says 17.5% revenue growth as promised in cloud migration and also has a forecast for 2022 as shown in the following image.

#cloud computing services #cloud migration #all #cloud #cloud migration strategy #enterprise cloud migration strategy #business benefits of cloud migration #key benefits of cloud migration #benefits of cloud migration #types of cloud migration

Seamus  Quitzon

Seamus Quitzon

1595205213

How to perform migration rollback in laravel

As we know that laravel migration provides very simple way to create database table structure. We need to create migration file and write table structure then migrate that migration. Sometimes we need to rollback that migration. So here we will discuss about the migration rollback in laravel.

We can run the rollback artisan command to rollback on a particular step. We can execute the following artisan command.

php artisan migrate:rollback --step=1

Every time when we will rollback, we will get the last batch of migration.

**Note: **This rollback command will work on laravel 5.3 or above version. For the version below 5.3, there is no command available for migration rollback in laravel.

We can also use the following command to rollback and re migrate.

php artisan migrate:refresh --step=2

It will rollback and remigrate last two migration.

You can also checkout the article for executing single migration by clicking on the link below.

How to migrate single migration in laravel

#laravel #how to perform rollback migration in laravel #laravel migration rollback #migration refresh in laravel #migration rollback batch in laravel #migration rollback for one specific migration #migration rollback in laravel

Fredy  Larson

Fredy Larson

1595202210

How to migrate single migration in laravel

Sometimes while working on a laravel application, we just need to migrate only single or specific migration. If we run normal migrate command it will migrate all the migrations written in the application. Here i will let you know to migrate single migration in laravel.

Migrations play very important role for aplication’s database structure. We just need to create migrations in the application for each table which you want and whenever we migrate these migrations. New table structure would be created.

For new developers or setting up new environment, we do not need to backup of table structure. We will just need to run the migrations. It will automatically create desired tables in the database connected from the laravel application.

We can run all the migrations using the command below.

php artisan migrate

Now if we want to run only one migration or a specific migration, we will need to define a path parameter and will need to specify the path of that migration file which we want to run like below.

php artisan migrate --path=/database/migrations/my_migration.php

It will migrate only my_migration.php file. Here, you will need to replace file name from your own migration file.

You can also learn how to add column in existing daatbase table through migration by clicking on the below.

#laravel #how to migrate single migration file #laravel migration #laravel single migration #migrate specific migration in laravel

Oral  Brekke

Oral Brekke

1615921920

From the Simple to the Complex: Monolith vs. Microservices

Monolith vs. microservices: a long path from a simple structure to a complex architecture.

Working in the software development industry, I often see articles on monolith pros and cons, microservices pros and cons, monolith vs. microservices, etc. — and much less often about the correct transitions between architectural approaches and their interactions. While projects can grow rapidly or dramatically change their course of development, you need to know when and what architectural approach will help support the system.

This article is for those for whom the monolith hasn’t solved problems and only aggravates all processes. It will also come in handy for those who are just getting acquainted with microservices. I will not say which is better, but I will share my experience of migrating from a monolithic to a microservice architecture.

#microservices #monolith #monolith architecture