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: Amazon And The $150 Million Typo : The Two-Way : NPR
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
please continue
Just walked by @Mathiasās desk right now.
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?
Weāre hosting the Serverless London meetup next week & weāll be talking about Google Cloud Composer and how it fits into our stack. Justin Grayston from Google will also be sharing his Google Next talk. Itād be great to see some of the community there if you can make it
Which tool you use for local developement ? I faced bit difficulties with serverless in local development. Specially with NodeJS.
Hey @shivanshuit914 - this might be surprising (it certainly was to me initially) but weāve found exercising code via unit tests is often enough locally. Serverless functions are smaller more isolated pieces of code so thereās less āsystemā to test when you make a change. This gives you greater confidence before pushing to your own test environment. That said there is tooling to allow local testing The Firebase Blog: Testing Functions Locally with the Cloud Functions Shell but we tend to use it less often.