Your evolution as a serverless engineer – Introduction to Serverless on AWS
Your evolution as a serverless engineer
Consider the simple serverless application shown in Figure 1-8, where a Lambda function reads and writes to a DynamoDB table. Imagine that you are proficient in TypeScript and have chosen Node.js as your Lambda runtime environment. As you implement the function, it becomes your responsibility to code the interactions with DynamoDB. To be efficient, you learn NoSQL concepts, identify the partition key (PK) and sort key (SK) attributes as well as appropriate data access patterns to write your queries, etc. In addition, there may be data replication, TTL, caching, and other requirements. Security is also a concern, so you then learn about AWS IAM, how to create roles and policies, and, most importantly, the principle of least privilege. From being a programmer proficient in a particular language, your engineering role takes a 360-degree turn. As you evolve into a serverless engineer, you pick up many new skills and responsibilities.
As you saw in the previous section, your job requires having the ability to build the deployment pipeline for your application, understand service metrics, and proac‐ tively act on production incidents. You’re now a multiskilled engineer—and when most engineers in a team are multiskilled, it becomes a diverse engineering team capable of efficient end-to-end serverless delivery. For organizations where upskilling of engineers is required, Chapter 2 discusses in detail the ways to grow serverless talents.
The Parts of a Serverless Application and Its Ecosystem
An ecosystem is a geographic area where plants, animals, and other organisms, as well as weather and landscape, work together to form a bubble of life.
In nature, an ecosystem contains both living and nonliving parts, also known as factors. Every factor in an ecosystem depends on every other factor, either directly orindirectly. The Earth’s surface is a series of connected ecosystems.
The ecosystem analogy here is intentional. Serverless is too often imagined as an architecture diagram or a blueprint, but it is much more than FaaS and a simple framework. It has both technical and nontechnical elements associated with it. Ser‐ verless is a technology ecosystem!
As you learned earlier in this chapter, managed services form the bulk of a serverless application. However, they alone cannot bring an application alive—many other factors are involved. Figure 1-13 depicts some of the core elements that make up the serverless ecosystem.
Figure 1-13. Parts of the serverless technology ecosystem
They include:
The cloud platform
This is the enabler of the serverless ecosystem—AWS in our case. The cloud host‐ ing environment provides the required compute, storage, and network resources.
Managed cloud services
Managed services are the basic building blocks of serverless. You compose your applications by consuming services for computation, event transportation, mes‐ saging, data storage, and various other activities.
Architecture
This is the blueprint that depicts the purpose and behavior of your serverless application. Defining and agreeing on an architecture is one of the most impor‐ tant activities in serverless development.
Infrastructure definition
Infrastructure definition—also known as infrastructure as code (IaC) and expressed as a descriptive script—is like the circuit diagram of your application. It weaves everything together with the appropriate characteristics, dependencies, permissions, and access controls. IaC, when actioned on the cloud, holds the power to bring your serverless application alive or tear it down.
Development and test tools
The runtime environment of your FaaS dictates the programming language, libraries, plug-ins, testing frameworks, and several other developer aids. These tools may vary from one ecosystem to another, depending on the product domain and the preferences of the engineering teams.
Repository and pipelines
The repository is a versioned store for all your artifacts, and the pipelines per‐ form the actions that take your serverless application from a developer environ‐ ment all the way to its target customers, passing through various checkpoints along the way. The infrastructure definition plays a pivotal role in this process.
Observability tools
Observability tools and techniques act as a mirror to reflect the operational state of your application, offering deeper insights into how it performs against its intended purpose. A non-observable system cannot be sustained.
Best practices
To safeguard your serverless application against security threats and scaling demands and ensure it is both observable and resilient in the face of unexpected disruptions, you need well-architected principles and best practices acting as guardrails. The AWS Well-Architected Framework is an essential best practices guide; we’ll look at it later in this chapter.
Builders and stakeholders
The people who come up with the requirements for an application and the ones who design, build, and operate it in the cloud are also part of the ecosystem. In addition to all the tools and techniques, the role of humans in a serverless ecosystem is vital—they’re the ones responsible for making the right decisions and performing the necessary actions, similar to the role we all play in our environmental ecosystem!