I finally feel like a user — developer’s praise for The Serverless Framework
In my line of job (which is backend developer, with strong DevOps mindset and intention to help SRE guys as much as possible) I deal with so called “developer’s tools” a lot. This is a broad category, that may contain IDE’s, linters, bundlers, clis and various kinds of automation frameworks. It’s not code, but my (and my team’s) ability to transform code we produce into a service someone actually uses depends on them heavily. This year’s list includes (but is not limited to): npm, yarn, mvn, gradle, Vagrant, docker, docker-compose, webpack, aws-cli, ansible, eslint, GitLab runners, Jenkins and lots of plugins and add-ons.
This list is heterogeneous, but what those products and solutions have in common is the user — me, a developer. And, to be honest, I rarely feel like a user. My team’s development environment is also heterogeneous (various operating systems, various languages) and I don’t think there was one tool we adopted for which the adoption would get smoothly and without problems for all of us. Sometimes it was lack of support for the OS, sometimes some strange dependencies required and sometimes things like not-so-great documentation that made the learning curve even steeper. Often those were cryptic error messages that required a lot of googling.
I am not saying that creators and maintainers of tools I listed don’t do a great job. They do. It’s not that all those products have all those flaws I listed, those were rather singular cases for most of them… but take a very diverse team working on quite complex assignment, pick any day in first five iterations — and almost for sure there will be someone that day fighting with some problem with one of tools. It usually gets better with time and it’s on the team, as well, of course — we could’ve gone with one OS, we could’ve limited number of tools, we could’ve read through documentation thoroughly… Nevertheless, if I try to to imagine what creators of most “developer tools” had in mind when developing, it’s something like “you’re a smart guy, you’ll figure this out”.
So last week, I did some experiments around automating lambda functions deployment. I started in very courageous mood, prepared to fight with those issues that are so usual and so characteristic when you try some new tool, having little experience in the field. I picked The Serverless Framework, read some quick intro on their page, configured my build, run serverless command… and it just worked. Then it worked for my friends on their machines as well.
I swear I could hear it’s contributors whispering to my ear “you are a user” and that’s a great thing for a developer to hear.
It’s not a fair comparison. It’s a tool that has one job, it may not be so complex as others I listed. But I really like it. I finally feel like a user, whose brain power is free to focus on what to do with a tool, not on usage of a tool itself. Here is why I think Serverless team did a great job focusing on users:
- At first sight, I know what’s Serverless’ job.
- Documentation is great — informative, with just enough details. It’s nicely and clearly divided into topics, so on each stage of my work I know where to click. I also know where I am when I read it.
- “Hello-world” is easy — like really easy — yet shows the important concepts.
- Output of the tool! It’s nicely formatted (I love that indentation), with clear division of sections, not just one messy output line. It has all key information in it: what went wrong, where I can get help and what’s my environment. Even the color-coding is helpful — it’s clear at first sight where is the information, where is the legend and what actions you can take. I believe whoever coded that console output, understood that a developer is their user and in consequence paid enough attention to details.
- All the error messages were informative, with ability to get even more info (which is clearly communicated in the output — see “For debugging logs…” message in red). Errors happened at different stages (keys not configured, config file in yaml malformed, something wrong with IAM on AWS) and were nicely communicated without any clutter.
- It’s open source, so if I want to be a developer and go and find out implementation details — I am free to do so!
To sum up — it’s been just a week. It was enough to use Serverless on a few real-life projects and automate its usage, though I tried only a subset of options. It may have been just those 6 seconds to make a first impression, but yeah, they used them well!
