I discovered the idea of a serverless backend back in 2015 through an AWS conference. Looking back, I was just a young developer, eager to learn it all and soak up everything that got thrown in my direction.
Over time, I also managed to convince upper management to let me architecture a switch from an EC2 styled set up to a serverless architecture that utilized Lamdba, API Gateway and S3. The monetary savings were instant as the payment module changed from pay per hour used to pay per million calls.
Here are some lessons learned from the entire experience.
You might be able to write the overused hello world lambda function and link it to API Gateway, but anything beyond that requires further knowledge.
Frameworks help a lot
Serverless is one of the best framework options out there that deals with creating serverless architectures. Not only does it provide an end to end tool set that enables deployment from your machine, it also allows for a more natural workflow between localhosts, github and AWS.
Not only that, the framework also supports other major players such as Azure and Google Cloud Platform — making your code portable between platforms (to a certain extent) without having to rewrite the entire thing from scratch in order to conform to the requirements of the service.
Serverless is like a fancier version of shared hosting
The idea of not having to manage servers sounds ground breaking, but if you really look at it, the idea is very much similar to shared hosting providers — but more technical and made for developers.
While there isn’t quite a one-click installer as such, you’re not required to deal with servers, its upgrade, maintenance, up time and load balancing. That’s all up to the service provider to optimize on their side and only charge you for what you actually used.
The idea of serverless takes away the server so the developer can focus on creating applications rather than deal with infrastructure and its optimizations.
It’s easy to cheat but don’t do it
Just because micro services are small, it doesn’t mean you can take shortcuts with it comes to code quality.
SOLID principles still apply. Observe your code from the perspective of cohesion within its sphere of influence. Sloppy code contribute to a series of speghetti functions that will turn into one big gloop of uncomprehensible code. This will only serve to subtract from the benefits of micro services and what it has to offer. The costs you saved will be taken away in the form of refactoring or rewriting.
Bake automated pipelines into your workflow from the get go
While Serverless framework creates and solves some workflow problems, it’s not the holy grail of everything. Production deployments, roll back and contingency plans are required for commercial projects and it’s best to start your serverless adventures with automated pipelines in mind.
For AWS, Code Pipeline has the potential to handle this. The thing with AWS is that if you think you need something, they probably have it as a service for you. Having knowledge of the different services available can also give you perspective on what you can do manually yourself or delegate (for a small price) to AWS.
Be careful of who you give admin credentials to
It’s very easy to just give someone the admin credentials. However, this can be very dangerous if that person happens to be unskilled. It’s like giving root access to someone that may end up costing you more money than its worth.
Learn how to use IAM roles and security groups. There are a lot of services available on AWS with some being more costly than others to run like EC2 extra large instances. While serverless itself is quite minimal in costs, limit the credentials shared to only what’s needed for security, safety and wallet protection purposes.
Don’t over architecture
When we start something new, we can often fall prey to over architecturing. However, the trick is to understand the scope of your project, how it fits in with the rest of your current existing infrastructure and create clear boundaries for your serverless application.
Keep your architecture as simple as possible. When you’re stringing together several lambda functions, it can cause a certain amount of latency. If you keep your functions small and to the point, its easier to maintain in the long run.
It might also require you to rethink the way you consume and output data through APIs. Optimization of your database structure may be needed in order to increase your ability to construct code efficiently.
In the 2 years that I worked with serverless, the company ended up cutting at least a third of its infrastructure costs through it.
For our case, running a serverless set up is much more efficient and effective than running your own servers to serve APIs. The question then become, if it’s so cheap, why isn’t everyone doing it?
When working with serverless, you need transform your current set and think slightly differently when it comes to creating micro services. Legacy code architectures are not directly transferable and the cost of migration may be much greater and unaffordable for some.
The thing with serverless is that it focuses more on your skills as a developer rather than your knowledge and skills of AWS itself. Booting up a set of micro services through Lambda and API Gateway is super simple in the beginning, but it’s the other stuff — the workflow set up, the architecturing, the coding and the reviewing that determines how well-formed your final product is.