You can also watch the video version of this here: https://youtu.be/1C-sVyAoznw
Technology evolutions typically disrupt people and roles within an organisation, often creating entirely new roles and responsibilities. For Serverless, I think it is mostly a narrowing and specialisation of capabilities.
For solution architects coming from an application or infrastructure background, there will be a much heavier focus on knowing the managed services that cloud providers offer. It’s critical for an architect to understand what problems each service solves and how they integrate because one of the responsibilities of the architect is to help the team avoid reinventing the wheel or developing unnecessary code. Knowing how the most common services are best configured, the service limits, security considerations and any potential challenges will also be part of their responsibilities.
For developers, there is a push towards certain programming languages that perform better in Serverless architecture such as JavaScript and Python. These languages have lower latency and have many available resources to help speed up development. Besides languages, developers will need to rethink how applications are designed. Changing to microservices is not just a case of splitting a monolith into smaller parts. The interactions between different components, using managed services instead of developing a custom microservice and code efficiency to reduce latency are all crucial elements in a successful Serverless application.
The use of databases in the cloud is also undergoing an evolution being referred to as ‘purpose-built databases’. Traditionally, you would just pick one database to serve an application. Now that we are splitting the application into microservices, we can also reconsider how we use databases and pick databases that are best suited for the data of each microservice. Amazon has several different database services that each perform very well with a particular type of data. For example, ledger type transactions, time series, document or JSON data, as well as the traditional relational databases. This can greatly enhance the performance of a solution, but it does come with the complexity of understanding each data set and picking an appropriate database to work with that data. Database roles in Serverless teams need to have a much wider understanding of the different types of database services and what their strengths and weaknesses are.
Managing the more fine-grained access permissions of Serverless applications and the team members involved can be more work. Certainly when meeting the Principle of Least Privilege. A dedicated team member that is focused on security can be very beneficial and allow other team members to focus on their own responsibilities.
Lastly, DevOps knowledge is crucial for Serverless teams, but I wouldn't necessarily advise having a ‘DevOps’ specialist in the team. With Serverless, infrastructure, deployment and coding are all far more integrated. The infrastructure configuration is typically part of the application code, so it all merges together and having separate team members tends to reduce overall productivity. At least the developers, but ideally all team members should have an understanding of DevOps, automation and tooling. For a less experienced team, having a specialist at the beginning of a project can be beneficial as they can help to set things up, make sure the team gets started with best practices, and provide some training.
To go deeper on this topic and to read many more related topics about Serverless Architecture please buy the book Serverless - Beyond the buzzword here: serverlessbook.co
