agsandrew - Fotolia
When compared with traditional apps, serverless apps have many benefits, particularly since developers no longer have to worry about physical and virtual server provisioning and maintenance.
With serverless, a cloud provider handles all the typical scaling and maintenance work -- such as OS updates -- that come along with traditional architectures. Devs also don't have to worry about instance types, resource scaling or the costs of idle computing, which lets them focus on what makes their application unique and the potential features that will enhance its functionality.
But there are crucial decisions that development teams must make before they commit to serverless. These include team staffing, development framework selection and testing methods. This serverless architecture tutorial addresses these three critical, upfront considerations.
Your development team
The first thing to understand is that developers are the central part of serverless adoption. While there are low-code ways to start prototyping serverless applications, developers that build the needed custom logic are the mainstay of a serverless environment. Specifically, you'll want to hire a team lead who understands frameworks like Serverless Framework, Serverless Application Model (SAM) and Chalice.
The team will need developers for each specific aspect of an application. Chances are that there will be an API component and a front-end component. For this, you'll need to create two separate teams of developers, and each one should dedicate itself to one of these components.
If a website needs a mobile companion app, there should be one or two developers for each. Your team lead's responsibility is to make sure all of the separate development teams coordinate, just like with a traditional application stack.
Picking a framework
The next thing we'll outline in this serverless architecture tutorial is the importance of framework selections. There are pros and cons to each serverless framework, including the three popular ones mentioned above.
The chief consideration is that the framework you choose can handle your application's specific requirements without adding too much more development time. For example, Chalice might be great for those who use Python but not so much for those who use Node.js. Serverless Framework is great for Node.js but doesn't support Python as well as Chalice does. And SAM is great for AWS, but it won't work on any other cloud platform.
The best framework choice is often the one that your development team feels most comfortable with. Have your team try each one to see which ones best fit their development style.
Explore other serverless architecture possibilities
Serverless is more than just function as a service (FaaS), but it is often a big part. AWS Lambda made FaaS and serverless both especially popular, but not all FaaS is serverless. For example, Docker Functions enables you to run just your code, but you still need to manage the underlying scaling.
Organizations that need more control over their underlying environment may still want to use containers, and serverless container options exist. This type of architecture requires more heavy lifting from development teams, but it can lead to increased flexibility. For example, systems that require long-running tasks to compile code or to build a video file might need a Docker image with preloaded custom software that takes over an hour to run. This scenario wouldn't run on FaaS-like Lambda, but it could run in serverless containers on something like AWS Fargate.
Databases can also be completely serverless. DynamoDB recently announced support for an on-demand capacity mode, completely auto scaling for you and enabling a true serverless database. When there's no usage, you pay only for storage. When there's a massive traffic spike, the on-demand capacity automatically scales, and your application can rest assured that DynamoDB will be able to handle the traffic. Other serverless databases are also available, including some relational databases, such as Aurora Serverless, for those who need more traditional SQL-like access.
The final thing to cover is testing. If you picked a framework like SAM or Serverless Framework, then it is important to create a testing environment that can closely simulate production. Have developers set up individual accounts with your platform provider so they can mimic their defined production environment. In AWS, for instance, developers can create separate accounts in order to test their changes prior to production.
But this approach can be risky. Keep access keys and other sensitive information outside of any general code repositories. Set up a secure storage environment, such as Systems Manager Parameter Store, or encrypted DynamoDB tables to access this information, even during local development.
If you must store sensitive information within environment variables, encrypt them, and use Key Management Service or another cloud-based service to decrypt. Finally, store all configuration variables in config files, including ones passed in via environment variables.
And make sure there are automated, end-to-end tests alongside individual unit tests. What if you didn't configure Amazon API Gateway to support binary output, but your Lambda function is trying to output a PNG? It may appear to work properly during unit tests, but API Gateway will garble the PNG output in an attempt to output plain text. This is why it's important to use something like Ghost Inspector or New Relic in order to actively monitor changes and install logging frameworks, such as Sentry or IOpipe to monitor real user errors.
Serverless is a great option for application development and management today but only if it's configured properly. Follow the advice outlined in this serverless architecture tutorial to make the most of your adoption.