For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Giorgio Tempesta -
WavePlay Staff -
Aritra Karak -
Trainings24x7 -
Top comments (3)
Hey Jesse,
I'm currently at the beginning of the serverless journey, learning as much as I can to kick start a personal project, so this content comes at the perfect moment for me. It actually changed my view quite a lot about how I would structure my backend, thanks!
So, IaC is very appealing to me because config files can be versioned using git, but I'm not sure if that's 100% true or there are certain things that cannot be kept as code and you end up having a mix of manual configurations and code. Any advice on that? is it something you have to figure out at the beginning of the project?
What's your take on serverless frameworks such github.com/serverless/serverless ?
Thanks, Joan! Yeahhhh... a few things.
First, Jesse Warden has a big mouth and is very confident, so take with a grain of salt. Some of those who can appreciate Serverless most are those who are REALLY GOOD at servers and Unix and Ops. Meaning, they know what Serverless is doing for them. My view is merely "I couldn't easily deploy apps for the back-end, now I can". Which is super empowering, no doubt! Just be aware I'm super n00b on Ops and back-end which is why I love Serverless so much. AWS is complicated, yet even an art student like me can be successful with grit.
Ok, so IaC is a mess. A good or bad mess depending upon how you view it. It's bad in that not all of it is code. Like, Ansible is only part Python. Terraform is a wanna-be TypeScript. Even ServerlessFramework has godawful YAML. There are many who are pretty adamant that configuration shouldn't be code, and that things like JSON, YAML, CSV, dot files, blah blah blah are justified to "handle just a little configuration". Um... no? I'm a minority, I get it, but I've seen JSON and YAML break things constantly, with no quality controls like code has unit tests AND it takes minutes to hours to find out.
However, one could view that as awesome in that we're still innovating. Not me, I'm forced to find out that is "ok". I'm still exploring, and not sure which one I like. I'd like to play with ServerlessFramework outside of work, mainly because I am comfortable with JavaScript, and like the plugin idea. However, at work, I use AWS SAM because we have an important IAM Role plugin we're required to use and it's nicely implemented AND there is a smart dude at work supporting 8,000 developers in CloudFormation lol.
I like the ideas of the AWS CDK, no doubt. Having types is 1 part of the fix for YAML, so TypeScript is a step in the right direction. However, my problem wtih TypeScript is that it has a lot of Object Oriented baggage. Meaning, in OOP, you create classes, and they have internal state. For infra... there is no state. You just define a blueprint and your tools figure out the order to build things. But "OOP" is still in fashion, imperative style code is how people think, so... it's where we're at.
Also, the CDK's ability to write Step Functions in code vs. JSON or YAML is quite powerful, too. Now, AWS compiler in the console for Step Functions is good enough that you don't really need types, but I still like the idea of using code. It's interesting, too, because it's not really class based despite TypeScript heavily favoring classes & interfaces over types. Anyway, that kind of innovation that just surprises you is compelling and you see a lot of it if you dig into these tools (I don't, I hate Ops and DevOps).
To be clear, I'm new at all this. I've been doing UI development for about 12 to 14 years, then slowly moved to back-end for the next 6 to 8. At the same time, the industry was changing to a "You Build It, You Run It" model. That quote is what Werner Vogels mentioned how he ran Amazon Web Services back in 2006. Since then, many companies have started making developers, even UI dudes like myself, responsible for deploying and maintaing what I deploy. We used to just shove over the wall to Ops/UNIX people, and they'd throw in a server. However, maintenance is often still handled by us for the code, but not for server things. It was a bit more involved for back-end people for reasons I'm just now learning about as both the Ops and back-end things are intertwined.
Anyway, fast forward to 3 years ago, and Capital One where I work follows the same thing, just called "You Build It, You Own It". Meaning a feature team not only builds an app, but deploys it, and is responsible for supporting it, and gets Pages in the middle of the night if you have that type of app. So you suddenly have motivation to make deployments easier, less risky, less to manage, etc. Serverless solves those 3 problems and more, hence my insane passion for it. I'm new to all this and from my naive view, Serverless seems the brainless choice, yet droves of people invest in Kubernetes and I'm like "wtf am I missing". Then again, I prefer Hammocks over Tents because they're complex and then I'm like "Oh..."
If you're looking to play, yeah, SeverlessFramework will help a lot. SAM is good too, just less ability to make plugins, but I'm not smart enough yet to tell you if that's a deal killer. At work, I could really use those for some edge cases. However, AWS itself is pretty complex; things like Netlify or Vercel or Heroku help reduce the complexity a bit, but sometimes, learning the low-level is fun and builds your self-esteem so either choice is fine.
Funny timing of your post, this week I'm setting up AWS SAM for 3 projects at work because I don't want the 2 kids (young 20 somethings) to have to suffer in Ops, and want them to just have fun in the code. MISERY but for a good cause.
Ok, I just checked AWS CDK, and I'm quite impressed.
With the CDK, It looks like that the abstraction doesn't "leak"; you truly get rid of all manual configurations and configuration files. You can code everything.
The idea of constructs and high-level constructs makes sense, it's basically a 1:1 relationship with the real thing, so I guess that knowledge is quite portable compared to other abstractions that try to redefine The Cloud homogeneously.
Like you, I'm not a huge fan of doing stuff with Ts classes, but I can live with that, especially compared to yamls and jsons. But you are exactly right; the CDK is super imperative. Even with classes, you can create things that are much more declarative than that. Definitely not a fan of the style they chose to write the thing.
I also like that you keep things within the AWS umbrella. ServerlessFWK is another account that you have to connect to AWS. I'd rather avoid that if possible.
Those are my first impressions. I could be wrong. I will try to validate them by doing a proof of concept.
I should stop learning and start getting my hands dirty!