View source for Cloud: Conceitos importantes para usuários do IBM Bluemix

Abaixo temos alguns conceitos importantes para quem tem uma conta no IBM Bluemix

=Conceitos=

==Cloud Foundry==

: O Cloud Foundry é uma ambiente de execução (Runtime), onde sua aplicação vai ser executada. Você não precisa se preocupar em qual Sistema 
: Operacional, Memória, ..., o você seleciona um Runtime do Catálogo, e a sua aplicação será executada. Se você fizer um deploy de uma aplicação Java, : o Runtime terá uma JVM, Application Server, ... para que sua aplicação seja executada.

 https://www.cloudfoundry.org/

=Organização do Bluemix=

[[File:BluemixOrganization.png]]

==Organization==
Organization é uma entidade que abrange todos os recursos de uma conta pública no Bluemix.

De forma semelhante a uma empresa, associação, ... que estarão disponibilizando uma aplicação no Bluemix.

Você acessa através do menu Manage -> Account -> Organizations

[[Ficheiro:BluemixOrgUsers.png]]

==Users==
São os Usuário na organização, que compartilham os recursos das sua conta, e que podem funções específicas por Organization e Space.

Outro conceito é o de Colaborador e Membro.

*  Colaborador
: Se você '''já''' tem uma conta no Bluemix e alguém te convida você para uma organização, você será um colaborador.
* Membro
: Se você '''não''' tem uma conta no Bluemix, mas alguém te convida você para uma organização, você será um membro.

==Quota==

Quota define os recursos disponíveis para a sua organização, isto é, a quantidade de serviços e de memória alocado pra sua organização.
 
Exemplo: Um usuário X pode criar uma VM com no máximo 2 processadores e no máximo 4 GB de RAM.

==Space==

Space é um grupo lógico de aplicações e serviços na plataforma. Podem haver múltiplos espaços por organização. 

Usuários de uma organização podem ser associados a múltiplos espaços e terem diferentes papéis (Developer, Manager ou Auditor) por espaço. Mas somente usuários com o papel de Developer, pode criar aplicações  e adicionar serviços a um espaço. Como:

* Administrador
* Desenvolvedor
* Auditor

[[File:BluemixSpaceUsers.png]]

Exemplo: Criar um projeto com os serviços e pessoas envolvidas com um software de RH, exemplo: 

* RHDigital-dev
* RHDigital-hom
* RHDigital-producao

==Region==

Region é um datacenter on a Bluemix pública está localizada.

Selecione uma região mais próxima do seu cliente para fazer o deploy de suas aplicações, com isso você diminui a latência de rede.

Outro motivo para usar uma região, é caso seu cliente tenha questões legais que regulamente onde deve ficar os seus dados.

Tabela de [https://www.ng.bluemix.net/docs/overview/overview.html#ov_intro Regiões e API endpoints].

==Domains e Routes==

'''Domain''' é o domínio internet para acessar sua aplicação e está associado à sua organização. Exemplo: mybluemix.net

'''Route''' é a URL que utilizada para direcionar requisições para uma aplicação. Basta acessar o Dashboard para ver a rota.

[[File:BluemixRoute.png]]

==API endipoint==
: API endipoint é uma url na REGION, onde existe um datacenter do Bluemix.
:
: Exemplos:
: * for Dallas, US region is  https://api.ng.bluemix.net
: * for London, UK region is  https://api.eu-gb.bluemix.net
: * for Sydney, Australia region is  https://api.au-syd.bluemix.net

=Paas no Bluemix=

==Runtimes==

Um runtime é conjunto de recursos para executar uma aplicação. Exemplos de runtime: uma plataforma Nodejs, um compilador Python, uma Java Virtual Machine (JVM).

==Boilerplates==
Um Boilerplate consiste na combinação de um runtime e serviços pré-definidos. Por exemplo: o boilerplate "NodeJs Cloudant DB Web Start", disponibiliza um runtime com NodeJs e um banco de dados NoSQL (Cloudant) já configurado e um aplicação tipo ''Hello World!''.

==Buildpack==
Buildpack é uma coleção de scripts que prepara seu código para ser executado no Paas. Um buildpack coleta dependências de um runtime e do framework de uma aplicação, então ele empacota estas dependências em um ''droplet'' que pode ser ''deployed'' no cloud.

==Service==
Um serviço prove uma funcionalidade pronta para o uso por sua aplicação. Exemplos de serviços podem ser um banco de dados, messaging, push notifications, elastic cache.

Existem 2 tipos de serviço:

* '''Managed service'''
: Integrados no Bluemix/Cloud Foundry através de um broker de serviços que implementam uma '''Service Broker API'''. Esta api notifica o Catalogo 
: de serviços do Bluemix/Cloud Foundry com 4 funções: create, delete, bind ou unbind. O broker então passa essas chamadas para o serviço propriamente.
: Desta maneira os usuários podem criar instâncias dos serviços e credenciais conforme a demanda.

* '''User provided service'''
: As instâncias de serviço fornecidas pelo usuário são um mecanismo para fornecer credenciais a aplicativos para instâncias de serviço que foram 
: pré-provisionadas fora do Bluemix.

=Bluemix e Cloud Foundry=

IBM Bluemix PaaS is built on Cloud Foundry, so you should understand the Bluemix and Cloud Foundry internal architecture and its components, such as Diego Cell, Cloud Controller, the Router and the interactions to maintain application availability.

Cloud Foundry Components 
http://docs.cloudfoundry.org/concepts/architecture/

==Diego Cell==

The Diego Cell hosts application instances, reports application status to the Diego Bulletin Board Service (BBS), and provides application logs, errors, and metrics to the Loggregator. Application instances live inside Garden containers. Containerization ensures that application instances run in isolation, get their fair share of resources, and are protected from noisy neighbors.

==Cloud Controller==

The Cloud Controller directs the deployment of applications. When you push an application to Cloud Foundry, the Cloud Controller uses the CC-Bridge to store the application bits and direct the Diego Brain to coordinate Diego Cells to stage and run applications.
Router

The Router routes incoming traffic to the appropriate component in the environment. For example, the Router sends traffic to the Cloud Controller for management of applications in their lifecycle or a hosted application on a Diego Cell. The Router is informed of active application instances through the router-emitter that monitors status in the Diego Bulletin Board Service (BBS).

==Application Availability==

Application availability is coordinated by the CC-Bridge nsync component, the Bulletin Board Service (BBS), and the Cell Rep component. The Cloud Controller uses the nsync component to save the number of instances for an application into a Desired Long Range Process (DesiredLRP) structure in the BBS database. The Cell Rep monitors containers and provides the Actual Long Range Process (ActualLRP) count to the BBS. The BBS uses its convergence process to monitor the DesiredLRP and ActualLRP values and launches or kills application instances to ensure the ActualLRP matches the DesiredLRP count.

==Service Broker==

The service broker advertises a catalog of service offerings and service plans to Bluemix and Cloud Foundry, and receives calls from Cloud Foundry for four functions: create, delete, bind, and unbind. The broker then passes these calls to the service itself.

= Links =

==IBM Bluemix documentation: “Virtual machines”==
–https://www.ng.bluemix.net/docs/virtualmachines/vm_index.html

==IBM Bluemix documentation: “IBM Containers”==
–https://www.ng.bluemix.net/docs/containers/container_index.html

= Ver também =

*[[Cloud| Mais Artigos sobre Cloud]]

[[Category:Cloud]]
[[Category:IBM]][[Category:Bluemix]][[Category:ibm-bluemix]]