Elasticity is one of the most important part of RoQ, as the phrase says : "RoQ, Rock solid, yet elastic"
In this context, we thought about the cloud integration of RoQ, which will have to be able to run on a very heterogeneous environment, considering cloud providers, operating systems and hardware architecture, we will have to answer to tons of questions, the main are :
1/ Which type of deployment : Image management ? Configuration Management ?
2/ What are the limiting factors ?
3/ How to be sure of the elasticity and speed of the scalability ?
1/ Which type of deployment ?
Regarding the type of deployment, we tried to be focused on a single image, running a server OS, our first choice was Ubuntu Server Edition, which appeared to be too large after Java and RoQ installation, ending to up to 4Gb by base image... which is a bit big to fast scale, even on a hyper-mega-powerful-magic infrastructure...
After selecting the base image, we had to face the plethora of cloud providers, our first choice was OpenNebula / KVM, since we're running a full OpenNebula lab in our premises, meaning we had to contextualize the image, and manage it to be always up to date, both on OS and RoQ side.
So if you multiply this base OpenNebula/KVM/Ubuntu image, with the number of Operating Systems able to run RoQ, the number of hypervisors and the number of cloud providers, my maths have never been really good, but I'm sure that you end up around ... TOO MUCH !!
Then we thought that we could pivot and investigate the track of configuration managers (Chef, Capsitrano, Puppet etc...), those are tracks still in progress, but on the paper it seems fantastic to define different profiles that you could apply whatever OS or Hypervisors you're using :) Looks like a "lazy sysadmin tool"... a life achievement :)
2/ What are the limiting factors ?
In scalability, we have to face several factors :
Machines : physical, virtual, high or low end specs
Network : ethernet, thunderbolt, dark fiber
Storage : local, distributed, shared, dedicated, SSD, hard...
Deployment process : local, cloud
Each of these factors raise its own lot of questions, for which you have to make choice, or you can try to avoid choosing and create something agnostic enough to be running on whatever basic layers you're using.
That's why we will keep in mind the following principles :
1/ RoQ installation should be done easily whatever infra you're using
2/ New RoQ thread (in VM or not) should be quickly deploied (matter of seconds)
Yes, yes, we will be working for YOU !
3/ How to be sure of our speed ?
This part is quite a merge of the 2 previous questions, since we will have to combine infrastructure requirements, deployment and configuration systems to answer this.
To make a long story short, we will have to think that RoQ is agnostic and light, in both size and management...
Yes... challenging, but what's the point of staying in our comfort zone when we're shaping the future ?
Elasticity is one of the most important part of RoQ, as the phrase says : "RoQ, Rock solid, yet elastic"
In this context, we thought about the cloud integration of RoQ, which will have to be able to run on a very heterogeneous environment, considering cloud providers, operating systems and hardware architecture, we will have to answer to tons of questions, the main are :
1/ Which type of deployment : Image management ? Configuration Management ?
2/ What are the limiting factors ?
3/ How to be sure of the elasticity and speed of the scalability ?
1/ Which type of deployment ?
Regarding the type of deployment, we tried to be focused on a single image, running a server OS, our first choice was Ubuntu Server Edition, which appeared to be too large after Java and RoQ installation, ending to up to 4Gb by base image... which is a bit big to fast scale, even on a hyper-mega-powerful-magic infrastructure...
After selecting the base image, we had to face the plethora of cloud providers, our first choice was OpenNebula / KVM, since we're running a full OpenNebula lab in our premises, meaning we had to contextualize the image, and manage it to be always up to date, both on OS and RoQ side.
So if you multiply this base OpenNebula/KVM/Ubuntu image, with the number of Operating Systems able to run RoQ, the number of hypervisors and the number of cloud providers, my maths have never been really good, but I'm sure that you end up around ... TOO MUCH !!
Then we thought that we could pivot and investigate the track of configuration managers (Chef, Capsitrano, Puppet etc...), those are tracks still in progress, but on the paper it seems fantastic to define different profiles that you could apply whatever OS or Hypervisors you're using :) Looks like a "lazy sysadmin tool"... a life achievement :)
2/ What are the limiting factors ?
In scalability, we have to face several factors :
Machines : physical, virtual, high or low end specs Network : ethernet, thunderbolt, dark fiber Storage : local, distributed, shared, dedicated, SSD, hard... Deployment process : local, cloud
Each of these factors raise its own lot of questions, for which you have to make choice, or you can try to avoid choosing and create something agnostic enough to be running on whatever basic layers you're using.
That's why we will keep in mind the following principles :
1/ RoQ installation should be done easily whatever infra you're using
2/ New RoQ thread (in VM or not) should be quickly deploied (matter of seconds)
Yes, yes, we will be working for YOU !
3/ How to be sure of our speed ?
This part is quite a merge of the 2 previous questions, since we will have to combine infrastructure requirements, deployment and configuration systems to answer this.
To make a long story short, we will have to think that RoQ is agnostic and light, in both size and management...
Yes... challenging, but what's the point of staying in our comfort zone when we're shaping the future ?
To be continued...