Understandably our backend sometimes doesn’t get as much focus as the app but it’s pretty darn cool. @Mathias posted today about how we use a serverless system to keep our tech resourcing hyper-efficient. It makes cloud look antiquated.
@Mathias, really well written and comprehensive article (opinion from the IT dummy perspective)!
One thing I am curious about, what would be the advantages of renting compared to Serverless? Is it something that becomes more financially viable with bigger volumes of data or simply a soon-to-be obsolete service?
Main benefit is it allows for dynamic, changing demand and you tend to pay per invocation of a function. So if you have a huge spike in the morning and then nothing for the rest of the day, you are still paying for the rest of the day if you rent a server for the month, while with serverless you are just paying for when it is used.
This line from the blog sums it up:
You only ever use what you need, when you need it.
The other big benefit is you can focus on coding your business logic rather than maintaining and managing servers.
Well written article.
You mentioned ‘Firebase functions’ in the post. Does that mean you also use other Firebase products?
Thanks for elaborating, I am still curious why other companies would rent the whole shebang and not go serverless? If serverless is cheaper and more effective, there should be benefits for the a full server rent, right?
Summary of common reasons:
- Lack of familiarity, cost of getting familiar, cost of restaffing, training staff, cost of change
- Their use case is stable and they have consistent demand
- Intense demand, at which point you could argue Serverless is more expensive.
- Need specialised equipment
- Vendor lock in if you are not careful ( big one )
Other reasons too, this is just off the top of my head.
General comment unrelated to Freetrade’s choice: Tech choices are complicated, subjective, based on staff, resources and objectives. It’s one of the reasons why huge projects fail or are delayed.
When you do go into more depth, would be interested to hear about Firebase vs Lambda
Serverless is very very cool, wouldn’t stop going on about it when I learned to use Lambda.
Hope you’re all being a little more careful than most were (and I’m sure you are ) and hosting in more than one region, unlike those who were part of this beautiful moment in internet history: https://www.npr.org/sections/thetwo-way/2017/03/03/518322734/amazon-and-the-150-million-typo
Definitely one of my favourite stories to tell non-techy people to scare them with how much bigger Amazon and related companies are than they think
That’s exactly it. Could not have given a better answer
Sure, I’m not very familiar with lambda though, but when I go more in depth about why we think Firebase is the right fit for us, I will try to include some comparisons with what other providers have to offer.
Thanks. My original response was a race with the coffee machine
Noticed sometimes people mention they are recruiting at the end of technical posts, might draw the right crowd ( who knows ). I was going to ask how sourcing candidates is going for a serverless stack but I’m scared your time will be consumed by recruiters and rockstar candidates or worse ( maybe better ) ninjas. Where have the bearded wizards or the gurus gone. Joking ( maybe in bad taste ), not all recruiters are bad, and not everyone is funny ( me ).
That’ll explain why Firebase Functions instead of AWS Lambda, Azure Functions, or even Google Cloud Functions. If I had to guess, beyond the obvious ( it’s a decent service ), I’d think the realtime services Firebase offer were/are a big draw, and maybe Viktor’s ( ex Google ) contacts help( ed ).
It’ll be great to learn more about serverless architecture, development process(es), and how you approach testing serverless.
Sorry if I am spoiling future posts. Just say, I’ll be quiet and wait
Yes, the real real time services that Firebase provides you with, plus Viktor’s help in getting us (quite a few) free credits to use Google Cloud Platform, it soon became quite clear that this technology stack would be a great fit for us.
To be honest, development processes and testing are still big issues regarding serverless, and with the complete lack of industry standards, we are still trying to figure these things out by ourselves, which takes time… but it makes the work even more interesting in that regard
Yes, 99% of the examples are super simple to communicate the idea, plus they tend to show all the logic in the handler so anyone copying blindly can have; hard to test, highly coupled, poorly structured code The best we have is, some vendor normalisation via the Serverless Framework. I can imagine all the other challenges like debugging, monitoring, configuration, startup latency etc but it’ll be worth it just to reduce number of stressful days trying to add & manage more servers ( hyper growth ). I look forward to the more technical post on this.
Guessing you went with REST over GraphQL to keep that side simpler?
By the way is the BETA label on Firebase Functions accurate? Or is it a solid Release Candidate?