Lessons Learned From a Legacy Serverless App
Lessons Learned From a Legacy Serverless App
Take it from this developer: working on a legacy app you didn't design, with a cloud platform you're not used to, is more than a little challenging.
Join the DZone community and get the full member experience.Join For Free
Feeping in mind the growing multi-cloud trend, developers should start working with more than one provider. However, this can mean leaving your comfort zone, and not everyone likes the idea of doing that. Recently, I’ve done this and would like to share my experiences with you. I believe they are useful, regardless of whatever cloud platform you are using/are going to use.
We have a legacy serverless application hosted on Azure Functions. There were some issues with it:
- The original team who made the app didn’t use any kind of serverless tooling to develop the app locally. Instead, they developed the app through Azure Portal, i.e. with in-browser code editor.
- No Infrastructure-as-Code (IaaC) tool was used and there was almost no documentation.
- There was no development environment (everything was released directly to production).
Thanks to these, app maintenance was done only through an in-browser code editor and every release was risky. I decided to change this frustrating situation by creating a development environment, by enabling local development for the app.
To create a new development environment (by replicating the production environment), I needed to reverse engineer the whole application, which was an extremely tedious and time-consuming job. And to enable local development, I need to upgrade the app runtime from 1.x to 2.x *
In general, this was a painful experience for me: working on a legacy app (with low standards) which was hosted on a new cloud provider that I never touched before. However, I’ve learned a lot and now I find this experience indeed valuable.
1. Use a Cross-Platform Serverless and IaaC Tool
Please avoid developing and maintaining your app in-browser, at any cost. It’s inefficient and a huge technical debt. In our case, there were many small settings that the original team did by using Azure Portal. They were crucial to get the project up and running, but they were neither documented nor automated. Reverse engineering others’ work was very time consuming and frustrating job. If I would have developed the app from scratch, it would take less time and would have caused less headache. But unfortunately, this wasn’t an option, so I ended up reverse engineering it.
And whatever tooling are you using, make sure that it’s cross-platform. People who will work on your project can have Windows, Linux, or Mac workstations. So, if your tooling is platform-specific or doesn’t have all features in all platforms, then the next poor developer can ben a big trouble (in our case, I was the victim).
2. Multi-Cloud Requires Change of Mindset
Even though the multi-cloud strategy concept is growing, I’ve seen very few developers who really work with different cloud providers. The majority are working exclusively with one of the big providers. For example, many Azure developers told me that they never touched AWS, and vice versa. Often, I hear from AWS developers who complain that how confusing Azure is. While working on my Azure project, often I got a headache getting some simple jobs done. Now that I'm reflecting, I can partly blame myself for this problem: I was used to the way that AWS works, and tried to get things done on Azure using the AWS way. This is wrong. Let me clarify this with a few examples:
- In AWS, you can authenticate your DevOps pipeline just by defining few environmental variables, whereas in Azure, you need to define the Service Principal.
- If you locally develop and deploy your serverless app with Azure Functions Core Tools, by default, it does NOT set your defined environmental variables. To do that, you need to explicitly specify it while deploying your application. In contrast, the Serverless framework and AWS SAM automatically set your environmental variables by default as far as you have defined them.
I’m not telling you which implementation you should use. I’m just saying that they are different and require a different approach. Don’t expect all cloud providers to have the same way of working.
From now on, before using any new cloud provider, I’m not going to make any assumptions (from my AWS nor Azure experience) and try to understand how the new cloud provider is looking at a problem and which solution is it offering for my use case.
*To clarify: Core Tools is Azure’s own tool for local development and debugging of Functions (it’s not an IaaC, though). To use it for v1, I need to have a Windows machine (and I’ve got a Mac). So, I ended up using Core Tools for v2 of the app. Alternatively, you can use Serverless framework (it’s provides IaaC and local development). My colleague was at the same time trying Serverless framework for his Azure project. Despite some issues at the beginning, at the end he was happy. We haven’t made any comprehensive comparison yet. But when we make, we will share it with you.
Opinions expressed by DZone contributors are their own.