Serverless Architecture – How & When To Leverage It

November 24, 2020 | By: Adrian

If you were a contractor, Serverless Architecture would be like building without having to worry about the necessary embedded infrastructures of plumbing, electrical wiring, or city mandates. You could just build freely while someone else came in and handled the logistics for you. 

Serverless architecture does all of the provisioning for your business in terms of managing and scaling servers to run your services, applications, and databases. In addition, Serverless computing supports an a la carte approach to billing in terms of charging based on usage. Sounds good, doesn’t it?

But what’s the catch? There’s always a catch…

Should You Build Serverless Architecture?

Traditional servers can be complicated, testy animals requiring 24/7 monitoring. The early dawn mornings with coffee and patching, the late nights…with coffee and updating – arguably not the best lifestyle for your adrenal glands – especially if you suddenly find yourself facing errors that affect your production, but necessary to ensure optimum availability for your services. 

While the dream of a regular sleep schedule is tempting, let’s be objective and break this down. 

Pros

Pricing

Sometimes, it’s all about the money. Or at least, financials are a major contributing factor when it comes to business decisions. Serverless architecture is execution-based, (meaning you’re charged for the number of executions you make), with an allotment of time (in seconds) related to your memory requirements. 

So, for efficiently run functions, serverless architecture is really viable. There’s also the additional bonus of saving money on your back-end staff as many of their tasks can be absorbed with a serverless approach. 

Easy Environments

This bonus is an offshoot of the way serverless pricing works – setting up environments with a serverless architecture is a no fuss process and you can expect to be charged per environment. 

External Dependencies

Most SaaS and e-commerce companies rely on third-parties to fill out their framework via external libraries. If you have basic projects that can be packaged directly into your applications without compromising functionality, then serverless architecture is a good option.

Scaling

With serverless architecture, your cloud provider becomes responsible for scaling with a supply and process based on your usage. When we think about traditional scaling we think expansion only but the serverless approach acts more like a pair of lungs, expanding and contracting based on need – making them elastic as opposed to scalable. 

Cons

External Dependencies

Yes, we have this one here, too. Third-Party dependency can be easy with a cloud-based system, or more challenging – it just depends on the volume of your libraries. In this case, more is not merrier, the more basic your processing needs are, the better a serverless architecture will work for you – remember, with serverless you limit your access as you no longer directly manage the server infrastructure. 

Access via API

Access to a serverless architecture is supported via a private API which you have to create at onset. This plays again to your more limited access as you are restricted from the direct IP. 

Provider Control

We’ll put this as a con because people, generally, like reliability and control when it comes to their services. One of the disadvantages is that your cloud provider is it’s own company to which you are outsourcing a crucial aspect of your needs. The solution is to be critical with the content of your Service License Agreement (SLA). As you are not managing your servers you need to have a clear outline of guaranteed uptime percentages, and functionality. 

How to Build a Serverless Architecture: Use case with AWS Lambda 

Amazon Web Services provides an easy setup via AWS Lambda, as an example, let’s take a quick walkthrough setting up a serverless application.

Let’s say we’re going to build an application to store raw data. We want our database to send event alerts when we push edits or changes. 

1. First, we need to configure AWS Amplify to host our static resources. This is simple as we only need to create our GIT repository and enable hosting via the AWS Amplify console. 
2. Next, we need to make sure that we can subscribe the users we need to have access to the database. We do this by setting up an Amazon Cognito pool so our users can register.
3. Now we have to construct our backend with AWS Lambda, this is where we can write a function to generate metrics from our updates. 
4. We’re almost at the end, now we need to unmask our metrics function using a REST API. This process will make our API available publicly so that our users can access and call the functions we need them to have to receive our valuable database updates. 
5. The final step with AWS Lambda is to tidy up your creation process and remove all the unnecessary apps and resources you used to setup your app. This is less an organizational move and more a security precaution against unplanned or unwanted updates to your app. 

No matter your needs, whether you’re hosting a single application or a fleet of functions, there’s a lot of potential in a cloud-based approach but you don’t have to navigate this serverless world on your own. 

Have questions? We have a large network of people with answers. Call us today to implement your next digital transformation project.