Serverless: Learn how to get it in your team without making them AWS Cloud Architect Experts.

Cleriston Bernardes
Sep 24 · 7 min read
Image taken from Microsoft’s blog (https://devblogs.microsoft.com/devops/cloud-hosted-mac-agents-for-ci-cd-pipelines/)

Serverless architecture has been attracting many companies’ and developers’ attention as it claims, among other things, to increase productivity and reduce (if not remove) server maintainability. However, as many other good solutions, there is a complication which has been preventing companies to go through: It still requires a considerable amount of expertise in Cloud Architecture combined with Code Design.

There is no magic (not that I am aware of) to skip the step of understanding cloud concepts, but, even though it will still be necessary at least one team member holding this knowledge, there are few approaches such as code responsibility and aggregation, tool exploration, environment configuration, tests and knowledge sharing which will allow every individual in a team to make code changes without mastering the obscure cloud world.

Serverless architecture is the concept of having an application running without a server. Naturally, an application needs to be on a server, but in this case, the server is not part of the scope (actually it is unknown) and it is managed by a cloud provider. As a result, there is no longer a need to have complex management of scalability or availability. Serverless is also an open source framework built by developers and maintained by a company, which provide tools to manage serverless apps.

Explore the cloud provider interface or website to build the API

Whilst creating the application through the provider’s interface defeats the purpose of the Serverless framework (it is exactly to automate this task), it helps to visualize the pieces, components and resources necessary to build the application - Not to mention that the cloud structure is very likely to change from one provider to another. It is easier to understand, for example, that an Api Gateway has a path which contains one or more methods which will invoke a lambda, if you can visualize the whole application. Seeing the big picture gives a better support to understand where to configure an authentication, cache, methods or any other things you may need across your project.

API Gateway resource details from AWS management console

In addition, this approach could be used to implement any new component or resources into an existing project. Imagine there is a new requirement to create a proxy integration and there is not even an understanding of what it is or what would be the provider’s solution for it. The best approach would be a POC through the provider’s interface and then, after validating its capability and limitations, consider to write its code template.

As this task does not have to be limited to only one person, it is important to create an isolated area (maybe a Lab) where the team can have different attempts of exploring the cloud tool without breaking or “polluting” the current development environment or without impacting any other application.

The goal is to build, at early stage, the application through the provider’s console and, from their interface, have a reference to compare with once the architecture is translated to the Serverless framework. In other words, create through the console, then build through the serverless deploy and finally compare the output.

Aggregate Responsibility and Code Accordingly

This is the most important part to make the project easy to interact with by any team member. The idea is based on the first SOLID principle and even though it sounds obvious, it is sometimes ignored very easily. In general, the project can be categorized in two types: cloud structure and code.

The serverless cloud structure is defined through a yml file and it should contain info related to the app cloud structure. The framework will use this file to build (before deploying, there is a step where the framework translates the written code into a, even more confusing, cloud structure) the cloudformation of you application before pushing it to the cloud, so basically this info is only used to build your app.

Regarding the code, as it is more extensive it can be aggregated in subcategories such as functions, includes/common, tests, crons, config, etc. It not only will guide the development team to know where the information are but also decouple the code. It will work as a road sign which will lead them to the right path and make them more aware of the consequences of their changes. A readme.md file for each folder and code comments could be very useful as well.

Project structure example

Allow devs to run the project locally

It may sound obvious, but considering that serverless is a cloud based architecture it is very tempting to consider there is a need to have the application on the cloud in order to test it or even validate the new implemented features. However, because of the time and effort to push the code changes to the cloud, it is important to allow the team to check/validate their code locally before pushing it. This will actually give the feeling of a non serverless application and will not only increase the productivity, but allow the team to catch issues before the code is pushed.

Ideally, to start the application locally, only two commands should be necessary: “npm install” and “npm start”.

There is a plugin called serverless-offline, which allows the serverless api app to be simulated locally.

Configure environments properly

A common thing across development routine is switching to different environments (dev, stag) or changing information in the config file, and, if not not organized properly, it could become a mess very quickly. In order to avoid this problem, it is suggested to create config files and use them according to the value informed as the Stage. Imagine a proxy integration endpoint which needs the URL and Authorizer to be configured. These two info could be set up in a config file and referenced in the serverless template. This will make more intuitive for the team to change if there is a new version of the URL or the Authorizer.

In the yml file you can export the config values and use them to change info in your cloud structure, like this:

custom: ${file(./config/${opt:stage, 'dev'}.js)}

And in your code something like:

const config = require(`../config/${STAGE}`);

This will allow not only changes in the architecture (db name, lambda timeout, environmental variables, localhost port, and so on) based on the environment, but will also give the flexibility to inject different values dynamically throughout the code (third party access keys, urls, secrets keys and so on). Whereas Serverless uses the parameter “stage”, this is a similar approach of using the module “config” in Nodejs. Bear in mind that if the project starts to grow too big and the config file starts to be too complex, it could be split in two categories: template and code.

Even though these are the most common scenarios, the configuration domain could go even further. Consider a WhiteLabel app where each client would have an unique configuration. In this case every single client would have a configuration for each environment.

If possible the team should be able to easily switch locally between different environments, config values or clients.

Use tests to empower the team

Tests, like in every product, gives the team the trust that: even though changes have been made, the tests will validate the overall behavior of the app and will inform if something goes wrong. It is known that test will not guarantee failures 100%, yet it gives comfort to the team. They no only empowers but it also brings value to the team when included in a CI/CD pipeline taking in consideration it will block code deployment if there is any failure.

It is important to understand this is not an approach to encourage the team to write piles of code recklessly, but to give them the confidence that they can make changes and locally validate their behavior.

Share knowledge across the team

While few people only see the code revision as an one-way of code validation, it is a powerful way of sharing knowledge across the team. Instead of having one person doing the code review, allow everyone in the team to validate the code and, as a result, be aware of what has been implemented. This will no only boost the team growth but will prevent some team members of receiving a call during holidays just because there is no one else capable of taking care of few situations.

Evidently this is one example of how to share the lessons learnt during the project development, but it is important to understand what works better for the team and build a process which will bring value to everyone. There are people who prefer code comments, documentation, pair programming or code sharing, which are all effective ways of improving the team skills, therefore the team has to choose what works better for them.

Conclusion

Regardless the application type, most of the projects usually contain modules such as Authentication (access validation), Controller (business logic), Model (for DB access), Scripts (for scheduled execution or automation), Tests (for CI/CD) and beside the fact it is already complicated to implement them in an ordinary environment, doing it Serverless will no only require this knowledge but also the understanding of how these modules can be translated to the cloud architecture.

Although it may look too complex to be implemented, serverless can not only be added to any company but be handled by any type of developers, whether they master cloud architecture or not. The key is to make sure the project is organized in a way that it is intuitive to develop and it has some facilities like tests, documentation, proper configuration and isolated environments which will give the team the trust and encouragement to do what they do best.

Glossary

DB: Database
CI/CD: Continuous Delivery / Continuous Delivery (or Deployment)
stage: Is the parameter used on serverless framework to defined the application environment. It could be something like dev or prod for example.
POC: Prove of concept. Superficially trying something in order to understand its applicability.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade