ShreyTheCray Interview: Serverless Framework & Cloud Explained

We love to talk about Serverless and serverless development and when we were invited to have a chat with Shreya from the ShreyTheCray YouTube channel, we jumped at the opportunity. The interview is now live on YouTube.

The discussion covered a range of topics from:

Why Serverless is important
General guidance for newer developers entering their professional careers
How local development in Serverless works
Where the future of Serverless is going to go
How you could consider migrating your existing application to Serverless

Transferring Apps to Serverless

Your focus should really be on making sure you bring value to your business and if you find yourself in a position where the current solution will not help reach the goals of the business, then a refactor or a rebuild of some type may be needed and this is where Serverless can become very useful.

Instead of trying to build something in isolation away from customers and providing no real benefit, serverless development can be used to slowly transition the application over time. Starting with something important but not critical, allowing proofing of the technology before investing a large amount of time and effort, you can transition one piece at a time to a new serverless architecture.

This is known as a strangler pattern where small pieces of functionality are essentially pulled off, built alongside the main application and eventually moved over when ready, with the old code no longer getting executed.

Fighting Complexity with Tools

Shrey asked if there were just way too many tools to learn and that we need to use as developers. According to Gareth this isn’t actually complexity for complexities sake but a symptom of the very real shortage of skills and developers out there to do the work needed. All these tools are being built to help fill the gap and make the developers you do have more efficient.

Serverless itself is essentially an answer to that. Let developers bypass as much as possible time spent putting together infrastructure, and focus on solving business issues instead which is where the real value is.

Best Practices

Starting with simplicity, this can be applied to building any system. While making it complex with many moving parts makes it look impressive from an engineering perspective, that is usually a bad idea. Even in the Serverless world, with the huge array of managed services available to you in AWS, you could build a solution by connecting every esoteric service with incredibly large Lambda functions. If you can just get away with using an HTTP endpoint that meets all your needs, then that’s what you should do. One advantage of building serverless is if you had to change that later (perhaps adding an SQS queue will ACTUALLY be useful), it's pretty easy to make the changes you need.

And try to reduce your code footprint. Serverless services can help you replace a lot of the functionality you would often have to provide for in code. Why? Because, believe it or not, code is where your bugs are! So the more code you have the more chance of introducing bugs. Your custom code has had way less QA than the managed service you use to bypass writing so much of it.

Local Development

Unlike traditional application development where running a local version of the application on your own machine is pretty much a requirement and usually the first step you go through when joining a new team, the problem with this in the long run is that your machine is not like the production environment. Often this means that code taken from local to production doesn’t work the way you expected it to.

While it is impossible to replicate production for every member of the team for these applications due to costs and complexity the opposite is true for Serverless development; spinning up your own instance of production is a single command away and costs nothing, while attempting to replicate the production environment locally is exceedingly hard.

The best practice is to really stick with developing and testing directly in the cloud instead.