Coding Without Complexity

hello thank you all for being here at the very end of the day so over the next 50 minutes we're going to talk about what it means to code without complexity but to break that down a little bit I'm gonna tell you a little bit about myself and why I care about this problem we're gonna talk about what complexity and software development today it does look like then we're gonna do the fun part where we're actually going to get to write code for a while and look at what the future might be like and then we'll break down some of those concepts and talk about how we can be removing complexity from the systems that we're all building so since it's the end of the day let's keep in mind how we're feeling I hope some of you are feeling like you've already had your mind blown and you have something that you're really super excited about I hope you're feeling adequately like you've spent a bunch of time talking about programming languages and infrastructure and I'm pretty cognizant that by 5:30 after listening to talks all day I'm usually a little bit tired from can you make the mic a little bit louder please I don't know how to mean is that better no I'm going to keep talking until we resolve our microphone issues is this loud enough yet you have to tell me it is because I okay still no still higher okay is this better are we getting now we're getting feedback I do not know how to resolve AV situations is this it's not changing okay it's not changing all right is that better okay yes people guess great thank you okay from my side this actually is quite a good transition I'm happy to be here and talking to all of you and I feel the Norma's amount of the normal amount of jitters that one feels when they're being attached to a microphone that they don't usually talk into and so I started thinking about this a lot in my career and as many of you as senior developers and leaders probably did as well when I started spending less time staring at my laptop and writing code and more time interacting with people and when I was thinking about how to handle my own feelings and keeping track of them and working with development teams I realized that I wanted to use the tool that I am most familiar with which is software so I wanted to use software to fix this i sat down and thought I'm just gonna build myself a simple application it will allow me to track my moods using emojis which are what I used to track my moods anyway it's what I send to my friends it's how I think about it and it was gonna be pretty simple I just needed to have a way to check in and some aggregation so I thought this would be an incredibly simple back-end all I needed was a persistent data storage and endpoint to post check-in and endpoint to get all my check-ins back and an endpoint to run some aggregation statistics when I sat down to do this over the weekend it instead became a mess of lots of things I was interested in I opened up functions I opened up the AWS console there are a hundred and fifty different options that I can think about like we were talking about the panel in this morning then I thought okay I'm just gonna go back to way I would have done this a long time ago I could get started in rails but rails has an API generator now and I'd be checking a bunch of dependencies and versions but once I get something working locally I still need to host it somewhere so maybe I make a repo and then maybe I run it on that cool new thing render oblate by now I still need some data storage and that's a problem I really only want to do four things I want to be receiving some data processing data storing and querying data and sending data and yet somehow I end up in this mess where I can spend we and never actually end up shipping an application and this seems wrong to be doing for simple things this wasn't just in my side projects in my previous professional life I was a product manager for a long time and infrastructure challenges came up across the board when we were working on things and I think many of you will face the same problems when I worked at Microsoft on Office Mobile it was great because we got to sit between office Windows Phone SkyDrive and SharePoint but that also meant we were thinking about a lot of different teams and at one point while we were building office mobile SkyDrive decided to update their API and we didn't have a formal agreement in place with them at the time and so that meant that we actually ended up shipping a version of Office Mobile where you couldn't see all of your documents you guys are then open the SkyDrive app separately and be able to open those all because it was so hard to change API protocols and then I worked at Kickstarter and that was exciting as well there weren't as many problems of the previous type but instead what we had was we had our development environments our staging environments and our production environments and pretty frequently a lot of my work on backer experience meant having to check the checkout flow and understand how people were able to back projects and then process their payments but unfortunately frequently a staging would get out of date and there would be no live projects that you would actually be able to back and so then as a developer you would spend a lot of time thinking about okay how do I do move a bunch of stuff from our redshifts system so we can have projects that are live on staging again taking time away from thinking about okay all I want to do is actually ship this improvement to the checkout flow and then I worked at Lola a travel management company and it was really important to us that our infrastructure worked well and it was scalable we knew that when we launched the product we wanted to have it ready for a large number of users right away sure some of you have run into this problem before as well and so we decided to shorter databases which seems like a good investment until we got to the point where we realized the core unit of our customer wasn't actually on the individual user it was that we were going to be a b2b travel management platform and so now we had these challenges where we charted on the wrong thing and it was are we gonna react to tech to everything or are we just kind of gonna keep cobbling this together and so the really upsetting thing about this is I feel like our general attitude within the industry is it's got to be like this and it's going to be hard Fred Brooks wrote his essay in 1986 no silver bullet saying until we get to the point where most of the things we're doing in software don't actually matter we're not going to be able to make things an order of magnitude better because right now most of the code we write we need ensure we do a little bit with memory management or garbage collection that's about the device that we're running on rather than what we're actually trying to serve but it's not so much that we can get an order of magnitude better I think things have changed a lot since 1986 and one of the big ways that they have is that now we're all primarily running on distributed systems rather than just writing our code that runs locally and when we did that we kept up the same mentality that we'd always had for software development when we think about the first tenant of the UNIX philosophy it's make each thing do one thing well and that's what we still do when we're adding tools to our ecosystem we make a tool that solves one problem for us and does one thing well but where that's gotten us to is we've actually gotten to the point where we are spending a lot of time and all of you and your teams are spending a lot of time on the things that we don't want to be stripe released their developer coefficient report in 2018 saying that nearly half of the time we're spending as developers is on dealing with bad code debugging refactoring and modifying rather than delivering new business value so when I look at that that really seems like we have gotten to this place where it's no longer our world of 1986 where there's no silver bullet we have accidental complexity absolutely everywhere and things we're doing so that's a little vague so let's break that down into three categories in particular axonal stuff complexity in software development today falls into three buckets the first one the one all of us in this room probably think about a lot being infrastructure the second one being deployment and the third being api's and specifically how we talk to external API from within our applications infrastructure wise have we seen this map before my like favorite thing about this diagram is that at the top it has a little no that says overwhelmed please see our other map even though this is meant to be an overview I think a lot of you in this room maybe probably actually know more of the things on this slide than I do but I think very few people don't feel overwhelmed when faced with four hundred choices of technology they could use when trying to move to a cloud native infrastructure the thing about this is if we go back to our beginning of we're just trying to receive and send and query our data and store it somewhere yes these things sort of help us solve these problems but they aren't one thing that lets us do all of that it's this giant ecosystem just to do those four simple tasks we think about deployment I enjoyed the joke earlier that if you ask 10 people on a team how something gets to production you will get 11 answers which i think is true similarly coming from a product background a common interview question to see if PMS we're technical enough was always what happens when you type a URL into your browser and how do you get a response back I think a more appropriate question today would be the same one of how do things that your developers that you're working with right get into production and so when you think about this really all you're trying to do is ship something and to think about how you're shipping it you have to remember these 34 different steps that you're going through and someone has to maintain and think about this and then api's api's used to work just like function calls and i don't know about all of you but today when I'm building with api's I end up having one thing up with all of the documentation and then my command line up so I can do a bunch of curling and then probably another API tool to be able to inspect things and then a whole bunch of other stuff that I end up meeting for some reason and so today it no longer works just like a function call we end up in this world where we end up having to use a bunch of tooling just to do something simple like talk to an external service and so that's what I want to think about is what happens if we don't think about these things what if we don't need that slide of 400 thanks what if we don't need a 34 step deployment process and what if API is once again are like calling of the same the native functions from within a language and so that's what we've been doing with dark over the last two years we've been building a holistic language editor and infrastructure for doing this I'm going to show you what's that like from the perspective of what does it mean to put all of these things together at once but then we'll go back and talk how some other tools are doing pieces of that since this is a language track I know that everyone always wants to get into the nitty-gritty of what is the syntax of this language and how does it work and so before we actually demo things it looks like a normal language it just looks like code this is a question that many of you may have been forced to answer it's some terrible part of your life but from the perspective of this dark looks like any other language you have conditionals the language itself is functional okay but with that in mind let's actually write code and talk about what a world without accidental complexity looks like okay first thing you will note that I am entirely in my browser I have not done anything special for this demo before I got here except I did pull out do use do myself once yeah that'll work I did pull out all of my tokens that I'll be using during the demo into function so I'd just be able to call them and not show you all of them so first thing in dark when I am setting up a new API endpoint all I have to do is specify my route which I've somehow lost do the method it is responding to and my response and so this is now up and hosted you could actually I'll go to it from your phones if you want to and so rather than my process before when I was thinking about setting up a simple mood tracking application and then spend hours trying to figure out how to configure infrastructure and got down my rabbit hole of all of the tools I have something that's just up and it works for me if you're wondering about how this works under the hood it's actually a very standard thing that you would build for yourself into the code it's running on G key and the data stores aren't Postgres and so then if I want to say make slightly more oh yeah so you go those are whoever in the room has just visited this end point apparently there are four of you who did not believe me and checked it out thank you for that I actually drove in and so then if we change this actually will do it you can do this cool many more of you and it'll be like 15 and then it'll start getting rid of some of them for me and so then if I say change it and whattcha greet visitors by name I can add a URL parameter I will say hello to Q Khan and you can see that my response is still updating and now some of you can create yourself so not Paul Kem Brel hello not Paul Kimbrel and so the cool thing about this is we can now see what our expression evaluates to for the current trace coming in let's see it's got another one Tyson that's a little bit easier and I think one of the things I don't usually show this in demos but since it's this audience and I think this is fine if we wanted to make a change to this code and since we're writing live right now obviously you wouldn't want if you had a bunch of end users like right now yourselves looking at your application you wouldn't want things to just change without intentionally making a decision so in dark I can add a future flag I can name it like we'll just change the greeting and then we can set a condition and so we'll change it say only if the name is mine and then I don't want all of you to be able to do this and then we'll just change it to be high instead and so now when I go back over and I greet myself I get hi Ellen but the rest of you are still getting hello to whatever end point you wanted and so from this perspective we've moved from this idea of I have an environment where I'm writing locally and then I'm shipping to staging and then I'm shipping to production to my application is working at production but I am still doing all of my changes behind feature flags so I won't be creating a bad user experience all right that aside what does this mean when you're building a real application instead of something that just means saying hello worlds you just really excited about this you're the best audience I've ever had no one ever does that so let's make a new one we're what we're gonna do here is frequently when we're developing we have some piece of our application ready built in this case a front-end and so what I'm gonna do is I have a sample front-end that I built ahead of time it's a react application if you want to see the code it is not very interesting and all that I've done in here is that I've set my API host to be pointed at dark where we're using it and then I used a command line up to app to upload it to where are we working and so this is what that looks like and you can see that because we're actually working live we get this 404 back and instead of doing what we would usually do while developing which I find to be extremely tedious and slow and having to go inspect and figure it out and then figure out ok our hosts and point fails and then go build that and then deploy and then hope that works we actually hooked up to it already my dev tools is what I can do is when I go back into dark I can see that this end point is failing and create that end point directly and so I'm building based off of what my application needs from the front end and from the end-user experience rather than having to do a bunch of stuff and see if it works then we can actually try it out if I add real data I can go back over and I have this here again one of the things that like seems a little bit silly about this demo is it feels like it's a toy application because it's relatively small which is what you have to do to get it to work for this but I want to make it as real as possible so instead of just having a host endpoint let's actually make a real data store let's give our hosts names and phone numbers this way we can tell them when people are visiting them and the other piece of this is now we want to be able to put someone into this data store and normally I would have a bunch of database tools that I'm using with some database that I had to go set up completely separately for my browser in this case I can just make my tool side-by-side and it'll work exactly the same way my HTTP handlers are working and so what I can do is I can add myself this is my real phone number sometimes I edit that out and that is and so then what I'm also doing I just had this on my clipboard this is my slack ID for our company slack so we'll be able to any actual messages in Dirk is a little bit hard to tell while I'm typing you're editing and ast which is part of what makes us know you won't break their production infrastructure and so when you have this you can actually do a bunch of cool stuff because it knows you're not just editing text I think there was a comment earlier about if the structure is text first code and this is very much not just text so I'm going to extract this so I can reuse it and so actually let me do this so if I pull my same variable out here and then I rename it I get all the nice auto renaming stuff that you might get which i think is very nice is the part to the built-in language and so then less piece put this into the data store same as before how we could see are the results of our incoming traces that were coming in hello pika we can choose to execute functions that have side effects and so in this case if I want to start something in my datastore I can do that and as soon as I've done so my datastore locks same thing with the handlers and needing to edit live code behind feature flags if you have real data in your datastore you want to be running a migration all right so now that we have that we just need to quickly edit our endpoint to be getting all of the hosts out so we can do the same thing here we can run it see what it is we don't actually need every single host so we can pull just their names there that is it'll be just me we go back to our front-end application that works and if we check in is coupon same flow make my visits endpoint and then we will work with that and so here we go the interesting thing about this is since we've passed in real data we have it available to us we have dude here who is apparently already checked in and what this what this means is that rather than having to guess at the shape of our objects we know exactly what they look like as we're doing it and just generate a new key and make our new datastore which is gonna have the same shape and so then I can double-check this so if I make this visits I get this relational link to my business data store I can go back and forth between them if I want but the interesting part about this is that I can compare that easily to the shape of the requests that I have coming in in the future you'll be able to use these to generate types and use types as the background so again we will run our request and we can see that that has now also locked and last piece of this right now technically if you go check and it'll work you'll get a confirmation because you're getting a return value but I said I wanted to show you what it might look like to be easier to operate with api's so let's do a little bit of that in dark there is a built-in eventing system and so I can admit the requests I got to be able to send a text message in a worker and then the same thing will emit the same event to be able to send a slack to you so let's do the text message first and you can see once I execute them it basically makes it to-do list for me and so when I'm doing my son text I much like I had woo that's mean um much like I had the I think I don't think is gonna matter at all but much like JC Thank You JC or a nicer person much like I could work with my requests directly in my HTTP endpoint I can work with my events directly here so I have my host name and then let me get my host back out of my datastore and then again we can run this and check that it works which it does and you can see that I really have this feedback loop all the time because I have this data where I can make sure things are working the way I want them to and then I want my host phone number and you can see here I get that autocomplete for the fields like any modern editor and then last piece of this I want to be able to send the host a text message to say that they've gotten a visitor and so in dark I can just call Twilio send text I pull in my Sadie this is the thing I showed you that I pulled out before hey aunt we are going to send it to me the host phone and we're going to say event visitor it is here to see you and so now is the point where you actually get to start sending text messages to my phone the cool part is much like we ran our DB query functions before we can use the same thing with our API endpoint run it and then see the message and in this case we actually get an error and it's because I used the firm number wrong oh yeah that was actually really great so now it's easier for me to debug because I can see the firm number is this thing which is not what it should be it's because I put my SAT there again run my text message again and I should get a text that says JC is here to see you and I have a text in my phone the iMessage syncing between one's phone and one computer leaves a little bit to be desired so similar not you're not going to have every single API wrapped in a language out of the box and so with flack I haven't done that yet so I'll show you the equivalent experience when you're using different when you are using the HTTP client library instead it's basically the same copy/paste works by expression which is another nice thing I somehow lost something there we go ah and then what we want is our channel which will be our host utter slack ID run this make sure we actually get this back we do and so in this case we're gonna want to build a header so [Music] again select joke and I also pulled out ahead of time the API we're using we're going to want to use the JSON content type so we'll do that nice thing about this is we end up with a nicely formatted header and so then last piece let me just blood the URL message and so now it should be playing post URL chickens slack chicken channel channel text event dot visitor it is here to see you don't worry about yeah I will make this empty and we already built our header and so same thing we've now integrated with an API from scratch using an HTTP client library rather than having a nice wrapper and when we do this we will get a bot message that select star from hosts is here to see you so I would say that seems to be working for us if I go over here we do and this is cool is here to see me as well thank you and we can also see we have pending events coming in that will continue to process as people visit the web page and use this but for all of you who are not sitting there following along and resubmitting names over time if I do this I will get the confirmation I will receive both a text message although probably not and also a slack message and so I wanted to show you that not because I love building off of sign-in applications although I seem to do this a lot now but because I think that's the power when you take away all of the complexity at once is you go from something where you would be spending way more than 10 minutes just to get an environment set up to being able to ship a working somewhat functional clone of what would have been and stage convoy or other office check in system sternum and so projects go from being something that you need to spend a ton of time thinking about to being something where you can just spin it up and try it out and work with it whenever you want whether it's a prototype or something you want to continue to work with and so let's hop back over and talk about that a little bit so when we're thinking about no accidental complexity it's just what you saw it's that you're getting compiled infrastructure where you aren't thinking about as you're writing code you are getting an environment that I call deploy less much like we talked about server less they're still servers with deploy list they're still a deploy it just happens in the fifty milliseconds after you type in before you can switch back to see what happened and you have something that acknowledges that the world that we're all developing in today is really focused on all of these external services and connections that we need to make and so let's look at what each of those pieces is compared to what we have today and some of the other ways people are approaching this as well so infrastructure complexity I think we probably all remember as being giant slide of many services we can use to be able to do our basic needs for backends of sending and querying and receiving data we really have boiled down into a super small set of core use cases I showed you four of these but not the fifth but when you're building something without accidental complexity you're thinking of what is it that I want to be doing and it might be that you are having a persistent data storage it might be that you are running something on a scheduled cron it might be that you have a background worker that you want to be responding to events it might be an API endpoint or it might be some sort of tool that you're using I would encourage you to think about the applications you're building and figure out how many things you're doing can be boiled down into these categories or don't do a bunch that don't I would be interested to hear about them because I found that most of my projects and most of the work that I have done over time is really a core set of services that I'm working from this might seem familiar if you've used other popular products like AWS lambda and so when you're thinking about this even though lambda technically has many many options of what you can do if you really think of it as the core of being your code runs on a trigger you can also connect that trigger to be based on time or you can connect to that trigger to be based on an HTTP endpoint you end up at a very similar set of core functionality that you're able to set up and keep working with second part of this one of the things we didn't talk about very much while demoing but is interesting is when you have a bunch of independent services like this it becomes really important to know how they connect to each other I don't know how many of you have started a new job recently or have hired someone recently but I feel I spend a lot of time going to whiteboards and drawing out a diagram of this is how our code really works because you can't just put someone in front of their text editor and say here's the file structure that's not how people learned that's not how people think about the impact they're building and so by having your infrastructure work like this you can end up having something where you can see all of the connections between what you're building and how they relate to each other in modern infrastructure technology today a lot of other people are trying to build systems like this cloud craft is one example where you have a system that allows you to monitor how your infrastructure is connected together and how your services are interlinked ok that's a big one then deployment complexity we talked about this before this is the big scary one right now we have these deployment pipelines where most of the people on our teams don't necessarily know how the entire deployment pipeline works and we keep adding more things in the name of adding safety or hopefully making things better but every time we add something it's another thing for people to think about or it's another couple minutes they spend not being uploaded polloi I spend a lot of time at Friday retro meetings with people or going just has to get through CI and then we'll be there and then we can see it and that comes with a real cost of course I just showed you this and how it works you in dark you can just deploy immediately the scary thing about this is the fact that it is live and you're on your production infrastructure and that feels weird and so I think the really important thing to think about here and then I would encourage all of you to think about and think about adding to your team is when we came up with the idea of having development environments and staging environments and production environments and creating safety by separating out where things live we didn't have the modern best practices of having feature flags that was really the only way we could control who is able to access things and now that we have feature flags that's a great way to control who is able to access things and there's there's still limitations here we get a bunch of extra safety out of features in the language where we can deploy in it's less scary but from the main perspective if you can set it up so the default action for thinking about how you're delivering to a user is behind a feature flag rather than behind your environment you're actually thinking about the thing that matters like none of your users care about if something is on Dever staging your prod they care about can I see it or not if it's on prod and they can't see it because it's behind a feature flag that's fine it's not there for them and then similarly that causes less risks for you the longer you let something bake in dev and you have this giant pull request that's sitting on your machine that isn't out there the more likely it is that it's gonna be hard and you're gonna have a bunch of merge conflicts when you get it in the longer something snips and staging the more secure people will think they feel about it because they've been testing it for so long but staging isn't necessarily a proxy for the real world same thing is when I was talking about Kickstarter and not ever having live projects on staging that means it's a very different place than the live Kickstarter site and so if you've been work towards the world where your primary thought about what it's safe in your deployment process is operating behind feature flags you've gone a big step towards not having to think about as much of this deployment complexity I'm gonna skip that since we already talked about it and I would say that one person who has spent a lot of time thinking about this in the modern ecosystem is lunch early and they're specifically a feature flag provider so if you are trying to say okay let's spend less time on this deployment part and more time investing in future Flags this is a great example of a provider who's really focused on that last one API complexity so again my experience of api's opening many things to try to get something to work and it works in a terminal or it works in your API test provider in it that doesn't work when it actually gets into your application plus when it's actually in your application then you need a bunch of stuff for backups and retries and all of those other things he needs to get it to work one of the things that's nice about having an environment and particularly a language is you can start to compose api's such that you take more and more away from what individual developers need to use and so there's the basic you can talk to any API through an rest request for the most part you use HTTP client post but you could think about how you could build internal tooling for developers or your company such that they would be able to call them much more closely to functions like the toilets and texts I showed you and the extension of this if you want to go a step even further it's depending on the teams and their different needs is you could even pull out your secrets and your credentials into another place so that developers are only really thinking about what is the phone number I'm sending a text to and what is the text that I'm sending and not necessarily thinking about the actual configuration around the other requirements for the API a company that's spent a lot of time looking at this base and particularly the space of being able to think about I just want to give this API up and running is transpose it if you want to play with it they have a really fun sample where you can have your Google Calendar link to your slack very easily using a fare like a minimal amount of actually writing code and it'll say okay if you have vacation on your Google Calendar I will set your slack status to being away and so people are really trying to move towards this world where we're not all writing the same logic for handling these external api's we're instead able to write the stuff that we care about the last piece of this which is kind of cheating my favorite thing about being able to integrate with external api's and this is actually true for most of the code here in this case like you get the text message response from your API and you can debug like we did in real time in dark you get the same experience for other functions like we were seeing so this is actually the emoji application written in dark and I can look at a check-in and debug what has gone wrong with it there's certain emojis that break which is really interesting and from this perspective the ability to have this real-time feedback loop whether it's around the API is you're using whether it's about the results of functions in your language whether it's being able to see what would happen for a specific trace or debug a specific instance you have and being able to do that right away is actually the best way most of us learn but right now we think of those tools is being prime early for novices or people who are learning to develop and so we think about that the one of the really cool things about glitch if you haven't played with this yet is you can go and you can build a JavaScript application and then it just runs and you can change it in real time well you can just go and edit the code and then hit go and it just works and you can actually see what's happening and one of the challenges we've run into with back-end systems today when you're sitting there is you write a bunch of code and then you go through this tuple I even or you build it locally and you hope it works but you have this like long lag between when you do something and when you see the potential results and I think one of the things that really moves removes complexity for people is not having to think about every single thing they're doing is they do it because they're gonna get the real-time feedback so blech is one company that's doing that another one if you want to play with it is repple it where they spend a lot of effort on supporting a bunch of different languages so you can get this real time experience as you're writing software and so that kind of breaks it down I think when you think about the future of the entire software ecosystem it's really exciting when we can get to a world where you're able to build with no accidental complexity whatsoever and we can all build things in 10 minutes and ship them to our users and be happy about it that's of course not the world we're necessarily all living in today if you're at a small company maybe it is if you're working on a side project maybe it is but for the rest of us it's more about we're going to need to make incremental steps towards having this better developer experience and not wasting so much of our time doing the same things over and over again three tenets of that will be this idea that for application developers you will have this compiled infrastructure that just works for you instead of spending a lot of time thinking about it you will be able to get this real-time feedback and not think about a thirty four step deployment pipeline it will work for you and you'll be able to use api's like functions but when you're leaving the room and you're hanging out with each other tonight and you're talking about it I hope you'll take away two things from this the first is when you're thinking of adding one of those many services from our cloud native ecosystem or something new to your deployment pipeline or something new around connecting to external api's you'll think contextually about it and figure out what problem you're solving rather than just the about this is the cool new thing in our ecosystem and then the second and perhaps more important about part of that is every time you're thinking about adding something new to your infrastructure tooling when you're adding it ask yourself is this removing some existing complexity from what I'm doing they will make developers better able to deliver software as we're building and if that thing isn't removing complexity ask yourself is there something else from our tool chain that I'm going to be able to remove as a result of this to make sure I'm at least not adding to the complexity that our team is thinking about so that's what I'll leave with you with today I hope you had a great day at coupon and thank you for being here let me know and I'll run over to you with the mic just oh there we go if I want to get started I'm using darkly is there any like is it talks or anything like that do you guys host any informational stuff to get started currently we're in private beta and so the way to get access right now honestly the private beta thing so I'll come to me so you're actually just talking to me and what that is is it's mostly about scoping the application that you want to build and making sure it's something the platform supports effectively today and I'd be happy to talk to you about that yeah my question is also based on but just see asked so how do I get started like on dark and P of the tools you just mentioned how do I get started using it you add all of them are open source especially I am more interested when you talk about the infrastructure thing I was amazed at how you know you have taken out almost ten steps to deploy the application and get it immediately so how do I more research on that and how it is happening without any deployment you know container I don't know more of that part yeah so I I I'll repeat it back and see if I'm getting it right you're interested in more of how it actually works under the hood and so from that perspective what happens when you're writing code in dark is when you're editing your editing a like a specific expression you're never editing just a small piece of text it has some actual implication where we say okay we know what expression are what function you're adding to your code we will deploy just that expression or just that parameter that you've added to that expression and then what happens is that then goes through like a very standard deployment process on our side it's orchestrated using kubernetes it's hosted on Google Cloud it's actually quite boring under the hood the only interesting piece is the abstraction on top of it that allows you to not have to think about that you mentioned Google Cloud do you support like AWS or Azure oh again this is not a like use dark marketing talk this is just like I don't have another way to show all the things at once yet which I hope other people build them too right now we down is just on Google cloud just dis cope what we're doing there's no reason that someone couldn't build something like this or this couldn't be multi cloud uh hi cool question so how does testing work with that like unit test integration test that kind of thing yeah when you saw the the requests coming in for when I had an endpoint and you could see the live data the idea would be that you would be able to save each of those incoming tests as a unit test if you specifically wanted to rerun that and have it automatically saved in that way and then it's a general-purpose language so if you want write other tests you can this isn't about dark itself but in terms of reducing complexity and removing this stuff how do you deal with developers or engineers just like not leaving well enough alone and always wanting to dig like a little deeper into something and always having that one piece that like this doesn't work exactly how I want it I this is like have a CEO p.m. answer and half a just person who answer I think the thing that I found to be most effective in this case is weighing the actual trade-offs and so like yes maybe this one piece isn't exactly right but if you're getting 10x the time savings and giving up that one piece that means you can deliver ten times more stuff to your users you can learn 10 times more new things and I think it's always about framing the problems such that people can see the benefit in the context of the trade-off I cut this feeling it feels like the visual basic for Windows and it like it was very easy for users to create like apps but then they tend to which the whole mess that people are still trying to deal with it I had June a little bit scared too trying to create something like that again yeah I man yes I think the the reason I'm not scared is I think when I look at all of the choices were making and the fact that we put a whole lot of very smart people in a room to try to talk about how we're going to have programmable infrastructure and like the future of infrastructure I think it's that things have gotten to the point where the solution we're using probably isn't the right one and we have to come up with something else and so when I look at that I go what is the coolest thing I can possibly imagine for where we could go and what would the best possible developer experience be and what would it take to be able to do that so with your feature flags and your elements as you're promoting those from being behind a feature flag do you have the ability to like the observer ability and the metrics to look in to see what's being used from that from that standpoint almost like an operational to define which code starts to you know kind of fade out yeah for sure I think this is actually a really great point is well all of the infrastructure we're running on is accidental complexity that we have to do to be able to ship our systems knowing how our systems are working and who is using them and how that works is really like essential to businesses and people need to know what's going on and so to that level of granularity with the future flag you can write completely custom logic for it this is only for my name or this is for this header or this is for this set of alpha users and then you would want to look at how that's working across that group before you can make the decision to promote to the next one can you have multiple people work on the same code oh yeah this is like one of the things that's really a bummer is it's hard to demo when you're by yourself the other thing that being live and deploying everything incrementally gets you is you can end up having a collaboration experience with developers on your team that is much more like a Google Docs like experience where you can both the editing things and working on things in real time together rather than saying I'm going to go off and build this thing and then come back with it you can put those by in future flights as well okay I think that's a wrap I definitely appreciate Ellen so another round of applause please [Applause]

Channel: InfoQ

Views: 16,632

Rating: 4.5862069 out of 5

Keywords: Culture & Methods, Development, Software Architecture, Refactoring, Design, Agile, InfoQ, QCon, QCon San Francisco, Transcripts

Id: NDg6Ko9gbGk

Length: 43min 8sec (2588 seconds)

Published: Tue Jan 21 2020