When SQL & Serverless aren't the right choices
Tags: serverless, sql, architecture, database
Published: 2019-09-28 10:30:18


Now that I have you here, at the end I also share a little about how Shopify scaled it's  development team. Culture & team is that important! 😁

Here are three TL;DRs of the best tech articles that I read this week.

*#database #sql*
### [When SQL Isn’t the Right Answer](http://bit.ly/when-sql-is-not-right)

When you’re looking for 
- something that’s easy to interface with and quick to develop
- cost-efficient infrastructure scalability 
- rapid software development and integrations
- data models that favor the requirements of the business rather than the other way around
- solutions that address creaky bridges between data models and software compatibility

[Check out the full post here.](http://bit.ly/when-sql-is-not-right) 

*8 min read*

-----

*#architecture #serverless*
### [Serverless: 15% slower & 8x more expensive](http://bit.ly/serverless-bad-choice) 

Context (read use case) is always the king when it comes to statements like this. Einar Egilsson of CardGames.io wanted to see if hosting their API using serverless framework made sense & gave it a go. Turns out that for some workloads serverless frameworks can get a lot more expensive than the old & traditional options. 

He set up two instances to route requests for one of their games - one on the new serverless setup and another one on their old Beanstalk setup - to compare performance. Einar ran 100 requests (one database call per request) for both the setups and found the serverless setup to be 15% slower. 

He was paying about $164.21 per month with the Beanstalk setup.The new serverless setup costed much more than what he expected. Their API accepts around 10 million requests a day which translated to about $35 per day, just for API Gateway. Add the Lambda cost of about $10 a day and he was at a cost of $45 per day or $1350 per month - about 8 times more than the $164 per month of the start state setup. 

Two takeaways from this:
* Decide within the context. Stay away from blanket solutions. Use cases matter the most. 
* The “Pay for what you use" always sounds like a cheaper option but you must always do the maths for your use case before making any switch. 

[Check out the full post here.](http://bit.ly/serverless-bad-choice) 

*6 min read*

-----

*#culture #team*
### [How Shopify scales up its development teams](http://bit.ly/shopify-scaling-teams) 

- When scaling up development teams, the first folks to recruit are the recruiters themselves - specialists who understand the company culture & team’s exact needs.
- The number of on-boarded folks on any team is greater than or equal to the number of those still onboarding to ensure enough market & product context.
- Set a clear baseline for teams about how they will plan their work and track their progress, what are the tools and technologies they will use etc. 
- Be very open about technical designs and code changes
- Use tooling to codify best practices
- Use pair-programming to share experiences
- Conduct frequent retrospectives

[Check out the full post here.](http://bit.ly/shopify-scaling-teams) 

*7 min read*

-----

For the last five weeks, I have been sharing small snippets of a few articles that I read throughout the week. This is the sixth post from the same series.

*If you like what I post and want to get the TL;DR versions of all the articles that I read, you can [signup for my newsletter, called in.snippets(), here](http://bit.ly/insnippets-devto6). Every weekday, I will send you bite-sized snippets of some of the best articles on software engineering that are super relevant for backend engineers.*