Cloud services continue to evolve and developers today are trying to understand what “cloud native” means and how to transform their legacy applications to take advantage of benefits including:

• Reduced overhead of maintenance — let the cloud handle the operating system, security patches, etc.
• Improved DevOps workflows with features like deployment slots
• Automated backups, logging, and analytics
• Pay-for-use rather than “pay-for-just-in-case”

The transition to the cloud is about reducing overhead and focusing more on the core business logic that is unique to your team. It is a DevOps journey and requires more than technology, but a cultural shift as well. There is a tangible evolution of application architectures from on-premises apps through Infrastructure-as-a-Service (IaaS) (the “low risk” on-ramp for cloud migrations, but often a more expensive approach), through Platform-as-a-Service (PaaS) and ultimately “serverless” or “less-server.”

I recently presented a use case for Connect() 2017 that focused on “lift and shift” for a .NET Core “Todo” N-tier application with a single page application front-end talking to a Web API tier that uses Entity Framework core to connect to a SQL database. The source code for the application is on GitHub:

  JeremyLikness/bring-own-app-connect-17

Here is what the running application looks like:

In the training I talk about transforming your software through a series of steps, all geared towards lifting and shifting the application without having to deal with the overhead of maintaining full-size virtual machines. The first step is to create a set of Azure App Service resources to host the web site and Web API, then migrate the SQL database to Azure SQL. You can read guidance for migrating SQL to the cloud here: https://aka.ms/migrate-sql.

Although moving the application “as-is” is often the logical first step, it makes sense in many cases to take advantage of microservices by transforming traditional monolithic applications. Azure’s serverless offerings include Azure Functions and Logic Apps. For apps that have hundreds or thousands of APIs, leveraging serverless provides the ability to scale endpoints independently (consider the case of one endpoint being called millions of times compared to other endpoints that may be called more infrequently), deploy updates out of band from other APIs, and even empower teams to iterate multiple APIs separately in parallel.

It’s not always feasible to transform a complete legacy application at once, so I demonstrate a hybrid approach that allows me to refactor a single end point without changing the main web app. This is done through the power of Proxies.

The final step in the application is to instrument custom telemetry to measure dependencies and answer questions like:

• How long does it take for an API call to complete?
• How much time was spent opening the SQL Connection?
• How long did it take to insert a new item into the database?

The incredible truth is that with our modern set of tools and features, these transformations take place quickly. In fact, I was able to lift the reference application to the cloud, refactor the API to use serverless and instrument custom telemetry live in just under an hour. That included creating the Azure resources from scratch! See for yourself: this is my lift and shift training video.

🎦 Azure: Bring your app to the cloud with serverless Azure Functions

I am curious to know your thoughts and challenges, so please share this with your colleagues and post your comments and feedback. For more lift-and-shift resources, check out this “Bring Your Own Application” link: https://aka.ms/byoa. Thanks!