Close

Serverless Architecture on AWS

Man jumping free: serverless architecture

You have a vast amount of choice regarding how “managed” you want your infrastructure to be, on AWS. Here’s what you need to know about serverless architecture.

AWS provides many ways of getting the same IT function, but with different levels of administration required and varying flexibility. You can own and manage your individual components – with obvious parallels to on-premise infrastructure – or pick managed services where AWS look after a lot of the detail for you.

A simple database example

With on-premise IT, if you wanted a database, you got a server, configured the hardware and storage, installed the operating system, followed by the DB app – MySQL for example; and kept it all running from then on, as best you could.

On AWS you can:

  1. Do the same – get an EC2 (virtual server) instance and some EBS storage and build and manage it yourself.
  2. Use their relational database service (RDS). You specify the application version, hardware, resilience and database options and AWS just provide it, at a set rate. You talk SQL to some name they give you, but you don’t get a server to log onto. You just know it’s there, being maintained and patched by someone who isn’t you.

Serverless Architecture

Serverless architecture is the same kind of idea, taken further. There are servers involved somewhere, but you never see them and don’t have to worry about their configs, scaling, maintenance of operating systems or hardware. You upload chunks of code – designed to talk to other managed services – and something takes care of running them for you.

It becomes someone else’s problem to design, deploy and keep the underpinning parts of IT running. And it’s also their problem to scale the low-level hardware appropriately, to match demand and configuration.

Does it make sense for everyone?

No, but like a lot of Cloud, it’s worth knowing the facts about what it is, and what it isn’t, and deciding in advance if it’s suited to your particular IT use case.

Like some other Cloud services, it kind of depends on whether your business runs its own bespoke applications, for users and clients. If you don’t architect at code level, you’ll probably be more interested in SaaS offerings from vendors, to achieve similar ends.

Even if you do architect bespoke systems, it’s still sensible to go through that whole ‘what would we need to do, how much would we save after, and is it worth pursuing’ process carefully, because you’ll need to do work and make changes, and so the returns depend on what form your code is in already.

A dynamic website example

Let’s say you have a dynamic website, running some kind of web-based company application that’s structured like this:

  • front-end web servers which take care of login and authentication, and serving presentation content (e.g. interface structure and media) to users
  • separate or combined servers for the middle layer logic or application functions; e.g. to take whatever the users are clicking and entering, process it in some way, and store it in….
  • …a database back end of some form. From large clusters to NoSQL perhaps.
  • Some or all of these servers and tiers load balanced, and have to be secured, capacity planned and/or scaled appropriately to cope with the user demands

On AWS, going the Serverless route might lead to something like this:

  • Static presentation web content stored in S3 (S3 is simple storage – but as it’s HTTP based, you can quickly create a static website out of a bucket of files, just by selecting options)
  • API Gateway – a service that allows you to define HTTPS-based APIs as web queries, for dynamic stuff that currently links through to your code that runs the logic or application functions. This integrates with the AWS global distribution network, Cloudfront, for availability
  • Lambda – the ‘differentiator’ – allows you to upload code, in one of the supported languages, and configure when it is to be run, in response to triggers you define – e.g in response to requests via the API Gateway. It can run in your own virtual private cloud for better security.
  • Database back end – this can be anything the code can talk to, but for ‘serverless’ is usually one of the AWS managed database-tier services – like RDS as described above or DynamoDB, Redshift, etc

You could also use AWS’s IAM security and user authentication framework holding it all together securely, which can save a lot of time versus building your own user authentication models. The APIs you define have their own resource-name ‘identities’ which can be used in AWS security policies, and each Lambda code function has its own IAM security role, allowing proper locked-down access to other AWS services.

Why bother?

It obviously takes time to chunk up your code into separate, logical, uploadable bits, and integrate it back together around AWS’s services. So why would this be worthwhile?

Basically, because that work, even if it’s longwinded, is a one-off. In return, you no longer have the steady-state administration of operating systems and underlying virtual hardware to think about, because that’s all managed and scaled by someone else. This means:

  • you don’t have to worry about OS patching or downtime
  • you have no low-level fault-tolerance mechanisms to worry about (or not at server level at least – the application code still needs to be written in a resilient way)
  • AWS will scale the underlying compute power you need automatically.
  • You don’t have to bother with capacity management and usage levels (If you use an automatically scaling data tier (e.g. DynamoDB) you might not actually have to do anything on the journey from 1 user to 1,000,000 users (apart from pay the bills))

That’s the trade off, and it might save a lot for your business.

What serverless architecture isn’t

It does have some limitations. Most of these are obvious, but in the interests of balance and giving a complete picture, these are worth mentioning:

  • It’s not an infrastructure managed service where you can transfer administration of whatever discrete servers you have now to someone else
  • Lambda isn’t able to run any code you like, or binaries (e.g. where there isn’t any source code). Although you can get other kinds of ‘packaged’ AWS service which will automatically provide scaled infrastructure around this if you want.
  • It’s not a lift-and-shift model. Serverless architecture is something you need to design the app around. Everything could probably be adapted – but it may not be worth it until that point where you need to re-architect anyway..

Should you go for it?

If any of the following apply to you, you should seriously consider it:

  • You have a web-based application
  • The logic-tier is written in a supported language or can easily be transferred to one
  • The application will be or is written in a tiered, restful API type manner already
  • You don’t know or don’t want to have to worry about scalability or user demand constraints

The things to consider are the limits placed on your application structure and code dependencies. Dynamic web apps and sites are one thing, business apps can be quite different.

Lambda needs functions to be ‘standalone’, de-coupled from other chunks of the application, and able to in their own bubble, without many dependencies on the OS. This is totally reasonable for a lot of applications, but sensible to check it’s ok with yours.

Other considerations

Time to migrate

An existing decoupled Python app that already used DynamoDB, and linked into IAM could be quick to move. Something written in non-reusable way, with lots of hardwired dependencies, might take so long it’s not worth it. Like many ‘how much’ estimates with AWS – it depends on what you have to start with.

Consumption-based billing

Depending what you application is used for, you may need to consider limits, in the context of unexpectedly large charges. API gateway is billed on the number of calls made, and data transferred out of the Cloud, and Lambda charges are proportional to the number of requests for your functions and the time your code takes to execute.
You may need to decide on a DDoS response strategy, and set limits, e.g:

  • do you try to outperform the attacker – involves paying for enough capacity to respond
  • apply limits and let your app get slow and unresponsive – but avoid the charges
  • Investigate and perform source-checks of the attack origin, and route traffic (possibly based on geographic origin) somewhere else.

How do you ‘go serverless’?

Make sure you have access to both AWS and software architects who will perform a feasibility study and estimate properly and take their time. It’s helpful to have someone realistic who has with a good understanding of particularly Lambda, IAM, API gateway rather than someone who’s ‘just’ set up a few EC2 instances.

Our strong recommendation is to then consider running a ‘proof of concept’ project based on a small portion of your application. As small and quick as possible ideally. Even if that’s not going to lead to useful, standalone ‘serverless’ app at the end of the process: it’ll build awareness and reliably determine how big a job is it (and if it’s worth it or not!)