services, (Federated) service contracting, 
CSLA provision, users management, 
security management and creation of the 
aggregated services in the FCSB. 
  Service operation, including CB CSLA 
monitoring, legislation compliance due to 
changes in the legislation, data 
migration/portability, service metering, 
billing to the user, and CP costs estimation. 
  Service termination: including service 
withdrawal and service contract termination 
3.3  Deployment Options and 
Technologies to Be Used 
There are different elements to consider when 
deciding the deployment of the presented solution, 
and the technologies to be used:  
  Resources  
  The application architecture and stage 
(monolithic, modular, service oriented, 
layered) 
  The forecasted demand and its possible 
evolution 
  Additional NFRs, such as profitability, 
high-availability, scaling, etc.  
Taking all the above into account, it is important 
to focus the application architecture and 
development towards the most flexible result. We 
need an application that is capable to be deployed 
anyway, anywhere and supported by anyone. And an 
application that is prepared to scale and provide 
additional NFRs. 
To achieve that purpose we envision to: 
  Implement a micro-cloud approach: split 
the application in components and place 
each component in a container. This will 
allow in the future scaling independently 
each component. 
  Package the code in installable binaries 
*.deb, *.rpm, etc. 
  Use popular technologies: Those with a 
significant user base. 
  Avoid vendor locking: Avoid proprietary 
solutions with vendor locking effects. And 
in case, there is no alternative, wrap the 
vendor locking technology or XaaS.  
  Split since the beginning those components 
that are subject to XaaS, i.e. databases, 
notification, storage, etc. 
  Focus on technologies that can be used by 
many instances of the same component: 
databases, memcached, object storage, 
block storage servers. 
  Decouple as much as possible also in data: 
avoid big databases; differentiate between 
static, dynamic and temporal information; 
do not share databases among components; 
minimize information writing and 
centralize that writing in one component.  
Besides, during the development we propose to 
use a DevOps approach to streamline the 
development and systematize the operation and 
maintenance activities. 
Summarizing the list of technologies proposed to 
the implementation of the design contained are: 
  Mature and highly used programming 
languages: Java, Javascript, Python, 
PHP. 
  Dependency management technologies 
such as maven for java, or distutils and 
set up tools for python. 
  Repository (Git or svn) for application 
code, configuration, installation binaries 
or infrastructure specification. 
  Package management systems such as 
apt-get or yum 
  Container technologies such as docker, 
openshift, cloudfoundry, … 
  Database for information storage 
relational or non-relational  
  Cache technologies, such as 
memcached or redis, technologies when 
possible 
3.4  Other Aspects of the FCSB 
Solution 
PAs need to be enabled to seamlessly change the 
service provider including all services, dependencies 
and associated data to avoid vendor lock-in and to be 
able to quickly react in situations like bankruptcy of 
the cloud provider or any other cases which causes 
outage of the service. This imposes to adhere to 
existing and established standards, standard 
interfaces, paradigms and certifications.  
In the proposed technical design the seamless 
change of cloud provider, that is, the portability 
between two different providers will be supported by 
the Intelligent Service Discovery module and the 
Interoperability module. These modules, and 
therefore, the FCSB will support the following 
standards: CDMI (SNIA, 2016) , OCCI (OCCI 
Working Group, 2011), TOSCA (OASIS, 2015), 
IEEE P2301: P2302 (IEEE, 2016). 
For the FCSB to be adopted by European Public 
Administrations, the FCSB must be aligned and 
comply with EU standards and existing legislation.