• Level Up Coding
  • Posts
  • LUC #41: Serverless Architecture Demystified: Strategies for Success and Pitfalls to Avoid

LUC #41: Serverless Architecture Demystified: Strategies for Success and Pitfalls to Avoid

Plus, what is gRPC and when should you use it, how SQL injections work and how to protect your system from them, and SemVer explained in very simple terms

This week’s issue brings you:


A big thank you to our partner Postman who keeps this newsletter free to the reader.

You can now simulate real-world traffic on your local machine to performance test your APIs via Postman. Check it out.

Serverless Architecture Demystified: Strategies for Success and Pitfalls to Avoid

November 2014.

That’s when Amazon announced AWS Lambda at AWS re:Invent.

The concept of serverless computing was beginning to gain prominence, and AWS Lambda took it into the mainstream.

For the past decade, we’ve been privileged to have server management abstracted away from us. And there are now several options for how much abstraction we want.

But it’s only been this way in recent times.

Prior to ~2014, before the advent of container orchestration services and serverless computing, server management involved a much more manual and complex process.

Serverless architectures have significantly transformed cloud computing.

Today will be looking into serverless architecture, best practices, pitfalls to avoid, and when and where it works best.

Let’s jump in!

The Essence of Serverless Computing

Serverless computing abstracts server management tasks from the development team’s workload.

Instead, it relies on Functions-as-a-Service (FaaS) to handle event-triggered code execution.

With this setup, cloud providers can allocate resources dynamically and only charge for the actual compute time used instead of reserved capacity.

Serverless architectures can support a wide range of applications, from simple CRUD operations to complex, event-driven data processing workflows.

It fosters a focus on code and functionality, streamlining the deployment of applications that can automatically adapt to fluctuating workloads.

Key Practices

To completely take advantage of serverless architectures, here are some best practices:

Design for failure

Ensuring your application can effectively handle failures is essential in a serverless setup.

Strategies like retry mechanisms and circuit breakers can help maintain reliability and availability.

Optimize for performance

Serverless performance optimization has two goals: reduce cold start latency and maximize resource utilization.

Lightweight functions, programming language selection, and aligning memory and computing resources with function requirements can all help to reduce startup times and costs.

Security considerations

A proactive approach to security is a must.

To protect your serverless applications, implement the least privilege principle, secure your API gateways, and encrypt data.

Cost management

Despite being cost-effective, improper utilization can result in increased costs.

Monitor usage patterns and adjust resource allocations to keep the expenses under control.

Navigating Pitfalls

While the above practices yield results, there are also common pitfalls to be mindful of:

Ignoring cold start latency

The user experience can be significantly impacted by cold starts.

Reduce them by using warm-up techniques and optimizing your code.

Overlooking security in a shared environment

Avoid being taken in by the convenience of serverless computing and allowing complacency to creep in.

Inadequate function permissions and neglecting data encryption are common oversights.

Ensure that robust security measures are in place.

Complexity in managing multiple services

The granular nature of serverless can result in architectural complexity, particularly when integrating multiple services and functions.

Adopting Infrastructure as Code (IaC) and serverless frameworks streamline management.

Limited control and vendor lock-in

Dependence on a single cloud provider can limit your control and flexibility.

Serverless solutions should be evaluated for flexibility and portability to ensure they align with long-term architectural goals.

When and Where Going Serverless Makes Sense

Serverless excels with event-driven applications due to its reactive execution model.

For microservices, it enables independent scaling and deployment.

It also works well for projects with fluctuating traffic through automatic, efficient scaling.

It's ideal for rapid development, allowing focus on coding over infrastructure management.

And the pay-as-you-go model also can be well-suited for cost-sensitive projects.

However, serverless architecture generally doesn’t fit well with long-running tasks due to execution time limits.

Applications requiring low latency can suffer because of potential cold start delays.

And cases needing precise environmental control may not be a great fit as it offers limited infrastructure customization.

Assess your project's specific needs; performance, costs, scalability, and so on, to determine if serverless aligns with the project goals.

Wrapping Up

Serverless architectures have simplified server management. It has enabled developers to focus more on code and functionality rather than managing infrastructure.

Despite its benefits, navigating serverless computing requires an understanding of its complexities and limitations.

By adhering to best practices and being mindful of potential pitfalls, developers can leverage serverless technologies to build scalable, cost-efficient, and resilient applications.

What Is gRPC and When Should You Use It? (Recap)

gRPC is a powerful remote procedure call (RPC) framework developed by Google, enabling efficient and fast communication between services. It is built on HTTP/2 and Protocol Buffers. This is where a lot of the benefits of gRPC are derived from;

  • Harnessing Protocol Buffers (Protbufs) as its interface definition language (IDL) helps alleviate tech stack lock-in. Each service can be written in any popular programming language, the IDL works across them all.

  • The compact binary format of Protobufs provides faster serialization/deserialization, and a smaller payload than JSON. Less data sent means better performance.

  • Since Protobufs are strongly typed, they provide type safety, which can eliminate many potential bugs.

  • Utilizing HTTP/2 suppers bidirectional streaming and reduced latency for real-time data transmission.

  • The combination of HTTP/2 and Protobufs provides maximum throughput and minimal latency. It's often faster than the traditional JSON over HTTP approach.

The easy implementation and benefits above have made gRPC very popular for microservices communication.

SemVer Explained in Very Simple Terms (Recap)

Semantic versioning is a standardized way to communicate software upgrades.

It categorizes changes into three buckets:

🔴 Major: Contains breaking changes that require users to upgrade their code or integration.

🟢 Minor: Changes are backward-compatible. Typically extends functionality or improves performance.

🟣 Patch: Contains bug fixes that don’t change existing functionality.

Pro tip: A simplified framework for thinking about SemVer is “Breaking.Feature.Fix”.

SemVer provides an easy and clear way to communicate changes in software, which helps manage dependencies, plan releases, and troubleshoot problems.

How SQL Injections Work and How To Protect Your System From Them (Recap)

SQL injection is a type of attack where the attacker runs damaging SQL commands by inserting malicious SQL code into an application input field or URL.

You can protect your system from SQL injections by doing the following:

1) Use prepared statements or parameterized queries
User input cannot be executed because prepared statements and parameterized queries ensure a distinct separation between user input and SQL code.

2) Validate and clean inputs
Use expected formats and constraints to validate user input, and clean inputs to get rid of characters that may be interpreted as SQL code.

3) Follow the least privilege principle
Limit the permissions for database accounts used by applications and services to only what is required for their functionality.

4) Set Web Application Firewalls (WAF)
By setting up WAFs, common threats and attacks from HTTP/S traffic like SQL injections can be identified and blocked before they ever reach your application.

That wraps up this week’s issue of Level Up Coding’s newsletter!

Join us again next week where we’ll explore edge computing vs cloud computing, how DNS lookup works, and how SQL execution order works and why it’s so important.