Evaluation and Development with AMPS

Evaluation and Development with AMPS

AMPS runs on any 64-bit Linux system. For best performance in a development environment, 60East recommends that the system have a minimum of 4GB of memory available.

For basic functional evaluation and development, AMPS runs well in a virtual machine, in a container, or in a WSL2 shell on Windows, as well as on a Linux host.

The Introduction to AMPS includes information on how to set up a basic development environment for AMPS.

Product Overview

AMPS is designed to help you quickly and easily develop and deploy data-intensive applications with demanding requirements for low latency and high performance. AMPS takes a nontraditional approach to messaging, storage, and analytics that is designed from the ground up for streaming data and highly-parallelized multicore systems.

AMPS is based on an incredibly fast messaging engine that supports multiple messaging paradigms, as well as providing persistent current value caching (effectively, an integrated database), content filtering and continuous query, historical replay, aggregation and analytics, message enrichment, focus tracking, partial updates and change tracking, and more.

Furthermore, AMPS is designed and engineered specifically for next generation computing environments. The architecture, design and implementation of AMPS allows the exploitation of parallelism inherent in emerging multi-socket, multi-core commodity systems and the low-latency, high-bandwidth of 10Gb Ethernet and faster networks. AMPS is designed to detect and take advantage of the capabilities of the hardware of the system on which it runs.

AMPS was designed to improve performance and reduce latency in real-world messaging deployments by focusing on the entire lifetime of a message from the message's origin to the time at which a subscriber takes action on the message. AMPS considers the full message lifetime, rather than just the "in flight" time, and allows you to optimize your applications to conserve network bandwidth and subscriber CPU utilization -- typically the first elements of a system to reach the saturation point in real messaging systems.

Understanding AMPS Features and Scenarios

For an overview of the features of AMPS, see the Overview of AMPS in the Introduction to AMPS.

To understand which features are most commonly used for a given scenario or application pattern, see the Scenario and Feature Reference. This provides a quick guide to help you focus on learning the features that are most relevant to the problem at hand.

For example, to distribute work across a set of independent processors, you would use AMPS message queues, whereas if your application requires a content-aware last value cache, you would use a Topic in the AMPS State of the World.

Evaluation Process Outline

60East provides access to technical support during the evaluation process.

To prepare to evaluate AMPS, 60East recommends the following process:

• Engage 60East support with a description of the evaluation goals, and to put in place any agreements necessary to make evaluation go more smoothly (such as mutual non-disclosure agreements).

• Define the detailed goals of the feasibility phase of the evaluation. Typically, these break down into:

  • Functional Capability - This represents what the evaluation project needs to be able to do. (For example: accurately receive NFVIX messages and deliver them to the appropriate subscriber or subscribers while maintaining the ability to replay 30 days of history at any point.)

  • Performance Goals - This represents the service level for the evaluation. (For example: Maximum latency to reach client processing of 250ms for current messages, no more than 1s to first message for beginning a replay at an arbitrary depth in history.)

  • Capacity Goals - This represents the total volume of work being evaluated. (For example: The system needs to reach capability and performance goals while processing 10,000 messages per second ingestion.)

• Develop initial design and testing plan. During this process, teams use the AMPS documentation to understand how to use AMPS to meet the goals of the evaluation. Teams engage 60East support as necessary to resolve any questions that emerge or get advice on tradeoffs and options to achieve the evaluation goals.

• Once a design and testing plan is complete, review the design and testing plan with the 60East engineering team, adjusting as necessary.

• Implement the design and tests. If questions or issues emerge, consult with 60East support to resolve the issues.

• Test and review the results with 60East.

• Evaluate the deployment and maintenance phase of the evaluation. Typically, this involves:

  • Operations and Performance at Scale - Evaluate the application in a production-like environment at scales at or near production volumes.

  • Maintenance Goals - Develop and test the maintenance, support, and upgrade plan as described in the 60East deployment checklist.

• Follow up on any open issues and complete the evaluation.