.jpg?alt=media&token=1583c953-c8a5-4e62-84c2-7ce08e5951b1)
Overview
This section describes Memphis Functions - Serverless stream processing
Organizations shift to process events and logs on the fly before they reach the data warehouse and adopt an event-driven type of architecture, but the environment and data are constantly changing - development teams are struggling to keep pace, and also development should be done with much less effort and much more agility.
- 1.Hard to develop new stream processing flows.
- 2.Highly coupled code to a specific flow or type of events.
- 3.No code reuse or share.
- 4.Debug, troubleshoot, and fix.
- 5.Code evolvement.
- It is forcing devs to use SQL or other dedicated vendor-locking languages.
- Do not support custom logic.
- Increase infrastructure complexity at scale.
- Do not enable code reuse or share.
- It still takes a significant amount of time to build a real-time app/pipeline.
Memphis platform comprises four decoupled components:
- 1.Memphis Broker as the engine and storage layer.
- 2.Schemaverse for schema management and enforcement.
- 3.Memphis Functions for serverless stream processing.
- 4.Memphis Connect for pulling and pushing data using ready-to-use connectors.
Memphis functions enable data analysts, developers, and data engineers to collaborate and process, transform, and enrich ingested events “on the fly” in a serverless, low-code/no-code manner, meaning without boilerplate or infrastructure in any supported language, including Go, Python, JS, .NET, Java, SQL, and more.
Last modified 1mo ago