Info
ou intox ? L’annonce de la version 4.5 de la plate-forme Sensage a de quoi laisser songeur.
Le CEP (Complex Event Processing), c’est d’importants volumes de messages à traiter en temps presque réel, de grosses volumétries à gérer… Des contraintes a priori peu compatibles avec une externalisation vers le cloud. Avec son stockage en colonnes, son architecture MPP, la solution Sensage apporte effectivement une solution à ces problématiques. Mais pour autant l’annonce de Sensage ressemble plus une réponse marketing qu’une solution technique crédible. Les entreprises veulent qu’on leur parle réduction des coûts et réduction de leur CAPEX ? ok, on sort en catastrophe une version certifiée sur VMware pour les adaptes de la virtualisation et une version cloud pour les autres, et l’affair est bouclée. Est-ce pour autant du vent ? Rien n’est moins sûr : Sensage a visiblement convaincu trois prestataires (l’américain Cerner, BT et le japonais JIEC) de proposer sa plate-forme en mode Saas. Un nouvel acronyme à l’horizon : CEPAAS ?
Loading ...
Si SenSage n’effectue pas le traitement des données en temps réel – sans le mot « presque » – SenSage n’est pas une plate-forme CEP.
It appears you assume in your article this topology for the SenSage SaaS: +————-+ | enterprise |
| |
| data | analysis consumer
| center |
| | ^
+————-+ | |
| |
V |
| |
| log data |
| |
| |
| |
V |
+——————+ |
| cloud provider | |
| | —-+
| SenSage |
| deployment |
| |
| analysis |
+——————+
This arrangement might work for small enterprises but clearly latency for the « real-time aspects » (« emps presque réel ») would not be sufficient for real protection.The above situation is not the architecture SenSage expects for SaaS … the real value in SenSage SaaS is in this configuration:
external threat –+
|
|
+———————+——+
| cloud provider | |
| | |
| +———+ | |
| | secured | <——+ |
| | service | |
| +———+ <——+ |
| | |
| | threat| |
| V |
| | +———+ |
| log | | other | |
| data | | service | |
| | +———+ |
| | |
| V |
| |
| +————+ |
| | SenSage | |
| | deployment | |
| +————+ |
| |
| |
+—————————-+
In this situation SenSage is co-resident in the cloud-provider with the SenSage customer (which runs the « secured service »). SenSage is in this case a true real-time security provider, and also efficiently archives log data. SenSage would in this have no choice but to run in a VMware/Xen/Linux-KVM virtual host. In a normal non-SaaS environment there is much less reason to run SenSage in a virtual host … it’s not efficient, and many SenSage clusters are 5-25 physical machines — there’s no advantage in virtualization that I see.From http://sev.prnewswire.com/computer-electronics/20090715/SF4659815072009-1.html:<<SenSage 4.5 software can be delivered as … SaaS … to meet the needs of public cloud
service providers who desire to offer SenSage solutions>> == cloud providers want to give their tenant customers that host services a solution for their real-time and forensics security — more $$$$ for the cloud provider<<Multi-tenancy issues complicate cloud-based deployments from a security perspective … >> == SenSage is meant to secure services INSIDE the cloud provider’s infrastructure, not OUTSIDE the cloud provider’s infrastructure
The question is : What are the applications which tolerate a CEP engine on-premise and the event data storage layer on the cloud ?
- Storing logs of an internet provider for a possible use in the future, ok,
- Computing business rules in real time as events arrive and correlating them with previous events within billions on them (e.g credit card system), not sure that such cloud architecture fits.
PS : sorry for the font, X.Watson!