This article is part of a series:

• Part One — review your existing application (Wed. 09/18)
• Part Two — break apart your application (Fri. 09/20)
• Part Three — lift-and-shift (Wed. 09/25)
• Part Four — choose a deployment framework (Fri. 09/27)
• Part Five — build a strong foundation (Fri. 10/11)

In this series, we take a look at what areas you need to think about when making a “serverless migration”. First, we will touch on what you should review about your existing application, move into breaking your application apart, talk about lift-and-shift, choose a cloud provider, choose a deployment framework, and how to build a strong foundation.

In this article, we are going to talk about the lift-and-shift cloud migration strategy and see how it looks when applied to serverless.

If you’re not familiar with lift-and-shift, let’s talk about it.

Lift-and-shift (explanation)

Pick up your existing application running on-premises and drop it onto a cloud providers VM (virtual machine).

This strategy usually plays out like this:

1. Select a small application running on-premises
2. Select your desired cloud provider
3. Manually spin up the cloud VM
4. Upload your code, install dependencies, configure networking and security
5. Test the application

There are services that can help you do this lift-and-shift automatically. For example, AWS has a service called AWS Server Migration Service. However, I’ve not personally used it, so I can not speak to the complexity level. Also, it’s worth noting that step #3 and #4 above can be streamlined with services like AWS Elastic Beanstalk and Google Cloud App Engine. These services fall under the “fully managed” umbrella and most of the lower-level details are handled by the cloud provider on your behalf.

With that explanation out of the way, let’s take a look at the question, “can I lift-and-shift to a cloud function?”.

Can I lift-and-shift to a cloud function?

I would lean towards saying you can’t simply lift-and-shift from a virtual machine to a cloud function because there are code changes which need to be made.

These code changes are mostly due too:

• Event-Driven Architecture — events drive the application
• Fully Managed Restrictions — draw within the lines
• Ephemeral-ness — temporary storage only

Event-Driven Architecture

In event-driven architectures, the event would be the action that takes place which causes your cloud function to execute.

• API request
• File upload
• Database CREATE, UPDATE, DELETE
• Message added to a queue
• etc.

Services can trigger your cloud functions based on events. This is why people refer to cloud functions as “glue code” because cloud functions connect all the various cloud services together.

To be able to make a serverless migration, you need to refactor your code at the beginning to handle unpacking the event coming into the cloud function. Then you can reuse *most of the code you’ve already written to handle that task.

Fully Managed Restrictions, draw within the lines

The other side of the coin is fully managed restrictions. When you’re operating in a fully managed environment by definition you have less control. This requires your team and company to shift its focus towards a new way of developing where single developers can take on the role of multiple other people because of the number of abstractions.

However, when you’re coming from an environment where you had control over absolutely everything, there will likely be some resistance that builds up.

For example, let's imagine a company named MagicLamp just did a lift-and-shift to the cloud and are now running their application on VMs. Then MagicLamp implements a security agent onto the VM alongside a monitoring agent. Now MagicLamp wants to make the move to cloud functions.

Where does my VM agent go?

Well, it actually doesn’t fit into this new model. After your cloud functions are done handling the incoming requests the underlying container hosting the cloud function will stop.

Can we add the agent to the underlying container?

Well, no not really. When the cloud function is invoked a container will start to host the cloud function and you could install an agent, potentially execute some scripts, and get really hacky with it. Even if it was possible, you shouldn’t do that.

Replacing the security agent

There is a serverless solution that Serverless Guru has worked with called, Protego. They allow you to handle the security element in this new environment.

Replacing the monitoring agent

Then if you need to have monitoring there are a lot of different options. We wrote an article about these different serverless monitoring companies a few days ago. Check it out, here.

Due to the fully managed nature of cloud functions we had to “draw within the lines”, but luckily there are options out there which can fit this new model and fully managed is actually one of the biggest motivators for migrating to serverless.

Those agents above which were manually installed onto your VM or baked into some machine image can now be removed. With that change, the ongoing maintenance goes away as well.

Ephemeral-ness, temporary storage only

We covered this in the first article on serverless migrations, but I’ll cover it with an example.

Let’s say your application handles storing images for your application on a hard disk or SSD attached to the server. When you move to serverless, you’re going to need too:

1. Replace the code that stores that image locally on your server with code that uploads that image to cloud storage
2. Add code that stores the user's image URL generated by the cloud storage service inside the database
3. Replace all endpoints that look for that image locally with code that sends back the cloud storage URL

Package non-serverless to serverless

Believe it or not, you can take a Java Spring Boot API which typically runs on a virtual machine or container and run it as cloud function. It turns out you can do this with a few other types of applications:

• Java Spring Boot
• Java Spring
• ExpressJS

The method to make this magic happen comes from AWS and it’s pretty cool. AWS gives you a way to wrap your cloud function up in such a way that it’s compatible with AWS Lambda.

We, Serverless Guru, actually wrote an article about this a while back with the catchy title “Move your Spring Boot API to AWS Lambda and Reduce Costs by 100%”.

Review

In this article, we covered two use-cases, one where you’re building an API and trying to determine how best to break apart your API to mesh with cloud functions. The second, covering how to take a not-fit-for-serverless long-running process and make it work anyways.

In the next article, we are going to talk about choosing a deployment framework because once you know how your architecture will look, you need to automate it.