This is a tech blog post in the afterglow of Frontend Developer Love Conference 2020. It is part of a blog series.
The past few years, we have been hearing more and more about ‘serverless’. Amazon, Microsoft and Google are the main serverless architecture providers in that market.
For many front-end developers, it may not be that interesting to spend considerable effort on infra related tasks as it’s unlikely that they’re responsible for it in their daily job. Nevertheless, some of us get to become full stack developers as these other developers prefer to work on wider scopes than deeper in one specific domain. Therefore, it’s important to choose wisely what you spend your efforts on.
As Yan Cui – Developer Advocate at Lumigo – presented during Frontend Developer Love, infrastructure shouldn’t be your main task unless you are an infrastructure company.
Have you ever felt like “I just want to write code!”?
But instead spend hours if not days trying to set up your next project? Or realised that before doing what you intended to do, you must learn some prerequisites?
Knowing just one programming language isn’t enough anymore. A beginner developer may start learning React after getting the basics of JavaScript, and have a hard time actually delivering some code in React because of Webpack, Babel, Linting, React Router and other testing tools.
Thankfully, there are new tools invented daily to ease our work. For example, more and more React projects start with a tool like ‘create-react-app’ that handles the whole burden of webpack configuration, testing tools setup and babel. It even creates some dummy components that are tested and ready to be displayed on the screen so you can actually code straight away and structure your new project.
Shall we know everything?
In the era of serverless, we often may feel the need to know everything. This isn’t easy as we are either good on the front-end side or on the back but rarely truly both. And that’s OK. Many challenges have to be tackled if we want a great app or website as scalability, security, logging and DevOps matter. We could either try to master them all or take advantage of serverless technologies that help us greatly to deal with those complex challenges.
Your responsibility should be related to what you actually build for business, not to all the preparations that need to be carried out beforehand. To efficiently use serverless services – for example AWS basics, DynamoDB and Lambda – for a production-ready solution, you need to know much less compared to EC2/containers management knowledge.
What else is there to gain?
Serverless technologies not only help you to remove weight from your shoulders but they also improve scalability, security and reliability of the application. A great example given by Yan Cui is that you may spend most of your time building applications and dreaming about finally getting some traction. When this day arrives, your servers can’t respond quick enough, are often not ready to tackle the traffic peak and you end up losing the opportunity.
The last but not least reason is that serverless is also cheaper as you don’t pay for sleeping servers but only for what you need, plus there’s much less security to handle. This all results in better velocity. Your server offer would now be closely aligned with the demand all the time.
Don’t get me wrong …
it’s ok to reinvent the wheel as a challenge or to give yourself the chance to truly understand how things work. But we should also constantly keep in mind: what do we build, why and what’s most important in the short run. Meeting the business requirements that will align with what your customer wants or to prove yourself you can do it all on your own “without cheating”?
Finding the balance between these two aspects is tricky and you should try to ask yourself regularly if your time is used wisely.
Is serverless the new perfect alternative to traditional architecture?
The technologies listed in this article as examples are just that, examples. They certainly provide many advantages, and many projects leverage serverless architectures successfully. It doesn’t mean that you need to throw away your well-oiled traditional architecture. The main point is to try to benefit from serverless tools and services when it makes sense to you and when it helps you to focus even more on what really matters.
Do more, with less?
Thanks to Yan Cui for the great talk.