The Aptilo SMP is built for stability, scalability and high availability with geographical redundancy.
The application logic is separate from the communication. Scale where capacity is most needed.
Taking the scalability issue out of the equation
When it comes to performance, we can only be sure of one thing. No matter if we use RISC-based, standard Intel®-based or proprietary servers, the top performance of today will be considered a mediocre performance tomorrow. We can also be sure of that the price for server hardware will go down at the same rapid pace as the speed goes up.
The only way to be sure to take the scalability issue out of the equation is to get a linear scalability when adding more servers. With the fast development of server hardware, it is important to go with a server platform that can offer the best price-performance-ratio.
We achieve carrier-class scalability by distributing our system over different layers running in several standard Intel®-based servers. This provide the most cost-effective server platform for delivering additional performance by just adding another server.
The Intel®- architecture offers economy of scale thanks to its pure volume in number of units. This means you will not risk doing large investments in individual high performance servers, that may not fit the purpose at the end. True linear scalability can only be achieved with 100% flexibility in both hardware and software.
The Aptilo SMP ALE architecture
In the Aptilo Long-term Evolution (ALE) architecture, the functionality is divided into three distinct layers:
- A management layer for configuration and monitoring
- A control layer for protocol-level interactions with external systems
- An execution layer for application logic processing.
The different layers are distributed over several server nodes to increase capacity where it is needed most and obtain high availability including geographic redundancy and distribution.
We scale from two redundant server pairs, all the way up to a large linearly scalable server cluster by just adding more server nodes.
ALE application control layer
The control layer runs a number of protocol adapters that facilitate interoperability with the required set of external systems. These protocol adapters include RADIUS, Diameter, REST, SOAP/XML, LDAP and SNMP. New adapters are introduced as needed to implement new or modified relationships with external systems. This layer do not need to have redundant servers as it is state-less and can be replaced by any other server with the control layer running.
ALE application execution layer
All application logic is performed in this layer. It holds state and thus need to be on redundant server pairs. We have learned the hard way that no matter how much features we add there will always be one more needed. Every customer have different legacy aspects that we need to take into account when designing the solution. We have designed the ALE architecture based on the simple truth that there will always be new requirements and that neither our customers nor we have the time to wait for the next release. Thus new logic needs to be added as configuration, learn more about how we have solved this through the Aptilo ServiceGlue™ functionality. The application execution layer architecture allows us to run several different types of applications such as EAP-SIM authentication and Policy Management from the same scalable platform.
ALE application management layer
The configuration and monitoring is handled by the application management layer and it is tightly integrated with a management plane which spans over all layers. With this design we can assure that we add capacity where it is most needed. For signaling intensive applications it might be the control layer that needs most power while in applications with extensive business logic it might be the execution layer.