Escolar Documentos
Profissional Documentos
Cultura Documentos
São Paulo
2016
RESUMO
1 INTRODUÇÃO.......................................................................................................................6
1.1 CONSIDERAÇÕES INICIAIS E MOTIVAÇÃO............................................................6
1.2 OBJETIVO........................................................................................................................7
1.3 CONTEÚDO E ORGANIZAÇÃO...................................................................................7
2 VIRTUALIZAÇÃO.................................................................................................................9
2.1 INTRODUÇÃO................................................................................................................9
2.2 MODELOS DE VIRTUALIZAÇÃO................................................................................9
2.2.1 VIRTUALIZAÇÃO COMPLETA POR TRADUÇÃO BINÁRIA................................9
2.2.2 PARAVIRTUALIZAÇÃO...........................................................................................10
2.2.3 VIRTUALIZAÇÃO NATIVA OU AUXILIADA POR HARDWARE........................11
2.2.4 VIRTUALIZAÇÃO POR SISTEMA OPERACIONAL.............................................13
3 CLOUD COMPUTING.........................................................................................................15
3.1 INTRODUÇÃO..............................................................................................................15
3.2 CARACTERÍSTICAS ESSENCIAIS.............................................................................15
3.3 MODELOS DE SERVIÇOS...........................................................................................16
3.4 MODELOS DE IMPLEMENTAÇÃO............................................................................16
4 INFRASTRUCTURE AS A SERVICE (IAAS).....................................................................18
4.1 INTRODUÇÃO..............................................................................................................18
4.2 CARACTERÍSTICAS....................................................................................................18
4.3 PROVEDORES E TECNOLOGIAS..............................................................................19
4.4 OPENSTACK.................................................................................................................20
5 PLATFORM AS A SERVICE (PAAS)...................................................................................23
5.1 INTRODUÇÃO..............................................................................................................23
5.2 CARACTERÍSTICAS....................................................................................................23
5.3 PROVEDORES E TECNOLOGIAS..............................................................................24
6 CONTAINERS DOCKER.....................................................................................................25
6.1 INTRODUÇÃO..............................................................................................................25
6.2 ARQUITETURA E COMPONENTES...........................................................................26
6.3 EXECUÇÃO DE CONTAINERS...................................................................................28
6.4 FUNDAMENTOS DA VIRTUALIZAÇÃO POR CONTAINERS................................29
6.5 SEGURANÇA................................................................................................................33
6.6 MODELOS DE OPERAÇÃO........................................................................................36
6.7 INDICAÇÕES DE USO DE CONTAINERS E MÁQUINAS VIRTUAIS...................38
6.8 ORQUESTRAÇÃO DE CONTAINERS........................................................................39
6.9 DOCKER COM OPENSTACK......................................................................................40
7 CONCLUSÃO.......................................................................................................................43
7.1 CONSIDERAÇÕES FINAIS..........................................................................................43
7.2 TRABALHOS FUTUROS E MELHORIAS..................................................................45
8 REFERÊNCIAS.....................................................................................................................46
6
1 INTRODUÇÃO
1.1 CONSIDERAÇÕES INICIAIS E MOTIVAÇÃO
Em áreas ou empresas de TI tradicionais a implantação de um novo sistema
em ambiente produtivo precisa ser planejada com antecedência. Por meio da
inspeção dos requisitos não funcionais (quantidade de acessos simultâneos,
tamanho do tráfego de dados das transações, tempo de resposta, disponibilidade,
escalabilidade, continuidade e segurança) a arquitetura da solução é desenhada e
uma estimativa de capacidade da infraestrutura é realizada.
De posse das definições de arquitetura e do planejamento de capacidade, a
infraestrutura é adquirida, instalada e configurada. Porém ao implantar o novo
sistema em produção, mesmo após uma análise de capacidade apurada, é comum a
constatação de que a infraestrutura provisionada está subutilizada. Em muitos casos
a análise da capacidade da infraestrutura leva em consideração o pico da utilização
dos recursos, quando estes podem ocorrer apenas raramente. Em outros casos, por
restrições de projeto, o aumento da utilização do sistema ocorre de forma gradativa,
mas a infraestrutura é provisionada desde o inicio para atender toda a carga
prevista.
Em busca de maior agilidade e eficiência, muitas empresas tem buscado por
soluções de cloud computing públicas e/ou privadas para o provisionamento da
infraestrutura (IaaS), publicação de aplicações (PaaS) ou utilização de software
(SaaS) contratadas como serviço. Na busca por padronização, algumas empresas
de tecnologia trabalham em conjunto para o desenvolvimento de soluções de cloud
(por exemplo, OpenStack). Outras empresas buscam sozinhas estabelecer padrões
(exemplos, OpenShift da Red Hat ou vCloud da VMware). Entretanto a base de
todas as soluções de cloud está na virtualização das camadas de processamento,
de rede e de armazenamento (ZANGH, CHENG & BOUTABA, 2010).
Em se tratando de virtualização, há diversos hypervisors disponíveis no
mercado tanto open source como de código proprietário. Através de um hypervisor é
possível ter em um computador físico (bare metal) diversas máquinas virtuais de
sistemas operacionais diferentes compartilhando o mesmo hardware. Antes mesmo
da explosão dos conceitos de cloud computing, a virtualização de servidores trouxe
para a TI muitos benefícios administrativos, de disponibilidade e de melhor uso da
capacidade ociosa dos recursos de processamento. A consolidação de servidores
7
2 VIRTUALIZAÇÃO
2.1 INTRODUÇÃO
Antes do advento da virtualização de servidores as aplicações eram
comumente instaladas em servidores físicos dedicados (bare metal). Esta era uma
exigência comum dos fabricantes de software a fim de evitar problemas de
incompatibilidade entre aplicações distintas e a perda de suporte do fornecedor. A
crescente demanda dos negócios por soluções de software resultou em Data
Centers com grande capacidade de processamento, com servidores físicos
dedicados para cada aplicação, resultando com frequência em baixa eficiência no
uso dos recursos de infraestrutura (hardware, energia elétrica, espaço físico e
refrigeração) e ociosidade de processamento.
A virtualização possibilitou o compartilhamento dos recursos de um mesmo
servidor físico (processador, memória, disco e rede) entre diferentes aplicações
executadas em contextos de processamento isolados, pertencentes aos servidores
virtuais. Entre os principais benefícios alcançados estão a redução de custos e do
consumo de energia elétrica, a criação de processos simplificados de alta
disponibilidade e continuidade, a migração de servidores virtuais entre servidores
físicos sem causar indisponibilidade do serviço e a agilidade técnica para o
provisionamento de novos servidores (NEMETH, SNYDER et al., 2011).
2.2 MODELOS DE VIRTUALIZAÇÃO
2.2.1 VIRTUALIZAÇÃO COMPLETA POR TRADUÇÃO BINÁRIA
Neste modelo um software hypervisor (virtual machine manager) é
responsável por prover os ambientes virtuais de execução, emulando para os
sistemas operacionais das máquinas virtuais hóspedes (VMs) os dispositivos de
hardware físicos. Os sistemas operacionais das VMs “não sabem” que suas
instruções não são executadas diretamente no hardware físico. Antes da execução
as requisições de instruções privilegiadas são interceptadas e traduzidas pelo
hypervisor (NEMETH, SNYDER et al., 2011). Instruções não privilegiadas
(executadas no nível do usuário) são enviadas diretamente para processamento no
hardware físico (VMware White Paper. Understanding Full Virtualization,
Paravirtualization, and Hardware Assist, 2007).
10
2.2.2 PARAVIRTUALIZAÇÃO
Assim como o modelo completamente virtualizado por tradução binária, na
paravirtualização um software hypervisor (VMM) é responsável por prover os
ambientes virtuais de execução, emulando para os sistemas operacionais das
máquinas virtuais hóspedes (VMs) os dispositivos de hardware físicos. Porém, o
sistema operacional de cada VM é modificado para substituir as chamadas de
instruções privilegiadas do kernel por hypercalls (chamadas de hypervisor), o que
reduz a sobrecarga causada pela tradução de instruções do modelo de virtualização
completa por tradução binária, mas torna o sistema operacional das VMs fortemente
acoplado ao hypervisor (NEMETH, SNYDER et al., 2011). As instruções não
privilegiadas (executadas no nível de usuário) são enviadas diretamente para
11
1
. Os processadores de arquitetura x86 possuem quatro possíveis estados de execução. Na maioria dos sistemas
operacionais o estado 0 é utilizado para a execução de instruções privilegiadas do sistema operacional e o estado
3 para execução de instruções não privilegiadas. Os estados 1 e 2 não são normalmente utilizados (BOVET &
CESATI, 2005).
13
3 CLOUD COMPUTING
3.1 INTRODUÇÃO
Mell & Grance (2011) definiram Cloud Computing como um modelo de
computação sob demanda, capaz de provisionar recursos de rede, armazenamento,
processamento, aplicações e serviços rapidamente e com mínimo esforço de
gerenciamento ou de interação com o provedor do serviço. Este modelo é composto
por cinco características essenciais, três modelos de serviços e quatro modelos de
implementação.
3.2 CARACTERÍSTICAS ESSENCIAIS
Auto serviço sob demanda: Um cliente da cloud pode provisionar
capacidades computacionais sob demanda, sem interação humana com o
provedor do serviço.
Acesso amplo pela rede: Os recursos devem estar disponíveis através da
rede por meio de interfaces padronizadas, possibilitando acesso para
diferentes tipos de dispositivos tais como telefones celulares, tablets, laptops
e estações de trabalho.
Pool de recursos: Os provedores de cloud agrupam recursos físicos e
virtuais de sua infraestrutura e os atribuem dinamicamente aos seus diversos
clientes sob demanda. Os clientes tem pouco controle sobre a infraestrutura
física onde as suas aplicações são executadas, exceto em alto nível de
abstração (por exemplo, país, estado ou Data Center onde o pool de recursos
do cliente foi alocado).
Rápida elasticidade: As capacidades de infraestrutura podem ser
aumentadas ou diminuídas rapidamente sob demanda e possivelmente de
forma automática. Para os clientes é criada uma camada de abstração que
faz parecer que os recursos de infraestrutura são ilimitados e que podem ser
redimensionados em qualquer quantidade e a qualquer momento.
Serviços mensuráveis: Sistemas de cloud monitoram e controlam
automaticamente o consumo de recursos em um nível de abstração
adequado ao tipo de serviço (para citar alguns exemplos: armazenamento,
capacidade de processamento, largura de banda e contas de usuários ativas).
Por meio de relatórios automáticos, tanto o provedor de cloud, quanto os seus
16
6 CONTAINERS DOCKER
6.1 INTRODUÇÃO
Docker é uma plataforma open source baseada no kernel do Linux, que auto-
matiza o deployment de aplicações por meio de containers altamente portáveis e au-
tossuficientes, independente de hardware, linguagem e framework de desenvolvi-
mento. Apesar dos containers executarem em um host sobre um mesmo kernel de
sistema operacional, cada container pode executar diferentes versões de binários e
bibliotecas de SO, de acordo com os requisitos de cada aplicação. Através de uma
API de alto nível, Docker gerencia a criação de containers que executam as aplica-
ções de forma isolada (OpenStack. Docker).
Nos últimos anos, muitas mudanças em diferentes áreas de TI tem ocorrido
de forma simultânea. Na área de infraestrutura tem-se observado a evolução das
tecnologias disruptivas de containers, como o Docker. Ao mesmo tempo, na área da
arquitetura, as aplicações tem saído do modelo monolítico para o de micro serviços.
Em paralelo novas metodologias de processos como DevOps e continuous delivery
(CD) têm trazido conceitos de colaboração (entre as áreas de desenvolvimento e
operação), de que é normal falhar (desde que que a correção seja rápida), e que
feedbacks devem ser colhidos a cada publicação de código, entre outros. As evolu-
ções nestas três áreas de TI têm se realimentado e trazido avanços na habilidade de
entregar valor para o negócio de forma mais rápida.
Docker facilita a interação entre os times de desenvolvimento e de operação.
Enquanto no modelo tradicional são publicados entre os ambientes os binários da
aplicação, com o Docker a publicação é feita no nível do container. Em razão do
Docker encapsular a aplicação juntamente com o seu ambiente de execução (siste-
ma operacional e dependências, tais como, binários, bibliotecas, arquivos de confi -
guração, scripts, ambientes virtuais, jars, gems, tarballs e etc), ele provê dois impor-
tantes aspectos para o processo de entrega continua (CloudBees. Jenkins, Docker
and Devops: The Innovation Catalysts, 2015):
Os desenvolvedores entregam Containers Docker e a operação de TI os pu-
blica. Deste modo garante-se que o mesmo pacote de binários será testado
em ambientes idênticos em todas as fases do processo de continuous deli-
26
very, sem que sejam inseridas falhas no ciclo de publicação entre os diferen-
tes ambientes;
Os desenvolvedores recebem um ambiente de “sandbox” que pode ser facil-
mente reciclado sempre que necessário.
Através da plataforma as imagens com as aplicações podem ser alteradas e
versionadas, fazendo do Docker uma poderosa ferramenta no pipeline de desenvol-
vimento de sistemas ou como runtime em soluções de PaaS. Para que seja utilizada
no processo de desenvolvimento, Docker combina sua plataforma de containers com
workflows e ferramentas que auxiliam no gerenciamento e na publicação das aplica-
ções (Docker. Introduction to Container Security, 2015).
O uso de containers é bastante apropriado para a publicação de aplicações
construídas no estilo arquitetural de microservices. Com o uso desta abordagem as
funções de uma simples aplicação são decompostas em micro serviços
independentes e fracamente acoplados, que podem ser publicados na infraestrutura
em grupos de containers segregados. Cada micro serviço é executado em seu
próprio processo e comunica-se com outros micro serviços por mecanismos
assíncronos de comunicação. Estes serviços devem ser publicados de forma
independente por processos completamente automatizado. Em razão do
desacoplamento entre os serviços, alterações podem ser publicadas com grande
frequência e em momentos arbitrários, sem a necessidade de seguir janelas de
publicação ou de sincronizar a publicação das alterações juntamente com
modificações em outros serviços (PAHL, 2015).
6.2 ARQUITETURA E COMPONENTES
Docker foi desenhado em uma arquitetura cliente/servidor, onde o cliente
pode ser executado local ou remotamente ao servidor Docker (Docker Engine). A co-
municação entre o cliente e o servidor pode ser estabelecida por meio de sockets ou
RESTful APIs (APIs compatíveis com as restrições do estilo arquitetural REST).
Os Containers Docker utilizam file systems de atualização tipo copy-on-write,
que permitem o uso de uma imagem de file system como camada base para a exe-
cução de múltiplos containers. Alterações efetuadas em arquivos ou diretórios dentro
de um container são isoladas e não podem ser vistas fora dele (Docker. Introduction
to Container Security, 2015).
27
Cria um novo container: Uma vez que o servidor Docker tenha a imagem,
ele a utiliza para criar o container.
Aloca um sistema de arquivos e monta uma camada de “escrita e
leitura”: o container é criado no file system do servidor Docker e uma cama-
da de escrita e leitura é adicionada a imagem para uso das aplicações.
Aloca uma interface de rede: cria uma interface de rede que permite a cone-
xão do container com o servidor Docker.
Configura um endereço IP: Localiza um endereço IP disponível em um pool
e o configura no container.
Executa um processo: executa uma aplicação especificada pelo usuário.
Captura e gera arquivos de logs das aplicações: conecta e captura as
standards in, out e error do container para que o usuário possa verificar como
a suas aplicações estão rodando.
6.4 FUNDAMENTOS DA VIRTUALIZAÇÃO POR CONTAINERS
Assim como outras tecnologias de containers baseadas em Linux, Docker uti-
liza os mecanismos de namespaces e de control groups (cgroups) do kernel para,
respectivamente, isolar os processos entre os diferentes containers e monitorar/limi-
tar o uso dos recursos de infraestrutura. Adicionalmente, o sistema de arquivos dos
containers são do tipo Union File System, que implementam a montagem do sistema
de arquivos em múltiplas camadas (PAHL, 2015).
6.4.1 NAMESPACES
Segundo informação do man-pages do Linux (Linux Programmer's Manual.
NAMESPACES(7), 2014), um namespace encapsula um recurso global do sistema
em uma abstração, fazendo parecer aos processos pertencentes a este namespace,
que possuem sua própria instância de recurso global isolada.
Um container é um conjunto de namespaces criados por meio de uma interfa-
ce com o kernel. Constituem uma área de trabalho isolada para um grupo de proces-
sos. Cada processo é executado sobre determinado conjunto de namespaces, não
interagindo com recursos pertencentes a outros namespaces (Docker. Understand
the Architecture). Abaixo segue uma descrição dos namespaces providos pelo ker-
nel do Linux:
30
7 CONCLUSÃO
7.1 CONSIDERAÇÕES FINAIS
A adoção de uma tecnologia de IaaS como o OpenStack traz muitos recursos
de automação, que possibilitam o provisionamento automático de servidores, stora-
ge e rede de forma rápida e padronizada e agilizam a detecção e isolamento de fa-
lhas. Entre seus recursos está a possibilidade de escalabilidade da infraestrutura de
forma automática, baseada em parâmetros pré-configurados e em indicadores provi-
dos pela monitoração.
Do ponto de vista do negócio, espera-se minimamente de uma solução de
cloud a redução do time-to-market de entrega das aplicações, maior disponibilidade
e escalabilidade do ambiente de TI, maior controle sobre os SLAs e cobrança como
serviço baseada na simples utilização de recursos.
Do ponto de vista técnico, a base das soluções de cloud está na virtualização
da infraestrutura de execução das aplicações. O uso de máquinas virtuais (VM) é
comprovadamente um meio eficiente e seguro de compartilhar a infraestrutura de
hardware entre diferentes aplicações. Porém, cada VM tem o overhead de carregar
uma imagem de sistema operacional completa, que consome memória do servidor e
torna o processo de inicialização das aplicações lento (cerca de minutos), em decor-
rência da dependência do processo de boot do sistema operacional.
Por outro lado, o uso de containers como o Docker permite a execução de
aplicações em processos e áreas de memória isoladas, sobre um único sistema ope-
racional em máquina física ou virtual, e com a possibilidade de limitar o uso dos re-
cursos do hardware de cada container. Porém, como vimos, o isolamento consegui-
do com containers é inferior ao entregue pelos hypervisors. Vulnerabilidades novas
do kernel e de escalação de privilégios de usuário para root dentro de um container
podem comprometer a segurança do host e impactar a execução de todos os contai-
ners, além da falta de suporte no uso da virtualização de hardware dos processado-
res, que oferece um nível a mais de isolamento. Portanto, para casos de uso que
exijam maior garantia de isolamento entre as aplicações, o uso de máquinas virtuais
é mais adequado.
Porém, no caso de aplicações construídas com arquitetura de microservices é
bastante dispendioso executar uma grande quantidade de micro serviços (dezenas,
centenas ou milhares deles) sobre máquinas virtuais, pois conceitualmente cada mi-
44
cro serviço deverá ser executado sobre sua própria VM. Em situações como esta o
uso de containers é mais apropriado, permitindo a execução das aplicações isola-
das, com baixo overhead da infraestrutura e tempos de inicialização na casa de se-
gundos.
Os requisitos de negócio de maior controle sobre os SLAs e cobrança como
serviço são facilmente endereçáveis através dos relatórios da solução da IaaS. A re-
dução do time-to-market da entrega das aplicações, porém, não depende apenas do
provisionamento rápido da infraestrutura. Requer um processo de desenvolvimento
e de publicação de aplicações eficiente.
Muitas empresas tem optado por processos de continuous delivery, que em
essência combina processos e ferramentas que automatizam tarefas de compilação,
empacotamento, testes e publicação das aplicações (não necessariamente em pro-
dução), dando agilidade ao processo de desenvolvimento e maior flexibilidade e se-
gurança para a publicação e rollback de código (quando necessário) em produção. A
tecnologia de Containers Docker facilita o processo de desenvolvimento em razão
de publicar entre os diferentes ambientes não apenas os binários da aplicação, mas
todo o ambiente de execução, o que torna o processo efetivo e confiável. Por esta
razão muitas soluções de PaaS tem adotado o uso de Containers Docker como seu
runtime.
O uso de Containers Docker também favorece uma maior disponibilidade e
agilidade na escalabilidade dos serviços. Em caso de indisponibilidade da infraestru-
tura ou aumento da demanda no consumo dos serviços detectadas pela monitora -
ção, basta que a ferramenta de automação, por meio das APIs Docker, traga do re-
positório a imagem Docker com o atual release de produção e a execute como con-
tainer em um servidor físico ou virtual por meio do daemon Docker. Caso o host já
tenha uma imagem de releases anteriores, apenas os arquivos modificados no rele-
ase corrente são trazidos do repositório. Deste modo, em poucos segundos novas
instâncias da aplicação estarão em execução nos containers.
Portanto, como diretriz geral para o provisionamento de servidores, aplica-
ções de diferentes linhas de negócio devem ser executadas em máquinas virtuais
separadas. Porém dentro de um mesmo negócio, as aplicações podem ser divididas
em um menor número de máquinas virtuais, onde cada VM terá os seus serviços
45
executados isolados em Containers Docker. Esta modelo tira proveito do melhor dos
dois mundos:
A utilização dos mecanismos nativos de alta disponibilidade, migração “a
quente” e isolamento entre as aplicações de diferentes linhas de negócio atra-
vés de máquinas virtuais.
O isolamento e controle do uso de recursos entre as diferentes aplicações de
uma mesma linha de negócio, somada a agilidade e segurança na publicação
da aplicações por meio dos containers.
A redução do overhead de infraestrutura em razão da redução do número de
máquinas virtuais em execução.
A tecnologia de containers está em constante evolução. Atualmente o uso de
Containers Docker é restrito para aplicações baseadas em Linux. A Microsoft anunci-
ou, porém, o desenvolvimento de sua plataforma de containers baseada no kernel
do Windows que será oficialmente lançada no Windows Server 2016. As APIs do
Docker estão sendo portadas para o Windows, de maneira que os clients Docker te-
nham interoperabilidade entre as plataformas e os usuários tenham a mesma experi-
ência de uso com Linux ou Windows.
Em razão da extensão das APIs Docker para o Windows, quando os contai-
ners Windows tornarem-se realidade, as mesmas ferramentas de automação do ci-
clo de desenvolvimento de sistemas poderão ser utilizadas para o provisionamento
de containers Linux ou Windows e funcionarão exatamente da mesma forma. Deste
modo os processos de desenvolvimento e de operação de TI serão simplificados,
agregando maior valor ao negócio.
7.2 TRABALHOS FUTUROS E MELHORIAS
Alguns assuntos importantes foram citados ou tratados apenas de maneira
superficial. Novos trabalhos de pesquisa, em continuidade a este, poderiam abordá-
los mais profundamente. Alguns deles são:
Integração de ferramentas de automação de processos de continuous inte-
gration e continuous delivery (exemplo, Jenkins) com um orquestrador Docker
(exemplos, Docker Swarm e Docker Compose), integrados com a solução de
provisionamento de infraestrutura de containers do Magnum OpenStack.
Estudo das funcionalidades e fundamentos da nova solução de containers ba-
seada no kernel Windows.
46
8 REFERÊNCIAS
BERNSTEIN, D. IEEE Cloud Compute Magazine. Cloud Foundry Aims to Become
the OpenStack of PaaS, v.1, Issue 2, p. 57-60, July 2014.
BOVET, D. P. & CESATI, M.: Understanding the Linux Kernel, Third Edition.
Sebastopol: Oreilly, 2005. 19p.
DOCKER Blog. Docker 0.9: introducting execution drivers and libcontainer, Mar.
2010. Disponível em:
https://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-
libcontainer/. Acesso em: 10 Jan. 2016
INTEL. Intel® Virtualization Technology for Directed I/O (VT-d): Enhancing Intel
platforms for efficient virtualization of I/O devices, Mar. 2012. Disponível em:
https://software.intel.com/en-us/articles/intel-virtualization-technology-for-directed-io-
vt-d-enhancing-intel-platforms-for-efficient-virtualization-of-io-devices#_edn1. Acesso
em: 13 Jan. 2016.
LAWTON, G. Computer. Developing Software Online with Platform-as-a-Service
Technology, v. 41, Issue 6, p. 13-15, 2008. ISSN: 0018-9162.
MELL, P. & GRANCE, T.: National Institute of Standards and Technology. The NIST
Definition of Cloud Computing, 2011.
NEMETH, E. & SNYDER, G. & HEIN, T. R. & WHALEY, B.: Unix and Linux System
Administration Handbook, Fourth Edition. Boston: Person Education, 2011. 983-
991p.
OPENSTACK. Docker.
Disponível em: https://wiki.openstack.org/wiki/Docker#Overview. Acesso em:
12/01/2016.
48
PAHL, C. IEEE Cloud Compute Magazine. Containerisation and the PaaS Cloud,
v. 2, Issue 3, p. 24-31, 2015. ISSN: 2325-6095