Panel: Elixir Adoption
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 11 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/37895 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produzent | ||
| Produktionsjahr | 2018 |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
EMPEX LA Conference 20182 / 11
2
3
5
6
10
00:00
Selbst organisierendes SystemCASE <Informatik>Große VereinheitlichungMAPFormale SpracheBeweistheoriePrototypingProjektive EbeneComputeranimationVorlesung/KonferenzBesprechung/Interview
02:03
MultiplikationsoperatorProjektive EbenePerspektiveAussage <Mathematik>SoftwareentwicklerDatenverwaltungFormale SpracheErlang-VerteilungZahlenbereichResultanteTelekommunikationKartesische KoordinatenKeller <Informatik>Web-SeiteFehlermeldungCASE <Informatik>RichtungMereologieProdukt <Mathematik>UmwandlungsenthalpieLesezeichen <Internet>SoftwarewartungAnnulatorGüte der AnpassungNichtlinearer OperatorSkalierbarkeitEntscheidungstheoriePrototypingMinkowski-MetrikWidgetSoftwaretestVollständigkeitFront-End <Software>MultigraphRechter WinkelTermDatenstrukturSelbst organisierendes SystemParametersystemFramework <Informatik>PunktKomplexe EbeneSchnittmengeExogene VariableWeb SiteGraphCodeSI-EinheitenInteraktives FernsehenFormation <Mathematik>Vorlesung/KonferenzBesprechung/Interview
08:40
Kartesische KoordinatenMigration <Informatik>DatenstrukturFront-End <Software>DatenverwaltungApp <Programm>KonfigurationsraumMereologieSummengleichungProgrammbibliothekEinsVariableProdukt <Mathematik>Erlang-VerteilungEndliche ModelltheorieBitPhysikalisches SystemNichtlinearer OperatorMultiplikationsoperatorPolygonnetzFramework <Informatik>ProgrammierumgebungPunktDebuggingGebäude <Mathematik>ZahlenbereichVorlesung/KonferenzBesprechung/Interview
11:15
Zusammenhängender GraphComputerarchitekturBroadcastingverfahrenMessage-PassingInverser LimesEndliche ModelltheorieNatürliche ZahlErlang-VerteilungEinfach zusammenhängender RaumDatenverwaltungPhysikalisches SystemDistributionenraumVorlesung/KonferenzBesprechung/Interview
12:31
Response-ZeitDatenverwaltungKartesische KoordinatenDatenparallelitätQuick-SortPunktPaarvergleichEndliche ModelltheorieZahlenbereichSoftwareentwicklerFormale SpracheNetzbetriebssystemMultiplikationsoperatorMultiplikationSoftwarewartungKontextbezogenes SystemAppletKonditionszahlAnalytische MengeProdukt <Mathematik>Rechter WinkelTermBefehlsprozessorComputerarchitekturCodeDatenbankFehlermeldungMultigraphGarbentheorieCompilerSelbst organisierendes SystemMAPApp <Programm>SpeicherabzugMicrosoft dot netThreadVorlesung/KonferenzBesprechung/Interview
18:38
DatensatzCOMXML
Transkript: Englisch(automatisch erzeugt)
00:07
So we're going to go through some main topic questions and then I'll be going down into the audience and picking up questions for the panel. Anything that you might have, I'll be running down. So first question for each of you. How did you get started with bringing Elixir onto
00:25
your projects? And did you do that first by getting a bunch of buy-in from the team or did you do prototypes, proof of concepts on your own? Brandon? Sure. So the way that we started bringing Elixir into our organization was at the level of getting buy-in. So starting off,
00:48
you really need to, like you can't just be the only person at your organization trying to say like hey let's go use this new thing because it kind of looks like you're trying to chase down a fad or you know you can get that kind of immediate gut reaction to that. So we actually
01:06
started through just kind of introducing Elixir and some of the like little nice aspects of the language or the VM that it sits on to basically get more people interested so that when we wanted
01:22
to make our case for it, we had kind of a unified front to be able to make that case. Yeah and in my case it was very similar. We approached the problem from the point of we're going to need to rewrite this tech stack. That was the first agreement that we all reached.
01:41
It was like things have gotten too complicated. We can't just iterate on this. It's best to tear out chunks and start anew. And once we agreed on that and we were on a PHP stack, the question got opened up of like oh are we open to just doing it in a different language if we're less comfortable working in PHP than in something else. And that's how the
02:06
Elixir question got brought up and that's how Elixir got in my case compared to a couple of other languages in terms of what would be most suitable for the organization. What did your first prototypes look like when you were getting that started after VIA?
02:21
Yeah we started off with an Autosuggest prototype which is the automatic completion on the search widget which is on every page of our website. And I think that was a really important move for us for a couple of reasons. It was like a real part of the application. It gets live
02:43
production data. It's like a fully fleshed out part of the ecosystem. And none of our directly. So it gets real traffic. But there's no dependencies. There's no like weird other like failure cascades that we could cause with picking Autosuggest. So that's like
03:02
what made it an ideal candidate for us to try it out. In our case we had an API that was dealing with basically large sets of data that our customers were requesting. So we had essentially a set of test cases that we wanted to verify that like any request coming into this one
03:25
particular endpoint it actually should be transparent to those users whether or not it's getting routed to our Ruby application or our Elixir application. The nice thing about that is through automated testing and a couple of other tricks we were actually able to
03:41
verify that the results were going to be identical in almost every scenario. Which allowed us to just slowly introduce just a single endpoint only written in Elixir and Phoenix that was actually routing traffic at you know small percentages at first
04:00
but we kept ramping those numbers up to see like okay is this going to introduce new errors new scenarios that we have to handle and over time we built that just that one endpoint up to a 100% replacement from our Ruby stack into our Phoenix stack and the users no one had any idea that anything had changed other than their responses were suddenly getting served back a lot
04:25
faster. So how do you make the pitch when you're going for the buy-in? How do you make that pitch to other developers coming from different backgrounds who have no idea what Elixir is? Often they don't and is that different and how is that different when you're pitching to
04:45
non-developers if you're pitching to management if you're pitching to you know somebody who has authority but isn't necessarily working with the code? Yeah so I mean I want to start with the pitching to management part of it. That's very I think dependent on what your individual organization structure is and kind of how it
05:06
works if if your Elixir technology decision makes sense on the back end has a lot to do with like how much like kind of trust and good faith there's been built up in engineering to be able to like make that decision in how much space you've got to just like navigate
05:28
without getting it too much into the nitty-gritty details and also with like how you're able to explain or how much risk mitigation you need to be able to explain to managers saying like oh well yeah maybe Elixir is like a really new language so that's a risky proposition but it's
05:46
built on the Erlang framework and that's been around for I don't know how many years now 30 something 40 something. Yeah so I think those are like the compelling arguments upwards. To
06:04
think about Elixir other than it worked with Erlang and now I'm here. So from the developer perspective we actually one way that we found work actually very well was doing lunch and learns. So our company was already had already had a concept of
06:26
brown bags and lunch and learns and things like that where you would just present on something it might be related to something in your main tech stack or it might be something just radically different you know we've done things on GraphQL but didn't actually have any GraphQL in our code
06:43
base. So it was already kind of a nice opportunity to say like hey I'm just gonna show this here and if you like what you see you know maybe maybe reach out to me maybe we'll talk about some side projects that we could explore and over time
07:01
developers kind of naturally see the value of being able to avoid immutability and you know working with the the pipeline operator is basically everyone's favorite feature when they first start off is like oh okay I could just write it like this is great I yes I want to do this everywhere which is why you know there's proposals for a pipe operator in JavaScript now
07:22
proposals for a pipe operator in Ruby and I'm sure like everything is trying to do it now but then from the manager perspective now that you've kind of got developers excited about something and you want to do that is anyone in here had to do a lot of communications with upper management
07:43
sorry what's up okay yeah and you have to use graphs Elixir and Phoenix lend themselves very nicely to graphs whether it's up and to the right for you know how many requests you can serve at the same time or if it's your cost graphs where things are going down because
08:04
maintenance is easier scalability is easier a lot of things are handled in a nice way so both of you we talked about where you started and obviously Elixir has grown on all those projects were there specific problems or pain points that you guys encountered that your teams
08:22
encountered as you're going from oh it's the side project that we're starting on to you know taking over 100% of the API or things like that okay so I would say something probably a lot of people are in here have run into
08:41
configuration and deployment were kind of the two major ones so just okay we got this into production we want to use environment variables to set different configurations like the pool timeout in pool boy which was especially a headache for us of trying to figure out okay
09:03
well this is an Erlang library that we need to configure we need to configure it at runtime but we're not recompiling this every single time we want to do a deploy so how do we manage that like we want to be able to change these variables on the fly that was I think probably
09:20
one of the biggest things we ran into and it wasn't a blocker it didn't stop us but it definitely was a little bit of a headache for a while yeah for us we had similar issues which we had a convenient solution to which is we had built out a deployment framework for the front-end migration part of our work which we migrated from php front-end to node
09:44
and we were using kubernetes for that and ops work ops team had to put in a lot of work into building that out so that was kind of our solution to the deployment issue but we a couple of the three points that like remained and we still have some questions about our how do we manage elixir releases versus like Erlang application releases versus the dockerized
10:07
approach like how do we balance that because we don't need slash can't use a lot of the power of like the Erlang like uptime guarantees and the distributed Erlang systems when we're in this dockerized world another is the totally blanking the the time when you move from a
10:32
like big chunky application to the umbrella app structure that's kind of what we're wrestling with right now we've got this like large relatively complicated api back end and we're
10:43
evaluating like what's the right move there and like how does the umbrella app model mesh with what we're trying to do all right do we have questions about adopting electric elixir getting elixir on team from anybody outside right now
11:18
yeah the question is just you mentioned that there are some limitations when you
11:23
deployed on a docker architecture and i'm just curious about the nature of those limitations yeah so elixirs or sorry Erlang rather is very opinionated on it's how nodes should be communicating with each other in the distributed Erlang model and it wants you to to have these
11:45
nodes that are like to manage the connections through the the like node supervisor model and with kubernetes really it's the like the the kubernetes supervisor or not supervisor the kubernetes pod manager and scaler is taking care of that aspect of it so it's been
12:05
tough for us to find like sometimes there's a problem that we see oh we want to be able to broadcast this message to all of our nodes we don't have the distributed Erlang system set up it doesn't really make sense for it to be set up given that we've got the kubernetes
12:21
architecture so now we're bringing in the third technology component to manage that broadcast as opposed to just keeping it entirely in Erlang any other questions what is the oh sorry was there somebody hi so you guys mentioned upper management and
12:43
i'm sort of a mole in upper management here but i came from lots of engineering backgrounds so i'm actually one of the people in the company that is trying to push this forward one of the things that i find challenging is that when you guys talk about stuff like um it's easy to show like the nice graphs of response times or number of requests per second
13:08
a lot of stuff that i hear in the community is like we went to elixir because it was way faster than ruby right or rails and it's really easy to to talk about that comparison
13:20
i come from a giant company that we use lots of other things that are not slow um or not implicitly pretty slow so it's for me it's harder to make the the same sort of comparison to something like java or golang or dotnet core or something like that which perform pretty well so i'm curious what your thoughts are on you know trying to convince
13:44
people like me about how fast phoenix is when there's lots of other things out there that are fast yeah um so if i were if i'm evaluating against something that uh kind of has like a stigma
14:00
attached to it of you know how are you going to scale this application after a certain amount of time that becomes kind of an easy comparison point when it's something that is a much more established technology like if you're sitting on top of an entire uh java stack that has been incredibly optimized and you've really gotten that performance tuned down that actually may not be
14:23
where i would focus my intent my attention because there are other significant benefits the biggest one in my mind is having that guarantee of immutability and how that affects how much time developers and i apologize because i'm kind of putting on my manager hat here
14:43
but how much time developers are spending working on fixing issues that get introduced and how much of that time pops up how much of that impacts customer experience or stakeholder experience and what kind of like long-term costs that that actually introduces versus
15:05
something where i can actually make some level of guarantees whether it's through what the compiler gives me or what the benefits of an immutable architecture gives me or what the benefits of a functional architecture gives me in terms of you know how much time my developer
15:22
is spending just working on code and adding value and doing better things for our company versus trying to trace down some really weird locking issue or race condition that we have no way really to like dive into without taking you know at least one senior resource probably
15:42
multiple non-senior resources and people like just dedicating themselves for i've had an experience where it took two months just to track down one race condition that's a lot of lost time that's a lot of lost effort and it's also a big missed opportunity for things we
16:01
could have been doing to add value to the company so that cost is actually like double what it is yeah i've got a very similar answer i think just the if so yeah the context is super important if you're you're gonna have to go into this assuming that you're coming from a place
16:20
of many architectures because if you're if you're already using one general purpose language c++ or or java or go or whatever or even two like maybe you have python for a lot of your data science stuff or analytics or something or uh or scala or something then maybe it doesn't make sense to to use elixir i think the killer feature is yeah the concurrency model is
16:44
it's done it's solved for you it's baked into the language it's in everything that's in the language you don't need to debug it there's a it takes a while maybe to learn the idiomatic way of doing things right in elixir so that is a that's an educational cost to your company to your
17:03
developers um but yeah historically uh in the many years i had before i was working with elixir the hardest problems to debug are the p thread gone wild or why am i never entering or always in this critical section um and so just yeah that like that itself has been great i think
17:25
there's another benefit too of uh it's simple uh not to say that it's easy but it is simple sometimes it's so simple it's it's hard to like uh to to figure out how you get to do
17:41
what or how you can do what you need to do with it um but it's a great like learning tool i think i've been very surprised with how quickly a lot of the junior engineers at the organization have picked up elixir and are just like rolling with it and like really learning these uh like the actor model kind of intuitively uh i just one very quick anecdote
18:03
um we actually had an elixir app that was running in production that we actually forgot about because nobody had to maintain it it was doing exactly what it needed to do and it was never exceeding like one percent cpu so we literally forgot that it was running in production until we had that database go down for maintenance and started seeing a bunch of error messages
18:24
pop up in our log aggregator thank you very much shanti brandon that's the end of this panel and we'll move on to deployment