Serverless Computing and a Case Study in Retail
Serverless Computing and a Case Study in Retail
Check this out to learn more about the hype of serverless and see how it can be applied in a use case based on e-Commerce.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Serverless is an architectural style to build applications as event-driven ephemeral functions with no need to provision, configure or manage server/infrastructure/platform to run and scale. Serverless functions get instantiated only when there is an event until it gets processed, and therefore they can scale as per the dynamic workload in the most economic manner without any planning/configuration required on your part.
Advantages of Going Serverless
- Lower TCO — The cloud provider manages the infrastructure, platform, maintenance, and scalability. You are only charged for the time your function is running.
- Faster Time To Market — Since you can focus entirely on the business logic without worrying about the operational overhead, serverless enables you to quickly run experiments in production.
- Scalability and Availability — It is all managed by the provider, although there are limits placed on the account which requires additional considerations. No configuration or setup is required for scaling.
- Handling Random Short Spikes — With auto-scaling of VMs/containers, there is usually a longer warm-up time which does not help in case you are seeing random short spikes. With serverless being lightweight, a spike is not much different from a regular trigger and it is much economical to scale.
Common Use Cases for Serverless Applications
For serverless functions, there are strict limits imposed by the providers on resource, time, rate and scalability such as available memory, deployable package size, duration of execution, concurrent executions, etc. Language choices are also limited at this moment. Each provider supports a choice of event sources to trigger the function.
Considering these limitations, your serverless functions need to be lightweight, quick, and event-driven. Invocation pattern is usually infrequent or in bursts (such as campaign, product launch or promotion), not consistently spread. Some common use cases are image and other static content processing, lightweight ETL, stream processing, notification, queue processing, log processing, cron jobs, lightweight APIs, conversational logic, and IoT event processing.
In certain scenarios, serverless is not the ideal solution and there are better alternatives.
- Long-running processes — If it cannot be broken down to smaller and lighter tasks that can be completed individually within the time limit for serverless functions, then it is better to use different approaches such as Docker containers.
- Stateful applications — Serverless by definition, is stateless. For managing transient state in serverless microservices/tasks you would have to use an external service (such as message queue for coordination or workflow for orchestration).
- Predictable consistent traffic — With properly utilized infrastructure it might be more economical and simple to use regular instances/containers.
This being a relatively new technology, you need to be prepared to face a few other challenges.
- A cold start will happen for the first time as well as after a period of inactivity causing the execution to take longer, even more with launching runtimes like Java.
- Attaching network interfaces can increase startup time as well as constrain scalability by exhausting the available number of interfaces and IP addresses.
- In a hybrid architecture, downstream applications may not be able to scale in proportion to upstream serverless functions.
- Often serverless architectures are comprised of other services from the same vendor (API Gateway, DB, Storage, Message Queue etc.). Integrating your serverless code with other vendor services might cause a vendor lock-in.
- Additional consideration is required in design/build of the application through refactoring the code and keeping it lightweight and efficient as per the limitations imposed by the provider, while maintaining the cost advantage.
- At this point in time, there is not much support available for local debugging, tooling. The technology is still evolving and has room for improvement. For instance, in AWS, if a function call fails due to insufficient ENI/IP address, it is not logged to Cloudwatch logs and can only be found out by manually invoking the function through console.
Platform Choices for Serverless
Cloud vendors: Language choices are limited amongst cloud providers (Node.js is the preferred language due to shorter startup time). Typical supported triggers for serverless functions are message streams, DB streams, blob storage events, message queue, pub/sub, CI/CD events, HTTP API calls, log events etc.
Vendor agnostic choices:
- kubeless, openfaas, fission, fn.
KNative is aimed towards standardizing serverless for kubernetes based platforms. It extends Kubernetes and Istio for build (code to container), eventing and deployment/serving serverless functions.
Serverless for Retail
Serverless has wide applicability in retail. But the adoption must be incremental and well thought through. Ideally, the first few use cases should be smaller and simpler processing, before aiming to target complex functions (such as with workflows and state management). Event-driven and pipeline-based architecture also lends itself well to the decoupling of processing and makes it easier to implement Serverless functions.
Some of the potential retail applications which can benefit from serverless are:
- Real-time Pricing
- Global inventory view
- Sales Transaction Audit
- CRM — Marketing campaign notifications
- PIM — Product Content Enrichment and push
Here is an eCommerce use-case for serverless in building a global inventory view. However, this approach could well be applied to various middle and back-office functions.
A majority of retailers have store applications running on the store infrastructure which periodically gets synced up with the centralized ERP systems. One of the requirements for having an omnichannel fulfillment capability is to have a global inventory view which is as real-time as possible. The view needs to be highly available and scalable. Using event streaming, cloud, and serverless functions, here is a possible simplified implementation to build a near real-time inventory view. Inventory is designed to be a microservice (bounded context) outside order management.
Journey Ahead with Serverless
With its cost advantage and quick scalability features, serverless could be the future standard of building solutions (serverless first). Retail has a plethora of use cases which can benefit from this approach. As the offerings, ecosystem, and frameworks mature in time, some of the concerns in larger adoption would get addressed. Meanwhile, we should apply it to the right use cases and follow best practices in design and operations to make the transition effortless.
Opinions expressed by DZone contributors are their own.