CCF4XAP has been designed to exploit XAP capabilities on the cloud and leverage XAP's scalability, low latency and high-throughput in this dynamic environment. The main focus is on ease of use, allowing users to deploy their application on the cloud without special application configuration.
Automated Application Deployment
In a cloud-based environment, where virtual machines are allocated on the fly, automated application deployment is essential. CCF4XAP supports the following:
Built-In Support for Core Enterprise Application Components
HTTP load balancer – A dedicated machine is started running an HTTP load balancer. The HTTP load balancer is configured in runtime to rout all incoming HTTP requests to all running web servers. Once a new web server is deployed, the HTTP load balancer configuration is modified to rout incoming requests into the newly started web servers.
Clustered web containers – web servers are deployed within a XAP SLA container. Web servers deployed to the cloud run in cluster mode, allowing the system to start a new web server in case of a failure.
Clustered application processing units - applications are deployed into a special machine type, running service containers managed by a server manager that enforces SLA rules. SLA rules might involve some cluster topology and scalability options.
MySQL database connected to EBS – A dedicated machine running a MySQL database server, used to persist application data stored within the In-Memory Data Grid (IMDG). You can persist data in an asynchronous manner (via a Mirror Service which also runs on the database machine), or directly in a synchronous manner.
Full Application Life-Cycle Support
Starting applications using external configuration – applications that have been tested on a local environment can be deployed to the cloud as-is, using a configuration file that specifies how many machines the application initially needs to run on. The configuration file also specifies which other artifacts need to be run on the cloud to serve the application (database, load balancer, etc).
Adding more machines manually – once the application is running on the cloud, you can deploy it on additional machines at the click of a button.
Auto scaling based on SLA – once the application is running on the cloud, you can instruct the system to add machines dynamically. The application will then scale out to more machines automatically, as soon as it requires more data or more processing power.
Simple XML-Based Application Configuration
Order of deployment – the application configuration file includes information about the different processing units that need to be deployed and the deployment order.
Deployment topology and SLA – the deployment command can include the cluster topology, number of primary instances, number of backup instances, and parameters you would like to inject into the deployment process.
Application Repository
CCF4XAP stores application libraries and supporting files in a central virtual location called an application repository. This allows you to deploy the application from anywhere and anytime. You can modify the application deployment topology or add components without shutting down the application.
Deployment of multiple application versions – the actual application libraries and supporting files are located on the cloud-based repository. Once the machine running the GSM is started, it pulls the application libraries from the application repository and deploys the application on the machines running the SLA containers.
Multiple JVM versions support (currently 1.5, 1.6) – the application configuration can include information about the Java runtime version you would like to use when running the SLA container.
Dynamic installation of application packages – the application repository is also used to store different application packages (such as different GigaSpaces releases), which can be downloaded into the virtual machine as soon as it is started. This provides great flexibility, and avoiding the need to generate a new machine image for each GigaSpaces release.
Application state – the application repository is also used to store the application's current state. This includes an exact list of virtual machines which are currently hosting the application, their role, their deployment status, etc. The user can view and manage the application's current state using a browser-based UI or a CLI.
Multitenancy
CCF4XAP supports multitenancy in several dimensions:
Same User Can Manage Multiple Applications
Using the same Cloud Web Console – the Cloud Web Console supports simultaneous monitoring of multiple deployed applications.
Under the same cloud account – you can use the same cloud account to deploy multiple applications, each with a different setup.
Different versions can coexist – you can have multiple versions of the same application deployed at the same time, each using a different set of machines but sharing the same base configuration.
Complete Isolation of Management
Logging – each machine started on the cloud maintains a log file, which is accessible remotely. This can be used to troubleshoot the system if problems are identified.
Virtual desktop – you can access any machine which hosts the application from a remote desktop. Each user can have a separate virtual desktop and can have full control of the application components which are currently running.
Machines – each machine started on the cloud has a specific role. The role is assigned once the machine is started. Management and monitoring operations can be applied only to machines with a specific role.
Lifecycle - the application lifecycle can be controlled using the cloud management tools. You can start, add, remove or shut down all the machines running the application.
Unlimited Scalability
No single point of contention or central bottleneck
Access to all distributed components is done using a load-balancing strategy
Failover, Recovery and Self-Healing
When your application is deployed on the cloud, any component can potentially experience machine failure or process failure. Once this happens, your application might reject incoming requests, lose data or experience total failure. To prevent this, CCF4XAP provides resiliency, recoverability and self-healing capabilities – here are the supported scenarios:
When a web server fails - CCF4XAP instantiates a new machine with a web server container, and automatically connects it to the load balancer.
When an application transaction breaks - the relevant application fails to hot backup while starting a new backup.
When messaging is down – fails to hot backup while starting a new backup.
When the database is down – store data in-memory (with an in-memory backup) until the database is recovered.
When the deployment manager is down – fails to hot backup.
Fully Secure
Having your application deployed on a public environment demands special care. You'll need to protect your customer's data and your business systems from attacks. CCF4XAP allows you to secure applications deployed on the cloud, and the machines running those applications, using several security layers. Each layer is focused on a different aspect of the application:
Support for Amazon Security Groups – firewall settings blocking specific ports.
Next: 
Add Comment