Huawei Cloud Sub-account Management Huawei Cloud serverless computing guide

So you’ve decided to venture into serverless computing on Huawei Cloud. Congratulations! You’re about to trade “snowflake servers lovingly crafted by hand” for a model where your code runs when it needs to, and you pay for that specific moment of glory. It’s like having a helpful but slightly mysterious roommate who shows up only when the fridge is empty.

This guide is designed to be readable, structured, and actually useful. We’ll walk through what serverless is, how to think about architecture, what Huawei Cloud services typically fit into the puzzle, and how to deploy, observe, and secure your workloads. Along the way, we’ll include realistic “what could go wrong” moments, because software without a few hiccups is just a bedtime story.

What “Serverless” Really Means (Spoiler: It’s Not Magic)

Serverless computing doesn’t mean servers vanish. It means you don’t have to manage them. The cloud provider handles the infrastructure layer—provisioning, scaling, patching, and the general “please don’t make me log into prod at 3 a.m.” work.

In practice, serverless usually means running code in stateless functions triggered by events. Think: HTTP requests, database changes, message queues, file uploads, scheduled timers, and other “something happened” signals. Your code runs, processes the event, returns a result, and then disappears into the cloud void until the next event arrives. No long-running servers to babysit. No fixed capacity planning. Just the right amount of compute at the right time—like ordering a single cookie instead of buying an entire bakery.

Now, before you get too excited, serverless isn’t a universal replacement for everything. Some workloads need predictable long-running connections, extremely specialized networking, or strict performance characteristics that require deeper tuning. Serverless can still be the right choice—it just needs the right expectations.

Why Choose Huawei Cloud for Serverless?

Huawei Cloud offers a serverless ecosystem that can support common patterns: function execution, API exposure, integration with other cloud services, and operational capabilities like logging and monitoring. It’s not just “one button does everything.” It’s more like a toolbox: you select the tools that match your problem rather than welding everything into one giant machine.

For developers, the key promise is speed. You can build event-driven applications without building an entire platform from scratch. For operations teams, the promise is reduced routine work: less infrastructure maintenance, more focus on application logic and reliability.

For everyone else, the promise is fewer dashboards that look like they were designed by a committee of owls in a cave. (You’ll still have dashboards, but at least you’ll know what they mean.)

Core Components You’ll Commonly Use

Huawei Cloud serverless solutions typically revolve around the following conceptual blocks. Exact service names can vary based on your region and the offerings available, but the patterns are consistent across serverless platforms.

1) Functions as the Execution Unit

The heart of serverless is the function. You package code, define runtime settings (like language, memory, timeouts), and attach triggers. When events occur, the platform runs your function.

Functions are usually stateless. If you need state, store it externally (databases, object storage, caches). Your code can still be “stateful in spirit,” but it must store the truth somewhere persistent.

Huawei Cloud Sub-account Management 2) Triggers: How Code Gets Invoked

Triggers are what make your code run. Common trigger types include:

• HTTP calls (webhooks, API endpoints)
• Object storage events (file created/updated)
• Message queue events (new messages)
• Database events (changes or streams)
• Scheduled events (cron-like schedules)

Pick triggers that match how your business processes actually behave. If your system cares when a file lands in storage, don’t poll every 10 minutes “just in case.” Polling is how you summon wasted costs and mystery bugs.

3) API Layer for HTTP Use Cases

If you want clients to call your function over HTTP, you usually place an API gateway or API management layer in front. That layer can handle routing, authentication, request validation, and throttling—like a bouncer at a club that checks IDs for your API.

4) Integration with Datastores and Storage

Most serverless apps need some place to store data. Object storage is great for files. Databases (relational or NoSQL) handle structured or semi-structured data. Caches can help with performance. The function reads, writes, and returns results.

In serverless, network latency matters. That means your architecture should minimize unnecessary round-trips. If your function calls five services to render one response, you might spend more time waiting for other services than doing actual work.

5) Observability: Logs and Metrics

Serverless means you’re less aware of underlying servers. So you rely on logs, metrics, and tracing. You want to know:

• Did the function start?
• Did it succeed or fail?
• How long did it take?
• Which events triggered it?
• What errors occurred?

If you don’t observe your functions, you’re essentially building an app and hoping your future self can interpret the smoke signals. Spoiler: smoke is not a great debugging format.

When Serverless Is a Great Fit (and When It’s Not)

Let’s discuss the “should I use it?” question. Serverless tends to shine when:

• Your workload is event-driven (requests, uploads, queue messages).
• You have variable or unpredictable traffic.
• You want faster iteration without maintaining infrastructure.
• You can make functions stateless and externalize state.
• You can design for scaling and concurrency.

Serverless can be less ideal when:

• You need long-running processes with persistent connections.
• You have extremely specialized hardware/network requirements.
• Your performance requirements demand constant low latency without cold start impact (though mitigations exist).
• You want tight control over operating system-level tuning.

But even “not ideal” situations can still work with careful architecture. It’s all about tradeoffs, and tradeoffs are the adult version of “choosing what to sacrifice.”

Designing Your Serverless Architecture

Architecture is where the fun begins. Not fun like “roller coaster,” more like “puzzle box that quietly judges you.” Here’s a solid way to structure your planning.

Start with Use Cases and Event Flow

Write down your primary user journeys and backend workflows. Then identify:

• What triggers each step?
• What data is needed?
• Where does the state live?
• What are the success and failure outcomes?

For example, if you’re building a file processing pipeline:

• A file upload event triggers Function A.
• Function A stores metadata and sends a message to a queue.
• Function B consumes the message and processes content.
• Function C updates a status record in a database.

This is more than a diagram. It’s a contract between your components.

Think About Idempotency (Yes, It Again)

Serverless systems can deliver events more than once, especially in the presence of retries and failures. So your functions should ideally be idempotent: processing the same event multiple times shouldn’t corrupt data or create duplicates.

Practical techniques include:

• Use unique identifiers for events.
• Store processing status keyed by event ID.
• Use conditional writes in databases.

Idempotency is the seatbelt of serverless. You might not think you need it until the moment you really do.

Choose Function Granularity Wisely

Should you have one function that does everything, or multiple specialized functions?

• One big function: fewer moving parts, but harder to maintain and test. Changes can be riskier.
• Many small functions: better separation of concerns, more reusable pieces, and easier scaling per task. But you manage more components.

A good approach is to break functions by responsibility: “parse,” “validate,” “transform,” “persist,” “notify.” Keep them small enough to understand, but not so tiny that your codebase becomes a swarm of gnats.

Manage Cold Starts and Performance Expectations

Cold starts happen when a function instance isn’t already ready to handle requests. Some platforms optimize this with warm pools or reuse. You can also mitigate by:

• Keeping deployment packages small.
• Initializing heavy dependencies outside of request handlers when possible.
• Choosing appropriate memory settings (often affects CPU allocation too).
• Designing your API to be resilient (timeouts, retries, and caching where relevant).

Be realistic: serverless cold starts aren’t zero, but you can often design for acceptable user experience.

Step-by-Step: Setting Up a Basic Serverless Project

The exact steps depend on your environment, tooling, and the services you pick. But here’s a practical workflow you can follow.

Step 1: Prepare Your Local Tooling

Choose your development language and runtime version supported by Huawei Cloud. Install the relevant SDKs, create a project directory, and set up your build and dependency management.

Keep your function code focused. If you’re building something like an HTTP-triggered function, make your handler do only:

• Input validation
• Business logic
• Calling external services (with timeouts)
• Returning a response

Don’t turn it into a monolithic application that accidentally includes the entire internet’s worth of dependencies.

Step 2: Create the Function

In the Huawei Cloud console (or via API/CLI, if you prefer speed and fewer clicks), create a function resource. Configure:

• Runtime and version
• Handler entry point
• Memory size
• Timeout
• Environment variables (secrets via the appropriate secure mechanism)

Pay attention to timeout. A timeout that’s too short can cause failures in normal operation; one that’s too long can delay feedback and tie up resources. Think “just long enough to do the job, not long enough to contemplate your life choices.”

Step 3: Attach a Trigger

For an HTTP example, you typically configure an API gateway route that invokes your function. For event-driven examples, you attach a trigger like:

• Object storage event for file uploads
• Queue event for messages
• Huawei Cloud Sub-account Management Scheduled trigger for periodic tasks

When configuring triggers, define what happens if the function fails. Some architectures use dead-letter queues or retry policies. Make failure handling part of your design, not an afterthought you add when things break.

Step 4: Configure Permissions (IAM) Early

Serverless is strongly tied to identity and access management. Your function runs under an execution role. That role must have permissions to:

• Read or write to required services (storage, databases, queues)
• Publish logs/metrics
• Call other APIs securely

If permissions are missing, you’ll see errors. Better to diagnose them once, calmly, during setup, than repeatedly during a demo when everyone’s pretending not to panic.

Step 5: Test with Representative Events

Test your function with inputs that represent real usage. If you’re processing files, test small and large files. If you’re handling HTTP requests, test edge cases like missing fields, invalid formats, and weirdly large payloads.

Also test failure paths. Return meaningful error messages (without leaking secrets). Use structured logging so you can find issues quickly.

Deploying and Managing Versions

Deployment is where “works on my machine” goes to retire. A good serverless workflow includes:

• Huawei Cloud Sub-account Management Versioning your function code
• Using staged environments (dev, staging, production)
• Automating deployments so you don’t rely on human memory

Try to implement a simple release strategy. For example:

• Deploy new code to staging
• Run automated tests and load checks
• Huawei Cloud Sub-account Management Promote to production

Some platforms support aliases or traffic shifting. If you have that option, it can help you control rollouts and rollback quickly when the universe disagrees with your assumptions.

Security Basics You Should Not Ignore

Security in serverless is mostly about:

• Least-privilege IAM permissions
• Secure handling of secrets
• Protecting APIs and data flows
• Validation and safe coding practices

Use Least Privilege

Grant only the permissions the function truly needs. If a function only reads from a bucket, don’t allow it to delete objects. If it only publishes messages, don’t allow it to browse your entire kingdom of data.

Store Secrets Securely

Don’t hardcode credentials in your function code. Use a secrets manager or secure parameter store if available. Set environment variables carefully and avoid logging secrets.

Validate Inputs

Regardless of trigger type, validate input. HTTP requests should have schema validation. Message payloads should be checked for required fields. File processing should check file size, type, and content format.

If you don’t validate input, your serverless function becomes a vending machine that accepts random garbage and turns it into expensive errors.

Use Authentication for Public Endpoints

If you expose HTTP endpoints, use appropriate authentication and authorization. API gateways often support token validation, API keys, or other mechanisms. Don’t make endpoints public “temporarily.” Temporary is how security gets retired early.

Monitoring, Logging, and Tracing (Your Survival Kit)

In serverless, debugging means following the trail: logs, metrics, and traces. The earlier you set this up, the less time you’ll spend staring at red error counts like they’re trying to confess something.

Log What Matters (and Not Everything)

Good logs include:

• Request ID or correlation ID
• Function name and version
• Trigger details (within reason)
• Key steps in your workflow
• Error details and stack traces for failures

Huawei Cloud Sub-account Management Be cautious about logging personal data or secrets. Also avoid logging huge payloads. Your logs are for humans, not for storage-bill nightmares.

Use Metrics to Track Health

Metrics can include invocation counts, error rates, duration, throttling, and concurrency. Set alarms for:

• Sudden spikes in errors
• Increases in latency
• Excessive throttling
• Unexpected invocation volume (possible abuse or misconfigured triggers)

Correlate Traces for Multi-Step Workflows

When your architecture spans multiple functions, tracing becomes invaluable. If function A triggers function B, you want to see the chain. Correlation IDs make this possible.

Without correlation, you get a “where did this request go” scavenger hunt. With correlation, you get answers.

Cost Awareness: Serverless Can Be Cheap… or Surprisingly Expensive

Serverless pricing is usually based on compute usage (time and memory), number of invocations, and additional services. Cost control is not optional if you like your budget to remain a human-sized number.

Understand What Drives Cost

Huawei Cloud Sub-account Management Common cost drivers:

• Number of invocations
• Execution duration per invocation
• Allocated memory (often correlates with resources)
• Background retries due to failures
• Huawei Cloud Sub-account Management Data transfer and calls to other services

A function that times out and retries repeatedly can become a tiny budget vampire. If your code fails often, the retry behavior might multiply your spend.

Optimize Execution Time

Make your functions efficient:

• Minimize cold start overhead
• Use reasonable timeouts for external calls
• Avoid unnecessary loops and large data transformations

Set Concurrency and Backpressure Strategy

If you process queue messages, design for backpressure. If your function scales too fast, you might overload downstream services. If it scales too slowly, your queue grows and latency increases. The sweet spot is the one where you don’t get paged.

Troubleshooting: Common Problems and What to Do

Let’s talk about real-world issues. Serverless is great, but it has a personality. Here are some common “why is this failing” scenarios and how to approach them.

Problem: Function Invokes but Errors Immediately

Likely causes:

• Permission issues (IAM role missing access)
• Missing environment variables
• Runtime or dependency problems

What to do:

• Check logs for stack traces
• Confirm environment variables exist in the correct environment
• Verify the execution role has the required permissions

Problem: Timeouts

Likely causes:

• External APIs are slow or have no timeouts
• Large payload processing in a single invocation
• Huawei Cloud Sub-account Management Cold start plus heavy initialization

What to do:

• Add timeouts to network calls
• Split work across multiple functions or steps
• Optimize initialization and reduce package size

Problem: Duplicate Processing

Likely causes:

• Retries after failures
• Huawei Cloud Sub-account Management At-least-once delivery semantics from triggers

What to do:

• Implement idempotency using event IDs
• Use conditional updates in the database

Problem: You See No Logs and It Feels Like the Function Is Ghosting You

Likely causes:

• Logging not enabled or misconfigured
• Your function fails before log statements run
• Log level too restrictive

What to do:

• Add a minimal early log statement
• Verify log sink configuration
• Check if the function is triggered at all by verifying invocations

A Practical Example: Build a Tiny Event-Driven Workflow

Let’s create a hypothetical scenario: you receive uploaded files in object storage, and you want to extract metadata, then notify another system. We’ll break it into functions so each does one job.

Workflow Overview

• Event: A new file is uploaded to storage.
• Function A: Validate the file, compute basic metadata, and write a record to a database.
• Function B: Read metadata, then notify an external endpoint (or publish a message).

Function A Responsibilities

• Read event payload to get file location
• Fetch file (or only read headers if possible)
• Validate file type and size
• Compute metadata (filename, size, checksum, maybe content type)
• Write record to database with a status field
• Optionally enqueue a message for Function B

Function A should be idempotent. If the same upload event is delivered twice, writing the same metadata record should not create duplicates. Use a unique key like object path or event ID.

Function B Responsibilities

• Receive the message (or query for pending records)
• Read the record from the database
• Notify external service with metadata
• Update status to completed (or failed)
• Handle retries safely

Function B should treat external calls carefully: use timeouts, retries with backoff, and record failures so you can analyze issues later.

Observability for This Example

Give each function structured logs. Include:

• The object key
• The correlation/event ID
• Metadata fields (not the file itself)
• Error codes and stack traces on failures

Then you’ll be able to answer questions like:

• Did Function A run?
• Did it validate successfully?
• Did Function B notify the external system?

Without observability, you’ll answer those questions by refreshing random dashboards and making confident guesses. We prefer actual facts.

Best Practices Checklist (The “Do This, Not That” List)

• Design functions to be stateless and store state externally.
• Plan for retries and implement idempotency.
• Keep function packages small to reduce cold starts.
• Set appropriate timeouts for your function and downstream calls.
• Use least-privilege IAM permissions.
• Validate inputs and handle edge cases.
• Log responsibly and include correlation IDs.
• Set alarms for error rates, latency, and throttling.
• Monitor cost drivers like invocation volume and retries.
• Automate deployment and keep versioned releases.

Common Misconceptions (So You Don’t Get Tricked by Your Own Hype)

Misconception 1: “Serverless means zero operational work”

Operational work becomes different, not zero. You still manage monitoring, error handling, and deployment strategies. The difference is you spend less time patching servers and more time building robust systems.

Huawei Cloud Sub-account Management Misconception 2: “If it worked once, it will always work”

Serverless systems can experience concurrency, retries, and event duplicates. Build for those realities from the start.

Misconception 3: “Scaling is automatic, so performance problems don’t matter”

Scaling helps when you’re CPU-bound. But if your function waits on slow external services, scaling might just increase the number of slow waits. Use timeouts, caching, and efficient queries.

Conclusion: Your Next Step

Huawei Cloud serverless computing can be a fantastic way to build event-driven applications with less infrastructure management. The trick is to treat it like a real architecture problem, not a magic trick. Plan your event flow, design stateless functions, implement idempotency, secure your permissions, and invest early in monitoring and logs. Then you can iterate quickly and confidently.

If you’re ready for your next step, start small: build a single HTTP-triggered function or a storage-event pipeline. Add logging, set timeouts, and test with real-like inputs. Once that works, expand into more functions and triggers. Serverless is not “one and done.” It’s a journey where your code learns to dance with events.

Huawei Cloud Sub-account Management And remember: when something breaks, don’t blame the cloud first. Blame the missing environment variable first. Then blame your assumptions. The cloud will be waiting politely, ready to take the blame you don’t deserve.