Serverless has been around for a few years. It is not a brand new idea, but it is a new way of thinking about building applications.
I always tend to think about why I am doing something before I think about how I will do something. It helps with motivation, product design, and understanding. It encourages you to rethink existing "well-known" solutions and also ensures that you verify the assumptions you make on a day to day base.
That is why the "why" of serverless is the most important. If you don't understand why you are using serverless, you will fail to implement it properly. That failure will erase any benefit you thought you had.
All of these mean the same thing. Serverless allows an individual or a company to focus its entire efforts on its Unique Selling Proposition (USP).
All the other benefits are just descriptions of allowing your team to focus on your USP. A good organization should be laser-focused on their USP, and a serverless mindset ensures this happens. As a developer, I do not have to manage servers, create and manage databases, scale servers, deal with downtime, build in fault-tolerance - all aspects of building a scalable system that are HARD to manage. As a manager, I can spend far more time focusing on the process and the purpose.
Having a paradigm in place that abstracts away the entire job of scaling and operating a worldwide application is a fantastic boon for creators.
Don’t let your developers turn into firefighters.
It takes time, it takes effort, and it takes expertise to get up to speed, but serverless ensures that creators create, rather than firefight. Serverless reduces churn, increases productivity, increase scalability, and allows you to generate genuinely game-changing applications within a small team.
That is why you should choose it - hands down.
If you do it right - serverless is THAT good.
Most companies don't do it right.
What is Serverless?
Once you understand why you might go with serverless, you need to understand what a serverless solution is. That explanation needs to be as simple as possible so you can easily verify your decisions along the way. Knowing what serverless is becomes essential because it won't work if you don't double down on it. Keep repeating a simple statement in your head.
Build every decision around being serverless. Only after you have exhausted all alternatives should you look toward something else. As soon as you introduce one non-serverless component into your application, you introduce a leak. A single decision, a single point of failure becomes the kink in your serverless armor.
You've defeated the whole purpose, you’ve crippled yourself, and your competitors haven’t even had to lift a finger. I like simple explanations, they have far more sticking power. Jeremy Daly had the simplest explanation of serverless I could find.
Anything that doesn’t have all of these attributes fails the test. If it fails the test then you need to have an exceptionally good reason for why you did it a different way.
Taking The Leap
Converting the paradigm that your company or team operates within is hard, the larger the organization the more difficult the decision is to make. New companies and new applications have the benefit of starting later.
However, before you decide to stick with what you’ve got, think hard about it. There are only a few genuine edge cases where a properly implemented serverless solution is the inferior one. It acts as a check on your team, ensuring you are always focusing on where you provide value. In 90% of cases.
Jesse Moore — Chief Technology Officer — firstname.lastname@example.org
P.S - if you are interested in working at a company that is hell-bent on being serverless, building great products and upending a broken industry (Advertising Technology) - shoot me an email below with your CV, an example project and an example piece of your content (blog post, youtube, etc). I will respond to all genuine applications.
P.P.S - I’m a big fan of Amazon’s serverless architecture and have outlined it below.