This content originally appeared on Level Up Coding - Medium and was authored by Louis Latreille
Determine what infrastructure as code (IaC) framework is best for you, based on my recent experience with both.
All the code in this article can be found here, along with the proper setup to deploy the application to AWS.
If you are in the same situation as I was a month, and trying to choose the right IaC framework for a new project (or maybe thinking about switching frameworks in an existing project), then I’m hoping I can help shed some light on two popular ones in the current market. I won’t explain in details what the Serverless Framework or Pulumi are or how they work, as there are already plenty of resources online about that. Instead, I will take you through the journey I’ve had with both tool, developing serverless applications, and discovering what works best for me.
TLDR
If you are developing serverless applications deployed on AWS, with a strong focus on serverless functions that are mostly using Typescript, then:
- Use the Serverless Framework with the configuration (serverless.ts) written in Typescript
- Use the serverless-bundle plugin to streamline the packaging of your functions
If you are mostly managing cloud infrastructure and ecosystems, and want to make it easier (I say easier because even though Pulumi has it’s own API, you will still have to write vendor specific configurations that wouldn’t be transferable to a different cloud provider) to switch cloud providers in the future, then:
- Use Pulumi
On with the Adventure
Both frameworks support all major cloud providers, although all the projects I’ve made were deployed on AWS. I was also mostly creating serverless applications with a heavy use of serverless functions, as opposed to only managing infrastructure. This means I was writing a lot of application code, and then using the IaC frameworks to deploy that code to serverless functions, that were then interacting with other cloud resources. Most of the applications were using Typescript as the main language.
I’ve been using the Serverless Framework for a few years now. I’ve tried all three flavors of it, i.e. writing the configuration with Yaml, JavaScript, or Typescript. I initially started with the default Yaml flavor, but quickly found that this was greatly limiting my ability to write re-usable code. There isn’t any way to write a generic function or block of code and re-use it across your configuration. For things like defining multiple serverless functions or IAM roles, which often are very similar, it didn’t feel good to re-write the same code over and over, or to have to change 10 occurrences of the same thing when trying to change the configuration. Moving to using JavaScript and Typescript made this much better. And this should definitely be an advice.
If you are using the Serverless Framework or thinking about using it, use either JavaScript or Typescript for the configuration.
You will go from this:
To this:
This will put you on a much better path for success on keeping your application maintainable.
The Serverless Framework has a pretty good integration with AWS CloudFormation. If you are trying to deploy other resources than the ones that are managed automatically (AWS Lambda, execution IAM roles, AWS Api Gateway, etc.), it can be done in the Resources section of your configuration. In this section, you are mostly writing a CloudFormation template. I say mostly as you will likely want to link resources created there to your functions in some way, if only to give your Lambda execution IAM roles access to those resources. And this is where the Serverless Framework starts to become fuzzy more complicated. As you add more and more CloudFormation resources, the inter-dependencies between these resources and your serverless functions quickly materialize into spaghetti code. It will be hard to understand what depends on what.
As I started a new project building a new application, this led me to explore alternatives to the Serverless Framework. This is where I discovered Pulumi. The main things that attracted me were the fact that Pulumi is designed to be able to manage entire cloud application, and isn’t focusing on serverless functions only. On top of that, it supports Typescript, and has a nice feature called magic functions, which allows to embed your functions’ code directly into your IaC configuration.
This makes it pretty easy to write a function that is triggered by, say, an upload to an S3 bucket, or a REST API. It also makes the dependencies clear (as opposed to what you have to do with the Serverless Framework).
There are also a few Crosswalks, which are essentially helper classes that streamline some common use cases, like deploying serverless functions in a REST API (like what is seen above). A lot of resource scaffolding is done by the crosswalks classes instead of by you.
With all of that, it felt like you could have one holistic view of your serverless application, writing application code alongside infrastructure code. And this is why I decided to try it out.
Fast-forward a few weeks into my new project, and I now realize that the above was nothing but a pipe dream. Magic functions are very limited. In fact, they only really work well if you aren’t using external libraries. And to be totally honest, this very rarely happens. Along with that, Pulumi doesn’t have anything to help with packaging your application. If you have to write many serverless functions, that each have different dependencies, you are pretty much on your own. Transpiling Typescript to JavaScript, tree-shaking code dependencies, minimizing your code, TSC, Babel, Webpack, bring it on! You will have to figure out all of that to optimize the packages you upload on AWS, and also stay on top of it, as the ecosystem (ahhh… JavaScript) changes every day.
After spending a few hours every couple days on my serverless packaging solution, I couldn’t help but remember how easy it was with the Serverless Framework, coupled with the serverless-bundle plugin. Everything was done for me, and I didn’t have to know anything about the tools above.
On top of that, the Crosswalks felt a bit like an afterthought. They are only partially documented. There are some examples, but if your use case fall out of them, there isn’t any other documentation.
Failing at properly configuring Webpack did it for me. I spent too many hours without the expected result, and decided to convert my entire IaC to the Serverless Framework. I never looked back.
In the end, I tried out Pulumi for a few full weeks, and realized that the Serverless Framework has much better support for serverless functions, at least with AWS.
Pulumi seems like a great framework if you are managing big cloud infrastructures where you have hundreds of resources and serverless functions aren’t the center of the infrastructure, but if you are like me and mostly design applications that heavily make use of serverless functions, I would recommend the Serverless Framework.
After switching back, I also experimented with a new way to structure my application in order to improve on the pain points I’ve had with the Serverless Framework. Stay tuned for another article that goes into the details of how I made the dependencies between resources clearer, and essentially designed what I wanted from Pulumi into the Serverless Framework.
Feel free to expand on your own experience with either of the frameworks in the comments! I’m always looking for different perspectives!
My Journey with Pulumi and the Serverless Framework was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Louis Latreille
Louis Latreille | Sciencx (2022-04-03T22:58:46+00:00) My Journey with Pulumi and the Serverless Framework. Retrieved from https://www.scien.cx/2022/04/03/my-journey-with-pulumi-and-the-serverless-framework/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.