Building a fully serverless API architecture
TLDR; Serverless architecture seems to be the popular cloud architectural choice for business with small runnable projects, and removes the costly overheads typically associated with server/data center management.
A common problem with software developing is the thinking is done after the fact, which doesn't lead to the best architectural decision. In fact it often leads to JGID architecture, which is Just-Get-It-Done Architecture. The problem with this architecture doesn't lead to the best outcomes. For example did you define which types need to be added based on their suitability when considering the end to end journey. Or was the decision made based on the type could be implemented with the least effort.
My preference for architecture is to lead with developing.a solution that meets the use case or business requirements. For example I added an example sketch of an initial for my proof of concept http://www.wotd-app.com. This is part of a project to develop the API end to end journey, one of the option is to look build a serverless API which parses a flat JSON file in S3 and returning value based on whatever random number is sent from the client side.
What is Serverless Computing?
"Serverless computing is a cloud computing execution model that allows developers to build and run applications and server-side logic without having to provision or manage servers. Serverless computing is also known as "Function as a Service (FaaS)"."
Bard 2023
Serverless computing is all of the rage in 2023, it is used to describe the next step in Cloud computing. When I first started working with websites and computers my dream was to have a virtual private server with my own person web domain. To have a box that I can adjust add new folders to, and have full control over. I had spent a lot of time using website builders, but I wanted to write a file and upload it via FTP and see my page be shown.
The website is no longer gone, domain since expired. And so has the era of managing your own person box.
Serverless computing has massively decreased the amount of time to get up and running with your web application, which ultimately means a shorter time to market. Time to market is often the criteria by which innovation is judged, to secure the interest of the Early Adopter crowd with a nice subscription deal for a minuscule amount a month, while you rush to develop your full product.
In my proof of concept, I found I could use a combination of serverless services to build a fully fledged API, that could meet the demands of my small project and for a minimal cost - as you only pay for you use, so no concern over a massive monthly cost for an app that is not receiving any traffic.
It does have pros and cons:
Pros:
Some of the Pros include:
- Reduced maintenance overhead these services tend to be managed
- More cost effective pay for what you use - this can be critical with new projects, as you don't necessarily know if there will be uptake so business don't necessarily want to get tied in with a large upfront investment, but serverless pay as you go pricing model make it easier for you to de-risk a new venutre.
- Easier to scale - as the capacity is often managed by the Serverless provider, so configuring auto-scaling can be as simple as changing a configuration setting.
Cons:
Some of the Cons include:
- Potential risk of vendor lock in - the risk with any managed service is that you become dependent on the vendor for all of your needs, which can make it difficult to move later.
- Less control over your infrastructure - while this can be a pro, this can also be a con as it can mean patches, operating system updates are also offloaded to a third party, which can introduce a separate risk for potential incompatibility issues to arise.
- Better suited for small runnable pieces of code - for a component which doesn't contain complex runtimes or long running process the cloud can work very well. However if you have long running batch jobs or workloads which required sustained computing power serverless options may not be the preferred approach, as many serverless workloads bill per running hour, which is better for shorter running jobs.
As with any Pros and Cons list, they need to be evaluated in line with the organisational strategy and business objectives.
In conclusion, Serverless architecture seems to be the popular cloud architectural choice for business with small runnable projects, and removes the costly overheads typically associated with server/data center management.
Related Links
1) https://azure.microsoft.com/en-gb/solutions/serverless