Michael Schaefermeyer - Buildings start-ups with Elixir | Code BEAM STO 19

Chifa Maya name gives it away the excellent light - I'm from Germany Minster Germany to be exact I'm currently head of business development at slight arc EMB ha which is also very German name and I'm also there to talk about technical things at the company formerly I started the elixir career basically a bleacher report where I was fortunate enough to be spare heading some projects in elixir because I was a pretty good answer at the time for some of the technical challenges that we faced and then I got lucky again because one of the heat report calendars asked me whether I wanted to be part of a new company that we started together and that was in verse calm and not surprisingly yes yes I think being having the opportunity to being part of something from the very start and having a big say in how we want to do things is an opportunity that you can't really pass up on and that's what I've done for the last three years I'm also gonna try to relax my arms and a little bit nervous so I'll be doing this a lot so if I've been with inverse for three years and we used elixir there for everything that didn't need to run in the browser I'm still waiting for the time where I can take that over as well with elixir and looks like with Phoenix life view we have an le into that but yeah we have we had a bunch of different services I'm going to talk about them in a bit a little bit too and they were basically all in elixir and the basically it's also something I want to touch on I am also a father and that has what changed my career path a little bit because I was working for San Franciscan companies out of minister germany which worked really well at the time but as as soon as my son was there I kind of wanted to be back in Germany full-time and not having to travel on a frequent basis so last year I helped friends with that company builder lap 25 where I was fortunate enough to be able to pop star some companies with them as basically an interim CTO and then since beginning of this year like I said I'm Becca slight arc we have ventures there as well and we also using elixir for customer projects so I talked us more for agency are doing customer projects but we also because that helps startups so that's our I also like to dive I figured I put one not professional note on this slide I'm really like to scuba dive so with the tank on my back what cool yeah let's start with retz let's start with the drawbacks of using elixir for startups and they are a few and one of them is authentication it's if you follow discussion around elixir and Phoenix on the elixir forum this is probably not the first time you'll hear this there are authentication libraries out there let me start with us with that and they are really really good for the purposes that are they were built for unfortunately those purposes a lot of times and a lot of companies or in a few of the companies that I was able to be part of from the get-go those priorities didn't really align with what we were trying to do with authentication for those companies well the sorry one of the reasons is that the probably I don't have stats but probably the most beloved authentication library Guardian which is really good it's built on JWT and JWT is great when you want to authenticate against different services especially if those services don't have access to your main database or when they are not if you don't want to have these services talk to like a central authentication service a JWT is great for that because it allows you to verify that a user is locked in and that he is who he wants to be everywhere without having like I said access to the main data store it's not so great if you want to have sessions that can be revoked JWT and in itself and have a concept of revoking tokens so you normally give it an expiration time and after say a day or two or now whatever you specify the joke token is no longer valid and you need to obtain a new one that's that didn't really fit too well with what we were trying to do where we wanted to have a user be able to just lock out and then be locked out not anybody else being able to use his session again and Guardian allows you to do that with Guardian DB where they track which tokens were issued and then if a token was revoked they store that in the database but that kind of defeats the purpose of JWT to start with and they are very vocal about that so this is not something that they hide if you go to the Guardian DB github page they are very open about jelly abilities are not really being there to expire hour sessions and coherence is kind of the same they don't use JW tees they have sessions if you use rememberable on coherence but it's their own data structure around sessions and what I really needed were sessions that store more information than just I'm a session I needed browser block in time current location but also potentially things like what version of an app was using that sessions and that's that's more than just authentication you start storing more information on this session than just that and that's where those authentication libraries at least in my experience and again I ask everyone to raise their hand and dispute with me I have a dispute with me but at least in my experiences vent occasionally Burris didn't work really well for that which is a very specific purpose that I was trying to use them for that didn't work too well I hope I said often TK ssin because now I'm talking about authorization and always mix these two up that's why I used all-star to just the second part is authorization and there's not really like a go-to way at least not one that I've found to specify what a user can do in your system in Phoenix I ended up using contexts for that a lot so that within a context when you wanted to say list projects that you worked on it checked what user was locked in and then figured out what projects that user had access to but it was always a very like self rolled way of handling the connection between persons users whatever and the resources that they should have access on and what kind of access they should have on and I've also worked a lot with Ruby on Rails a lot of the comparison that I'll draw will be with Ruby on Rails I'm sorry about that and in Ruby we have pandit which just gives you a nice wrap around specifying or it just gives you a nice way of specifying what a specific user can do and you can do that on per user basis and you can do that on a group basis and stuff like that and again authorization is kind of their guardian you can add permissions to user which then will get added to the JWT and you can write what he can cannot do but it's just information so there's no link there with your source code and your models we also experimented with third-party authentication services there's AWS kognito there is google firebase and I just realized that I don't have my moderators notes on here but I'll just swing it and there's also zero and they abstract all of that away from you and authentication will be a pain to manage yourself so that's an option but I didn't find it to be a great one because you're giving a very crucial part of your application away and you're trusting somebody else to keep your user data safe and that always kind of felt a little bit weird to me but it's an option and I'll motivate while all of these things are important for startups and a little bit admin backups I was afraid that I didn't have enough content but now I look at the time I see I'll have to speed this up a little bit admin beckons another thing there are when becos beckons in alexia for Phoenix others exciseman and for the second one fall or something and except Minh looks pretty good but there is still things that we weren't really able to do that we would have been able to do with say active admin or in Python with Django you actually have a plan that gets built in and I think that's fairly crucial because building admin backends they don't have to be pretty so that's different from the rest of your application if really just your own companies using them they can be a serious I want to be and that's the fact if you are using the Django admin it looks horrible but it works and it's there and that's a big plus if you're starting a company not having to build your own admin beckons so that's something that I and with X admin they have a DSL to describe what you want to administer and how but we didn't it wasn't flexible enough for us so we always ended up with two companies I started we ended up rolling around and econds and sometimes we had Google Spreadsheets as admin backends which is horrible but it was the fastest way of getting there and that's something that you might want to consider when building a startup another thing that used to be a big issue for us with monitoring so even when you get started it might be a good idea to see what's going on especially when you get started you have the unique opportunity to measure exactly how your app performs on probably low note and that's so you want to have as much insight as possible to know what what you have to change and optimize and that was a very involved process in the past I actually rode a medium post that kind of took off after my last conference talk on measuring Phoenix applications with XO meter and that works really well academia is a great library but it's also super involved and yeah but you have to kind of understand how extra meter works before you can really put it interpret or you can copy and paste the code that I wrote in the medium post but it's not really what you're trying to achieve for that and then you still have to figure out okay know that you collected the metrics what are you what do you want to do with them do you want to export them to stats D and just use the service to display them do you want to ship them somewhere else again I encourage you I will have a Q&A at the end by encourage you to say this is it's easy to measure and this is how we done it I be happy about that I think what's Pinterest my elixir meter which was like a lik sim wraparound EXO meter we've played around with that a little bit but I didn't really work for us they had a master branch that wasn't really usable and then I had to use a different checkout and it looks like a development on that has also stopped more than a year ago so nothing really that that ease the pain there things have started to change consider will be in the past there's telemetry now which looks really really very promising because it's starting to get baked into more more libraries and kind of we could start becoming standard features of library that they tell you about like what they are doing and how long it takes them which is absolutely great but it's also like work in progress right now not all libraries will have it yet and there are github projects that help you export telemetry data to wherever you want to have it but there also I didn't find too many great tutorials were just pluck and play and ideally if you start a company you'll be and before I mean obviously I'm making some generalizing assumptions here but normally you'll be very very resource constrained so you can ignore monitoring which is something I wouldn't recommend or you can invest resources in them but then you'll want to make sure that it's the least possible resources and still get you there so I think telemetry might enable you to do that in the future but right now it's still kind of not there yet alright last thing that's not really anyone's fault except maybe all is because we didn't spread the love enough but one thing that definitely you will notice when you start companies with elixirs that the adoption is just not at the same level as some of the other languages our usual go twos for startups so if you go to AWS or other service providers as other SaaS solutions they will most likely have ready to build libraries for you and an elixir there's great especially for AWS as a great for party library X AWS with all of these subtopics isn't that works really well today AWS is not the prime example here but it's just indicative of software as a service companies or platform as a service companies and not having a standardized libraries that they run themselves just because Alexis Egyptian is just not as as big as say Rubio goes and it also means that it will be extremely hard pressed to find experienced engineers that are not that intimate with elixir that's just something to keep in mind I'll address that in a bit when we when I stop bitching about Alexia and when I start telling you what's great about it but just because adoption isn't there there's just not a huge market elixir engineers are really good that are looking for a job not that that is the case and after other programming languages so you have a huge pool of Ruby engineers but the good ones are awesome also hard to find or a very well-paying job but yeah with with elixir just a pool of people that you can potentially hire it's just a lot smaller alright enough about what didn't work well reason I started with that is it's it's a good rhetorical figure if you want to have as something positive that you start with the bad and the end with the good so that's what I'm doing here and that's where we get to right now because there but our benefits of using elixir I want to kind of expand on them a little bit I want its is that I've learned today to only to a certain extend and not fully pure but I always considered it to be a functional programming language and that just has some huge impact on startups first of all and again this is all very subjective findings right like your mileage might vary but I found that the elixir code that was written in companies that I started with or that I was as part of an at the early stage had a pretty good code quality even though you might have junior engineers in there just because there's features in the language that kind of pushes you to writing maintainable applications pattern matching is one of those things that just if you if you really insist on people using it a lot they most likely end up writing better code and it just makes way more readable you don't really have like return statement so you can hide somewhere in the function body and you have to figure out why that function is returning something other than what you expect on the last line and the strict division of data and logic is something that really I think works well in writing maintainable systems because you know that where your data lives is not where your a logic lives and the other way around I find elixir and even Phoenix and we can argue about that a little bit I find Phoenix fairly explicit especially compared to other languages and other frameworks so as a as an engineer you if you look at a controller function so for example there are two arguments that get passed into that function that's all you can use in that function and you don't have parameters or get or post parameters or other information just appearing out of nowhere in your function body and that's just functional programming versus object orientation and I don't want to say that object orientation is bad but just for startups where you have maybe like a mixed group of people that I will be working on your application just having that level of explicitness makes it easier to understand especially for people coming into your project what's going on yeah function programming as no side effects I think that's a bit bold but there's less side effects and not as many side effects as you would have in other languages documentation is a big plus especially for startups because you'll most likely not have a big pool of knowledge in your company like you'll want to start bootstraps bootstrapped and with not that many engineers so being able to tap into the knowledge of other engineers or of just being able to read good documentation is very very crucial and I've I haven't looked at every programming language there is but especially as I go back to other programming languages I'm always amazed by how accustomed I got to really really good documentation so all of the core packages but also nearly all of the third-party libraries that we worked with were really really well documented and not only giving you like the most important information but also suggesting how you should be using it and what pitfalls there are especially if you look at actors documentation for example there are a lot of things in that are actually educational they know they don't just tell you you can embed data into this struct but they also tell you when to embed and when to use associations and how to attach associations to data while you're creating it there's a lot of things that just read like a good book on programming rather than just documentation and that's crucial if you don't have all that experience in-house and it doesn't have that documentation looks really really good I mean it's not something that makes it life easier but it just makes it life nicer I guess I'm trying to figure out how to say this without hurting anyone but in projects in the past that I've worked on I found that testing was perceived as something that he just had to do and I've worked on projects where you developed a feature and then people were like aha we also need tests and then trying to figure out how to write tests and if you don't design especially an object orientation your your software code around testing it will be pretty hard to test especially with edge cases I found that with an elixir projects it didn't feel like such a burden to and in the beginning you want to move fast and all of these things which is which is something you really want to do but also if you don't have tests you don't really have an opportunity to change things later and that will really come back to haunt you in startups so writing tests early is great elixir giving you a really good way of writing tests is even better and I'm not saying that this is not possible with other programming languages I'm just saying we found to be easier and not as much as much of a burden on engineers as it was in other programming languages to test community a lot of these points already touched on my last target I think these are very like prototypical elixir points I'm sorry for repeating them but they just made a huge difference for the companies that I started so I just want to wanted to highlight them and communities one of them I've never worked in a programming community that was so inclusive and so open-minded and even the most senior engineers or even the most senior contributors to any project you can just approach in channels and ask them the stupidest questions and they'll be nice and respectful and that's not something that I don't think that's that's usual for big programming languages they also super accessible so if you go into the right select channels you're most likely up or ICQ whatever works for you you'll most likely find the author of the library and he'll be there and he'll be helpful and that's huge again if you don't have a bunch of in-house knowledge and if you don't have 5060 colleagues that you can find the right one to ask that specific question just having that pool of knowledge and that pool of experiences at your disposal and just everybody being welcome makes a huge difference and for more junior engineers I always kind of push them to take the next steps and country breeds themselves even if we were in the startup context I felt it was crucial to encourage them to contribute to open source just so they understand what it means and get better at it and this community allows you to make failures and publish stupid packages without being chastised for it and I think that is key for developing more junior engineers recruiting I said earlier that the pool of resources of the pool of talent that you can tap into is limited and that's true but you have something to offer that other startups might not so at the end of the day if you if you're looking for a job and you're not passionate about it you don't get people passionate about what you start up you have equity you have the salary and you have basically like the whole package of what you're working on and with whom you work on it and trying to beat the rest of San Francisco with equity and money is a very hard task and it will drain your resources quickly so having something that people are really excited about and and giving you an up in negotiations is key to recruiting talent and we felt that elixir was that because you allow people to work on something new most of the time like a lot of people we hired didn't have any prior Lexia experience nearly all of them any of the ones that we spoke to really wanted to tap into your licks here so just having that as something that you can throw into negotiations was was huge for us and if you're recruiting more junior talent which we've done a lot and I really always enjoyed teaching is that elixir I found elixir to be a great language to teach because it's pretty easy to look at it's pretty explicit and you don't need to understand as many things to be able to contribute your first line of code as you might have to in other languages I've already talked about the explicitness and in and around like a controller functions of for example but it's for junior engineers it seems to be fairly clear where data is coming from and what they have to do to return it and that's not true for let's necessarily true for other languages and you can basically like employ a step by step approach with them and just give them a bigger view of the world as they go along but even the like most narrowest view that you can start with already gives them enough information to be productive and to have first feelings of success and feelings of contribution which is huge for junior engineers to get started and as as strong and as important as OTPs and something that I haven't even touched on it's not you don't have to necessarily understand concurrency and OTP and all the facets if you want to start building something or contributing something to elixir project it does a pretty good way of abstracting these things away until you need them and then they're there at your disposal and I think that's something that really makes it easier for for junior engineers to learn last good thing that I want to talk about and there's that list can be continued infinitively of course but I kind of try to highlight the points that we really felt moved the need of the most and all the things is operations I think we have two more talks today about like kubernetes and docker so I'm not gonna go into too much detail there but just being able to package use a multi-stage build and docker and use releases and put everything into in container that is self-contained and just has like a release and a binary that it can execute was huge for operations same as with everything else operations in a start-up you want to keep as easy as as simple as possible infrastructure can be the biggest time hog I've had multiple instances where I thought I would just do this one small thing in operations and two weeks later still wasn't finished so whatever you can do to simplify that will help you greatly I feel like releases and Doc are just a match made in heaven and they work really well and that's why I'm so excited about elixir 1.9 because they make releases part of the language and as great as distillery of us I think moving that functionality closer to the core of the language will be huge for operations recently talked to a good friend of mine who's still running a startup and he claimed a knife I have no data to back that up but it works really well in this presentation so I just used it he claimed that was elixir he's able to run a really high traffic website on a grand a month rather than three to five which other languages might have taken and at inverse we once won that why we had so much traffic on one of the instances I would think was going fine response times were good like everything was up but we were wondering where all that traffic came from or we realized that we with misconfigured our CDN to not catch anything and I've had that same experiences the same experience in another language in another company and it took down our entire stack for a day because we needed to like untangle all of the services that had brought down with it and build it back up and that was I kind of like a well we really really miss our big time and licks it saved a lot they kind of kind of situation I mean it's it just shows I specifically didn't talk about like the normal talking points when you talk about concurrency and fault tolerance and how well it scales it does and all that is true but for startups there are I felt like there were more important things to talk about that move the needle for you so some learning some recommendations most of which I've already touched on and this is basically like if if everything else I talked about today wasn't interesting for you mostly probably wasn't new but I just want to reiterate them this is probably like the most central slide in this slide deck it's just make it simple and that seems like a pretty obvious recommendation and it turns out that it oftentimes isn't as obvious as you think it is I was reasonable I was I was the reason for projects not being as simple as they could have been because I wanted to do things right and that makes sense but there's also like a certain level of wrongness that you have to expect except in the startup just to move the needle youth frameworks again not a shocking recommendation I don't think but we experience it around rolling our own solutions because we felt that there were better fit for a problem and a lot of time would work a lot of times it worked well but the the recommendation I would give here is like you use a recommendation for as long as you use the recommendation use a framework for as long as you possibly can and only if you convinced that it doesn't work go roll-your-own solution because normally and research your frameworks use the one that you like best but normally frameworks do a lot of things that you're not aware of when you start reimplemented am and then along the reimplementation route you realize how bad it was the next point is kind of like I kind of like went both ways in the past we did a lot of server-side rendering at each report when I first started and it cost a lot of problems and I think it's not a realization that was exclusive to be are so when we started inverse basically everyone was separating front-end and back-end and just doing a spa that would talk through rest or something with an API or at least that was our impression so being the cool kids we want to do the same and it's with the experiences that we made last year makes a lot of sense to render as much on the server and just have the the presentation logic where your business logic is if and obviously again I made generalizing assumptions if you if your product is something that is living in JavaScript or that is put for example showing things on a map that you can interact with you you won't be able to use so much server-side rendering and that's totally fine and at that point use react use view use whatever front-end library you like best or roll your own and be happy with it but if you start up or if the project that you're working on is like 95% of the other projects out there where you basically have some cool logic around having a forum and showing whatever you store and if you look at different websites different startups like just storing data retrieving them and presenting them in some way or another is 95 percent of what you will be doing a server-side rendering might be a very very good idea and we can share about that in a minute but phoenix life you might also be a good idea just to reduce front-end complexity and last recommendation I wouldn't would have wouldn't have made four years ago but if you start something and there's not a good reason not to do it do build amount of this you will probably have a small team and you'll probably not have too much interference with people working on different things once you do do break that model if apart but that's normally an issue that you'll get later on in your life and starting with a service-oriented architecture will introduce a lot of things that you don't really want to have to deal with when you just start with a product again simplifying assumptions if you have something and it doesn't mean don't use services but what I'm recommending is kind of have like your central app in the middle and try to do as much as you can in there and then if you need to have specified services I use them sparingly and cautious other than that just put everything in there I kind of wanted to use that given the recent events and really really resonated with me when I thought about this talk and when I wrote it because I think this is a quote obviously this this works in almost every situation but I think this is a quote that really exemplifies what I was trying to convey which is with elixir you you're able to just make it work in the beginning and then you make it beautiful and normally you really don't have to take the third step and make it fast like if it if it's it's working and if it's beautiful it's normally already fast so that's time that you save later on but also the make it work step Aleksey being a functional language or mostly functional language allows you to just make mistakes early on early on that yeah that are easier to correct later down the road so for example if you put too much logic into one module breaking out a few functions into their own module or even their own package or even down the line their own service that's totally fine the you will make you will take shortcuts in the beginning but these shortcuts will most likely not be as expensive as they might be in other languages because there's not as much dependency between functions in a module as there is for example if you have functions in an object that depend on object internal attributes and then you have to like pass them down if you want to break up that function into another object or into service level service object and there's just a lot more going on that makes it harder to like correct your mistakes or work with the simplifying assumptions that you make in the beginning and then licks it with with functions and modules I just felt like in the experiences that we made as it's not as costly to make to take shortcuts and to make mistakes so that's why this this quote by Joe really resonated with me when I made this presentation I decided to include it I'm already like approaching the summarizing part of the presentation I think it'd be great if we could have like a short discussion about what I just said after this alex allows you to scale it allows you to scale your team because you can break out functionality and don't have to do that from the get-go and thus it allows you to scale your codebase and also allows you to scale infrastructure wise because you can just throw my services throw more service at a problem even interconnect the service if you have to and just works really really well for scaling we haven't made the experience an investor's mind alexia so that was like kind of a worry that we had with inverse that we would find like institutional investors VCS and they'd say what technology are you using no we're not gonna invest that's not that's not experience that we've made you might have to sell it a little bit but mentioning that Alexei runs on a virtual machine that is older than I am normally worked really well or at least like whose foundations are older than I am and I think it's getting easier and easier to because there are like success success stories with startups that used it that a good reasoning a good way of reason why you should be using elixir and especially with with power line being the foundation of everything and our line just being proven for applications that are very similar to running a website really helped us convince investors we made the right technology choice which is something that they if they're good will take into account when judging whether they wanted to invest in you and this is always the final recommendation that I have are not unbiased I've been working with elixir and I've started companies in elixir for the last five years so even though I try to highlight both sides of the coin even though I try to be objective I will most likely not be I wouldn't say always use elixir no matter what you're doing your team you have if your experience in another language use that language if you do hardcore video processing it might be a good idea to use some of the seed libraries out there and licks it might not be the right choice if not all these things apply and you have the chance to use alexei it's it's a great choice and we've been really really happy with how it helped us build companies but that's not saying that you should use it wherever whenever why would anyone want to build startup with Erics here taken at account all of its drawbacks isn't it an easier choice to choose some well-established technology like for instance Scala I don't know you have to I mean you have to be really exciting about technology to experiment with Alex your along and taking into account all the restricted resources and wouldn't increase the risks when you invest in a technology like which has some drawbacks isn't it a better choice to choose something else yeah it might be but the the risks value we talked about I mean every every decision that you're going to be making will introduce risks and using al excitability startup will introduce risk so it risks as well what I was trying to show is that these risks are very manageable and that you that for us Alex it wasn't the make-or-break for the startup yes in other languages you'll have more sophisticated authentication libraries and maybe better telemetry baked-in but the flexibility that Alexa gives you in going back and correcting mistakes and just making these makes mistakes and a get go kind of offset those drawbacks for me as for the resource pool I don't know if I'll find more people being excited about Scala and about Alexa these days but that's also just my filter bubble but finding talent was never really an issue for us despite the smaller resource pool because people were the people that I talk to at least that we ended up hiring we were excited about trying elixir I mean some specialists from I understand and specialists asked us and on the platform sometimes it's easier to find specialists there is a plenty of specialists and other languages so if you need to quickly scale your company and you need some personal some staff urgently you just can't scale because of this scores of specialists you cannot employ them an instant I mean that's true if you have the money to spend and you just want to have keep people off which 20 are very senior it might be easier to do that in a different language that's the simplifying assumptions I was talking about if you start lean and you have a small team one specialist might be enough to the gate for the get-go and ideally I mean if you don't have a specialist in elixir I wouldn't start my company elixir but as soon as you have one it's easy enough to build your own and then if you take a normal scaling path where you add more importantly and not fifty at once we found that that is very manageable in elixir obviously that's why I left the slide up if you for example do ml something like that Python might be a better choice because there's just more libraries and more experts and data sciences that are used to like Python but that's that's why I'm saying you kind of have to like look at what you're doing if if you have the Liberty to choose Alex here I think it's a great choice what's your opinion on leaning to established but external solutions like Redis versus trying to use what Alexa has to get there I mean I'd argue with that a little bit you can do background tasks and almost every language is just gonna be a lot harder to set up and manage so ruby has delayed jobs delayed off a sidekick which will do a lot of the things that you'd otherwise be doing an agenda of an Alexia I think the thing that is great in elixir is that it just allows you to do everything in one node if you really want to get started and also the more services like writers that you add to your stack the more harder it will become tremendous that stack and the more resource intensive it will be to run that stack which is not saying that down the road you'll probably end up using something like writers or another in memory store and that's fine I think that Alexa just gives you like the Liberty to start with a very limited set of services and then as you scare your team and your application it's easy enough to add the services and breakout functionality to use it [Applause] you you

Channel: Code Sync

Views: 15,037

Rating: 4.9012346 out of 5

Keywords: Elixir, startups, Michael Schaefermeyer

Id: icfvFFZUxZQ

Length: 41min 44sec (2504 seconds)

Published: Sat Jul 13 2019