Go Circuit, un PaaS (Platform as a Service) programable

Extracto de la transcripción automática del vídeo realizada por YouTube.

I'm going to talk today about a tool that allows you to write distributed applications more more easily than before and if you've read the abstract from the confidence page it's a little bit also have an open mind as you always should so before

I even get into talking about distributed applications I want to fit some all right excellent so haha ways to build distributed applications but before we even start I want I want you to have a visual of what i mean by ID so so this illustration is just so

you have a visual of what i mean by distributed application we have three things at play here one is the black circles are the host that you have available to your application the white circles are the unix processes that comprise your application and the

lines are obviously TCP connections that you use and distributed control is an abstract term that we're going to define over the course of the talk which means the primitives that you need inside your application so you can expressively and easily write

big complex distributed applications the abstract definition that I like to use is the ability of one application process to affect and be affected by the others so we're talking about the application processes in your distributed application so for now

just keep this picture in your head and and let me tell you the story how all of this sort of got started um I started sort of thinking about what are the how do people currently do these tubular applications how do they build them and I came to the conclusion

that there's in the ecosystem of open source today there's basically two kinds of distributed applications the first kind is the one that i call my just for having some terminology i say the distributed control is outside and a good example of this

is a distributed mysql database so in this in this model what happens is that you get um you get an executable so in this case this would be the minus q executable which has a very rich and very complex configuration sort of file configuration parameters that

you have to give it before you can start it and so by by essentially coming up with a complex configuration you can actually get up a mysql cluster to do whatever you wanted to do for you unfortunately in order to get this whole thing to work you sorry mysql

wouldn't work out of the box you actually have to do some work into writing this complicated configuration files and nowadays you have nice tools like Papa Jeff and zookeeper and whatnot which would sort of make it a little bit easier for you but unfortunately

as a whole this process is quite complicated um and it's and it's sort of difficult for two reasons first of all the the black color in this picture represents the two places also show you represent essentially the places where a programming involvement

is needed before you can have the distributed application actually be running so the MySQL black boxes represent the programming that the authors of MySQL presumably programmers it you know MySQL incorporated so first I have to actually implement MySQL but

the black stuff that's outside of the puppet chef and new zookeeper is represents the programming effort that the user which is typically some internet company in more specifically the death the deft Devon engineering team other ops engineering team they

also have to do a lot of programming to actually get this whole thing to run and unfortunately this is not even the end of the story while tools like poverty and chef Anne and whatnot other orchestration to allow you to kind of get a handle on the configuration

files software is written in like minus QL is extremely difficult to manage when in response to unexpected external events like a shard dying and so forth and in fact Facebook has notoriously spent a humongous amount of work to automate for example the recovery

from a shart so this is the old school type of distributed applications which are probably here for historical reasons mostly in the current dying away the new the new type of distribute applications which include my favorite example is idb but there's

a lot of others they tend to come also in the form of a single executable but you can run them in you can deploy them in the most sort of mindlessly simple way you're supposed to just run them on all the computers that you have available point them to

each other there is no configuration for the most part that you can play with and and then these systems which have all the control of the decompressed CT of distribution inside they take care of everything so for example ciety be you know it's very simple

to run you just run it on however many machines you want and you can even you know asynchronously later on add another machine start another processing pointed to the existing cluster and everything works near oculus li and you know including shout recoveries

side we will do everything for you which makes sense because the people who manage the sustenance of the running distributed software shouldn't be expert on on what to do when a chart has to be replaced in particular for example with MySQL lots of teams

in internet companies and specifically the CC administrators which are not even necessarily database specialist they have to they have to learn how to deal with the multiple steps that they need to take to consistently recover from a MySQL shot and it's

not their expertise so that's actually a human resources problem in creddin tirely because of software structure so sit so the second kind of applications like julia DB is obviously what's the future and people keep making more and more applications

[ ... ]

Nota: se han omitido las otras 2.846 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.