Migrating to Serverless and Making It Work Post-Transition

In this article, we’ll be giving you tips while discussing the steps in each stage of migrating to serverless—from preparation to migration to post-transition.

The Cloud Spectrum

To understand more easily the wider context of migrating legacy systems into a serverless form, we should first understand the cloud spectrum. This spectrum ranges from on-premises workloads to virtual machines, containers, and cloud functions. Serverless typically falls within the cloud functions area, as  function as a service (FaaS), but now it’s an umbrella term growing to include back-end as a service (BaaS), such as fully managed databases.

The first thing when looking at legacy transitions is understanding where you are on the cloud spectrum.

Despite being four or five years old, we are starting to get into a cycle where even serverless apps are becoming legacy systems as well. Anybody that writes Node.js knows that if you make no updates for two years, you’re going to have dependencies breaking all over the place.

Your Serverless Experience

The next question to ask is: does your team already have serverless experience?

There are two different routes here:

  1. Yes: We already have serverless experience and we already have cloud experience. In this case, you need to identify the key team members who can help drive and evangelize the serverless migration, including training, pattern development, and so on. The engineering hours involved in the transition can all be streamlined by having the patterns, the documentation, and the training.
  2. No: If you don’t have that serverless or cloud experience internally, you would benefit from finding a consulting partner that specializes in serverless migrations (such as  Serverless Guru or  Theodo) or serverless adoption to help retrain and retool existing employees and help them grow.

The Serverless Acceleration Team

Following this, you would need to develop the serverless acceleration team. This would be a working group that will help accelerate the rest of your organization, which will focus on:

  • building reusable infrastructure as code
  • practices around building serverless apps
  • processes around development workflow

Drawing Service Boundaries

Next, you need to identify a  common service or use case. For that, you can ask the following question: what service represents 80% to 90% of how other services are built in the legacy system?

Let’s take a monolithic API as an example. If we have 100 endpoints and 10 of them are related to account and 10 of them are related to users and 10 of them are related to feeds, we can draw three service boundaries there. We could find that the APIs that are being done 100 times, one of them looks the same as the rest of the 100. With these service boundaries, we can start chunking this migration up into pieces. That makes it easier to migrate!

If we develop a pattern for one service boundary and it’s composed of 10 endpoints and there’s nine more of those services that all have 10 endpoints each, we know that if we can develop one, we can reuse it across the rest of them.

#devops #aws #serverless #serverless adoption

What is GEEK

Buddha Community

Migrating to Serverless and Making It Work Post-Transition
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

Migrating to Serverless and Making It Work Post-Transition

In this article, we’ll be giving you tips while discussing the steps in each stage of migrating to serverless—from preparation to migration to post-transition.

The Cloud Spectrum

To understand more easily the wider context of migrating legacy systems into a serverless form, we should first understand the cloud spectrum. This spectrum ranges from on-premises workloads to virtual machines, containers, and cloud functions. Serverless typically falls within the cloud functions area, as  function as a service (FaaS), but now it’s an umbrella term growing to include back-end as a service (BaaS), such as fully managed databases.

The first thing when looking at legacy transitions is understanding where you are on the cloud spectrum.

Despite being four or five years old, we are starting to get into a cycle where even serverless apps are becoming legacy systems as well. Anybody that writes Node.js knows that if you make no updates for two years, you’re going to have dependencies breaking all over the place.

Your Serverless Experience

The next question to ask is: does your team already have serverless experience?

There are two different routes here:

  1. Yes: We already have serverless experience and we already have cloud experience. In this case, you need to identify the key team members who can help drive and evangelize the serverless migration, including training, pattern development, and so on. The engineering hours involved in the transition can all be streamlined by having the patterns, the documentation, and the training.
  2. No: If you don’t have that serverless or cloud experience internally, you would benefit from finding a consulting partner that specializes in serverless migrations (such as  Serverless Guru or  Theodo) or serverless adoption to help retrain and retool existing employees and help them grow.

The Serverless Acceleration Team

Following this, you would need to develop the serverless acceleration team. This would be a working group that will help accelerate the rest of your organization, which will focus on:

  • building reusable infrastructure as code
  • practices around building serverless apps
  • processes around development workflow

Drawing Service Boundaries

Next, you need to identify a  common service or use case. For that, you can ask the following question: what service represents 80% to 90% of how other services are built in the legacy system?

Let’s take a monolithic API as an example. If we have 100 endpoints and 10 of them are related to account and 10 of them are related to users and 10 of them are related to feeds, we can draw three service boundaries there. We could find that the APIs that are being done 100 times, one of them looks the same as the rest of the 100. With these service boundaries, we can start chunking this migration up into pieces. That makes it easier to migrate!

If we develop a pattern for one service boundary and it’s composed of 10 endpoints and there’s nine more of those services that all have 10 endpoints each, we know that if we can develop one, we can reuse it across the rest of them.

#devops #aws #serverless #serverless adoption

Hermann  Frami

Hermann Frami

1655426640

Serverless Plugin for Microservice Code Management and Deployment

Serverless M

Serverless M (or Serverless Modular) is a plugin for the serverless framework. This plugins helps you in managing multiple serverless projects with a single serverless.yml file. This plugin gives you a super charged CLI options that you can use to create new features, build them in a single file and deploy them all in parallel

splash.gif

Currently this plugin is tested for the below stack only

  • AWS
  • NodeJS λ
  • Rest API (You can use other events as well)

Prerequisites

Make sure you have the serverless CLI installed

# Install serverless globally
$ npm install serverless -g

Getting Started

To start the serverless modular project locally you can either start with es5 or es6 templates or add it as a plugin

ES6 Template install

# Step 1. Download the template
$ sls create --template-url https://github.com/aa2kb/serverless-modular/tree/master/template/modular-es6 --path myModularService

# Step 2. Change directory
$ cd myModularService

# Step 3. Create a package.json file
$ npm init

# Step 3. Install dependencies
$ npm i serverless-modular serverless-webpack webpack --save-dev

ES5 Template install

# Step 1. Download the template
$ sls create --template-url https://github.com/aa2kb/serverless-modular/tree/master/template/modular-es5 --path myModularService

# Step 2. Change directory
$ cd myModularService

# Step 3. Create a package.json file
$ npm init

# Step 3. Install dependencies
$ npm i serverless-modular --save-dev

If you dont want to use the templates above you can just add in your existing project

Adding it as plugin

plugins:
  - serverless-modular

Now you are all done to start building your serverless modular functions

API Reference

The serverless CLI can be accessed by

# Serverless Modular CLI
$ serverless modular

# shorthand
$ sls m

Serverless Modular CLI is based on 4 main commands

  • sls m init
  • sls m feature
  • sls m function
  • sls m build
  • sls m deploy

init command

sls m init

The serverless init command helps in creating a basic .gitignore that is useful for serverless modular.

The basic .gitignore for serverless modular looks like this

#node_modules
node_modules

#sm main functions
sm.functions.yml

#serverless file generated by build
src/**/serverless.yml

#main serverless directories generated for sls deploy
.serverless

#feature serverless directories generated sls deploy
src/**/.serverless

#serverless logs file generated for main sls deploy
.sm.log

#serverless logs file generated for feature sls deploy
src/**/.sm.log

#Webpack config copied in each feature
src/**/webpack.config.js

feature command

The feature command helps in building new features for your project

options (feature Command)

This command comes with three options

--name: Specify the name you want for your feature

--remove: set value to true if you want to remove the feature

--basePath: Specify the basepath you want for your feature, this base path should be unique for all features. helps in running offline with offline plugin and for API Gateway

optionsshortcutrequiredvaluesdefault value
--name-nstringN/A
--remove-rtrue, falsefalse
--basePath-pstringsame as name

Examples (feature Command)

Creating a basic feature

# Creating a jedi feature
$ sls m feature -n jedi

Creating a feature with different base path

# A feature with different base path
$ sls m feature -n jedi -p tatooine

Deleting a feature

# Anakin is going to delete the jedi feature
$ sls m feature -n jedi -r true

function command

The function command helps in adding new function to a feature

options (function Command)

This command comes with four options

--name: Specify the name you want for your function

--feature: Specify the name of the existing feature

--path: Specify the path for HTTP endpoint helps in running offline with offline plugin and for API Gateway

--method: Specify the path for HTTP method helps in running offline with offline plugin and for API Gateway

optionsshortcutrequiredvaluesdefault value
--name-nstringN/A
--feature-fstringN/A
--path-pstringsame as name
--method-mstring'GET'

Examples (function Command)

Creating a basic function

# Creating a cloak function for jedi feature
$ sls m function -n cloak -f jedi

Creating a basic function with different path and method

# Creating a cloak function for jedi feature with custom path and HTTP method
$ sls m function -n cloak -f jedi -p powers -m POST

build command

The build command helps in building the project for local or global scope

options (build Command)

This command comes with four options

--scope: Specify the scope of the build, use this with "--feature" tag

--feature: Specify the name of the existing feature you want to build

optionsshortcutrequiredvaluesdefault value
--scope-sstringlocal
--feature-fstringN/A

Saving build Config in serverless.yml

You can also save config in serverless.yml file

custom:
  smConfig:
    build:
      scope: local

Examples (build Command)

all feature build (local scope)

# Building all local features
$ sls m build

Single feature build (local scope)

# Building a single feature
$ sls m build -f jedi -s local

All features build global scope

# Building all features with global scope
$ sls m build -s global

deploy command

The deploy command helps in deploying serverless projects to AWS (it uses sls deploy command)

options (deploy Command)

This command comes with four options

--sm-parallel: Specify if you want to deploy parallel (will only run in parallel when doing multiple deployments)

--sm-scope: Specify if you want to deploy local features or global

--sm-features: Specify the local features you want to deploy (comma separated if multiple)

optionsshortcutrequiredvaluesdefault value
--sm-paralleltrue, falsetrue
--sm-scopelocal, globallocal
--sm-featuresstringN/A
--sm-ignore-buildstringfalse

Saving deploy Config in serverless.yml

You can also save config in serverless.yml file

custom:
  smConfig:
    deploy:
      scope: local
      parallel: true
      ignoreBuild: true

Examples (deploy Command)

Deploy all features locally

# deploy all local features
$ sls m deploy

Deploy all features globally

# deploy all global features
$ sls m deploy --sm-scope global

Deploy single feature

# deploy all global features
$ sls m deploy --sm-features jedi

Deploy Multiple features

# deploy all global features
$ sls m deploy --sm-features jedi,sith,dark_side

Deploy Multiple features in sequence

# deploy all global features
$ sls m deploy  --sm-features jedi,sith,dark_side --sm-parallel false

Author: aa2kb
Source Code: https://github.com/aa2kb/serverless-modular 
License: MIT license

#serverless #aws #node #lambda 

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