
French: 
Déploiement et gestion des API
- Bienvenue à cette session
Lightboard, nous allons parler
de l'architecture CloudHub.
Mule est donc un serveur d'application.
Il a besoin d'une infrastructure
pour fonctionner. Dans
l'écosystème amazonien, on
appelle cela une instance EC2.
C'est une machine virtuelle
qui a une certaine quantité de
CPU et une certaine quantité
de mémoire disponible.
Maintenant, en ce qui concerne le modèle
de déploiement, lorsque
vous avez une application,
vous avez une instance EC2
et, à l'intérieur, vous avez
Mule, le temps d'exécution de Mule.
Et vous n'aurez qu'une seule application
par élément d'infrastructure.
La raison en est de garder le modèle
de déploiement simple, et cela facilite
un peu les choses comme la
maintenance et le support,
car si cela tourne mal, la
seule chose qui le fait,
c'est l'application.
Ensuite, afin de soutenir
les déploiements avec ou sans

German: 
MuleSoft
Technische Einführung in
Mulesoft. Bereitstellen und
Verwalten von APIs
- Hallo, in dieser
Lightboard-Sitzung werden wir
über CloudHub-Architektur sprechen.
Mule ist also ein Anwendungsserver.
Zum Betrieb ist eine gewisse
Infrastruktur erforderlich.
Im Amazon-Ökosystem wird dies
als EC2-Instanz bezeichnet.
Das ist eine virtuelle Maschine,
die eine bestimmte Menge an
CPU und eine bestimmte Menge
an Speicher zur Verfügung hat.
Was das Bereitstellungsmodell
betrifft, haben Sie,
wenn Sie eine Anwendung
haben, eine EC2-Instanz
und sitzen darin, dass Sie Mule haben,
die Mule-Laufzeit.
Und Sie haben nur eine Anwendung
pro Infrastruktur.
Der Grund dafür ist nun,
das Bereitstellungsmodell
einfach zu halten,
und es macht Dinge wie Wartung und Support
ein bisschen einfacher,
denn wenn dies schief geht,
ist das einzige, was
es tut, die Anwendung.
Als nächstes haben wir einen
Load Balancer vor dem Client,

Portuguese: 
Implementação e Gerenciamento de APIs
- Oi, nesta sessão de Lightboard,
vamos falar de Arquitetura CloudHub.
Mule é um servidor de aplicações.
Ele precisa de infraestrutura
para poder rodar.
No ecossistema da Amazon, isso
é chamado de instância EC2.
É uma máquina virtual que tem
uma certa quantidade de CPU
e uma certa quantidade
de memória disponível.
Quanto ao modelo de implementação,
quando se tem uma aplicação,
temos uma instância EC2
e dentro temos o Mule,
o tempo de operação Mule.
Você terá apenas uma aplicação
por parte de infraestrutura.
A razão disso
é para manter o modelo
de implementação simples,
e faz com que coisas
como manutenção e suporte
fiquem mais fáceis pois se algo dá errado,
só vai dar errado na aplicação.
Agora, para interrupção de suporte
ou para zero interrupções
de implementação, ou seja,

Japanese: 
- 今回のライトボードセッションでは
CloudHub Architectureについてお話します
Muleはアプリのサーバーです
それにはインフラが必要です
アマゾンのエコシステムでは
それをEC2インスタンスと言います
CPUと容量がある
バーチャルの機械です
デプロイメントモデルとしては
アプリがあれば
EC2インスタンスがあり
Mule内にそれがあります
Mule ランタイムですね
インフラ1つにつき
1つのアプリです
理由は
デプロイメントモデルをシンプルにして
メンテナンスサポートを容易にします
もしおかしくなれば
その要因はアプリになります
次にサポートダウンか

Spanish: 
Introducción técnica a MULESOFT
Implementación y manejo de las API
- Hola, en esta sesión con
ayuda del tablero lumínico
vamos a hablar sobre la
arquitectura CloudHub.
Mule es un servidor de aplicaciones.
Necesita de infraestructura
para funcionar.
En el ecosistema de Amazon,
se le llama una instancia EC2.
Es una máquina virtual con
cierta cantidad de procesadores
y cierta cantidad de memoria disponible.
Ahora bien, en cuanto al
modelo de implementación,
cuando tienen una aplicación,
tienen una instancia EC2
y en el interior está Mule:
el tiempo de ejecución de Mule.
Y solo tendrán una aplicación
por cada pieza de infraestructura.
Ahora bien la causa de esto
es tener un sencillo
modelo de implementación
que hace que funciones como
el mantenimiento y el soporte
sean un poco más fáciles
porque si esto se descontrola,
lo único que lo hace es la aplicación.
A continuación, para
apoyar las implementaciones
de tiempo de inactividad cero,

English: 
(upbeat music)
- Hi, in this Lightboard session,
we're going to talk about APIkit router,
and how it works with your API definition
to produce some of your implementation.
So you've gotta start with a spec,
but if you don't start with a spec,
you can retrofit things later,
but it works best if you start with a RAML
or OpenAPI spec or OpenAPI,
also known as Swagger.
Now the APIkit can be
invoked as part of creating
a creation of a project, so
when you're in studio, you say,
here is my API spec.
Now you've got options
for where this comes from.
The best option in my
view is to go to exchange
because that's where you've shared it,
so that it's discoverable and
documented for other people.

French: 
temps d'arrêt, c'est-à-dire
des déploiements sans
interruption, nous avons un
équilibreur de charge placé
devant le client, où qu'il se trouve.
Ainsi, le client parle à
l'équilibreur de charge, parle sur
le port 443 pour HTTP
et le port 80 pour HDDP.
Ainsi, pour le HTTPS, le port
443 va passer sur le 8082 et
le 8081 est le port pour le HDDP.
L'équilibreur de charge va
maintenant s'assurer qu'il
transmet la requête au port approprié.
Et c'est pourquoi vos
applications doivent être écoutées
sur le port 8081 ou 8082.
Maintenant, pensez au
scénario dans lequel vous avez
une nouvelle version de votre
application à déployer, ou
vous avez un changement de
configuration. Maintenant,
plutôt que d'appliquer ces
derniers par-dessus le serveur en
cours d'exécution, ce qui
entraînerait une panne, la façon
dont le CloudHub orchestre
vos déploiements est de faire
tourner une nouvelle instance
de EC2 avec une nouvelle
version de Mule, nouvelle
version de votre application.

German: 
um Bereitstellungen ohne Ausfallzeiten
oder ohne Ausfallzeiten zu unterstützen,
also Bereitstellungen ohne Ausfall.
Der Client spricht also
mit dem Load Balancer,
über Port 443 für HTTP
und Port 80 für HDDP.
Für HTTPS wird 443 auf 8082 gehen
und 8081 ist der Port für HDDP.
Jetzt stellt der Load Balancer
sicher, dass die Anforderung
an den entsprechenden
Port weitergeleitet wird.
Aus diesem Grund müssen
Ihre Anwendungen Port
8081 oder 8082 überwachen.
Stellen Sie sich nun das Szenario vor,
in dem Sie eine neue Version
Ihrer App bereitstellen
oder die Konfiguration ändern müssen.
Anstatt diese über dem
laufenden Server anzuwenden,
was zu einem Ausfall führen würde,
koordiniert CloudHub
Ihre Bereitstellungen,
indem eine neue EC2-Instanz
mit der neuen Version von Mule,
einer neuen Version Ihrer
App, gestartet wird.

Japanese: 
ゼロダウンタイムデプロイメントを実行するために
停電無しで
顧客がどこにいようとも
その前に
ロードバランサーがいます
顧客がロードバランサーと話
HTTPへのポート443やHDDPのポート80ですね
HTTPS 443は8082にいき
8081はHDDPのポートです
ロードバランサー
正確な場所にリクエストを送ります
なのでアプリは8081か8082を
聞かなくてはいけません
新しいアプリを
設置しなくてはいけないと考えてください
あるいは構成を変えるか
ランニングサーバーに適応させるより
それは停電を引き起こします
CloudHubは設置を開始する方法は
新しいEC2インスタンスを回転させます
新しいMuleバージョンや
アプリのバージョンで

Spanish: 
o sea implementaciones sin interrupciones,
tenemos un equilibrador de carga
frente a donde sea que esté el cliente.
El cliente se comunica con
el equilibrador de carga,
utiliza el puerto 443 para
HTTP y el puerto 80 para HDDP.
Entonces, para HTTPS, 443 irá a 8082
y 8081 es el puerto para HDDP.
El equilibrador de carga garantizará
que la solicitud se
envíe al puerto correcto.
Y es por eso que las
aplicaciones tienen que escuchar
en el puerto 8081 o en el 8082.
Ahora, imaginen el caso donde tengan
que implementar una nueva
versión de la aplicación
o tengan que cambiar la configuración.
En lugar de aplicarlos por
encima del servidor en ejecución,
lo que provocaría una interrupción,
la forma en que CloudHub
organiza sus implementaciones
es creando una nueva instancia EC2
con una nueva versión de Mule,

English: 
So you're going point to
those in your, in exchange.
And then there is a generation process
which will scaffold some
parts of your implementation.
Now your implementation is gonna have to
listen for inbound requests,
so that's the first part
that it spits out.
It's got your top level listener set up
where it's listening under
/api/*, so that's our main flow.
It'll have a slightly longer name,
but essentially it's the main flow.
Now, the other thing that is quite useful
from a developer's
perspective is having the spec
where they need it.
So there is another part which is created,
which is the API console,
which is documentation.
So it's listening on console/*
So these two flows give
you the entry point
into your application
and the documentation
so that you've got a local copy
without having to go to exchange
or fire up something separate.

Portuguese: 
sem interrupções, temos um
balanceador de carga na frente
de onde o cliente estiver.
Então o cliente conversa
com o balanceador de carga,
fala na porta 443 para
HTTP e porta 80 para HDDP.
Para HTTPS 443 vai para 8082,
e 8081 é o porto para HDDP.
O balanceador de carga vai fazer
ele passar a solicitação
para a porta adequada.
Por isso suas aplicações precisam ouvir
na porta 8081 ou 8082.
Pense em um cenário em que você tem
uma nova versão do seu
app para implementar,
ou mudou a configuração.
Em vez de aplicar isso
por cima do servidor,
que causaria uma interrupção,
o jeito que o CloudHub
orquestra suas implementações
é criando uma nova instância EC2
com uma nova versão do Mule,
uma nova versão do seu app.

English: 
Now, the business end of
this, which is your method
and resource combinations that
you've defined in your spec.
Now, for each of those,
there is going to be some
magic routing mechanism that
happens in this main flow
that we'll call a placeholder flow.
So down here further,
we've got our various ones
which will correspond to
whatever operation you've got specified.
So you'll find that for the
resource method combinations,
you'll see those in the names,
the forward slashes will be
turned into back slashes,
but essentially you'll have for
whatever operations you have
and whatever resources you have,
you'll find that there is a corresponding
flow down the bottom
of the generated code.
Now what APIkit router does
is will validate the inbound request.
It will validate the inbound request
and then call one of these
based on detecting the path

Spanish: 
o sea, una nueva versión de la aplicación.
O podría ser la misma.
Puede que solo estén
actualizando la aplicación
y no la instancia de Mule.
Puede ser que evalúen la
instancia de arriba a abajo.
En ese caso, eso desencadena
este mismo tipo de
modelo de implementación.
Ahora bien, cuando esté
activa y escuchando,
se agregará al equilibrador de carga.
Y luego, durante muy poco tiempo,
tendrán dos instancias de la aplicación.
Luego quita la original.
Esta sale de la ecuación y solo queda
la nueva instancia
manejando las solicitudes.
Y así es como, incluso
con solo una trabajando,
acaban con implementaciones
de tiempo de inactividad cero.
Y así es como CloudHub
organiza las implementaciones.
Y ese es el modelo de implementación
de la aplicación para
Mule y la instancia EC2.

German: 
Oder es könnte dasselbe sein.
Möglicherweise aktualisieren
Sie nur die Anwendung
und nicht die Mule-Instanz.
Es kann sein, dass Sie die
Größe der Instanz vergrößern
und verkleinern.
In diesem Fall wird dieselbe Art
von Bereitstellungsmodell ausgelöst.
Wenn es jetzt aktiv ist und zuhört,
wird es dem Load Balancer hinzugefügt.
Und dann haben Sie für einen kurzen Moment
zwei Instanzen mit der Anwendung.
Es nimmt dann das Original heraus.
Das geht also aus der
Gleichung heraus und Sie haben
nur noch die neuen
Instanzbehandlungsanforderungen.
Auf diese Weise erhalten Sie
selbst mit einem Mitarbeiter
keine Ausfallzeiten.
Und so orchestriert CloudHub
die Bereitstellungen.
Und das ist das Bereitstellungsmodell
Ihrer App für die Mule
to EC2-Instanz.

French: 
Ou bien ce pourrait être la même chose.
Vous pouvez simplement
mettre à jour l'application
et non l'instance de Mule.
Il se peut que vous ayez
modifié la taille de l'instance.
Dans ce cas, elle déclenche ce même type
de modèle de déploiement.
Maintenant, lorsqu'elle est
à l'écoute, elle sera ajoutée
dans l'équilibreur de charge.
Et puis, pendant un
bref instant, vous aurez
deux instances avec l'application.
Elle retire alors l'instance originale.
Cela sort de l'équation et
il ne vous reste plus que
la nouvelle instance
qui traite les demandes.
Et c'est ainsi que, même avec
un seul travailleur, vous vous
retrouvez avec zéro
déploiement de temps d'arrêt.
Et c'est ainsi que CloudHub
orchestre les déploiements.
Et c'est le modèle de
déploiement de votre application
Mule to EC2 instance.
MuleSoft

Japanese: 
同じ場合もあります
アプリをアップデートするだけです
Muleインスタンスではなく
サイズを変えることもできます
その場合
同じ設置モデルを引き起こします
それが引き上げられ
理解されれば
ロードバランサーに加えられます
ほんのつかの間
アプリで2つのインスタンスができます
オリジナルがなくなります
イクエーションが取り除かれ
リクエストのある
新しいインスタンスになります
これが1人出会っても
ゼロダウンタイム設置です
これがCloudHubがいかに設置を行うか
EC2インスタンスに向けたMuleアプリの
設置モデルです

Portuguese: 
Ou pode ser o mesmo.
Talvez só esteja atualizando o app
e não a instância Mule.
Pode ser que esteja medindo a instância.
Neste caso, ele provoca
o mesmo tipo de modelo de implementação.
Quando estiver implementado e ouvindo,
ele vai ser adicionado
ao balanceador de carga.
E por um breve momento,
você terá duas instâncias com a aplicação.
Ele então tira a original.
Isso sai da equação e você fica
com apenas a nova instância
lidando com as solicitações.
E é assim, mesmo com só um trabalhador,
você terá zero interrupções
de implementação.
E é assim que o CloudHub
orquestra as implementações.
E esse é o modelo de
implementação para o seu app
para o Mule, para instância EC2.

English: 
and the method that
you're feeding in, okay.
So it validates request,
now by validation,
it validates the URL
that you're feeding in,
it also validates any input
parameters, so query parameters,
headers, a body, so if you
were doing post or put patch,
so it'll validate the, URL side of things,
any inputs, and if any of those
fail your validation rules,
it will then throw an error.
So it doesn't get to this point down here.
So it takes away having to
do all of the validating
of the fields, all of
the validating of the URL
and the routing logic, okay.
So, and that's how APIkit works
to make your implementation
a bit easier if you've got a spec.
(upbeat music)
