Merken

Can Time-Travel keep you from blowing up the Enterprise?

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
and there was a little bit better than the other end of the floor right at thank you all can time-travel keep from blowing up the inner products of the where the abstract talk another really talking about scaling rails
but not this kind of scaling right we don't want to talk about making rules do so faster or making rules do most of it once use the hardware the problem goes away but we talk about scaling up and of a code base or a team or uh things around using rails and how to use rails as we scale problems we have and and all that so right like a growing team of growing business or project of products and a changing 1 right how we scale ourselves through stuff like this a lot of people think that the way to answer that question is to
decide between 2 we do a monolithic architecture do we do micro-services so we'll talk about those things but it's kind of a false dichotomy that's not really what we want so the explore this use of framing
device based on the Sotscheck an acceleration episode cause and effect anyone in the subset are i it's OK if not if you started it's OK but tell you all you need to know In this episode of the
enterprises flying through space as it those looking for
trouble and they find a spatial anomaly
as they do and costing rush to investigate find out what's going on especially as they approach in standard and do the things a ship flies now on a collision course in the enterprise the arrest can away in time and the label and this is like before the commercial break so it's the middle of the season 1st of all so you know linear price is not dead and all dead what's what's going on here so collection commercial everyone's back when they start they lived on the same day over and over again and eventually will themselves up again to the 2nd is kindly each time they get reset after the enterprise blows up they can eventually learn to send information to themselves a trident different seasons so that when they get to this critical point they don't all his survive in their course able to do so by the so worry users talk about scaling rules haven't haven't seen this experiences all these sort of normal growth and change in experiences and any decisions that of blow up their enterprise and then they're going to get to do it all over again they're going to do it all over again a couple more times and we'll see what might be a way to avoid that so the
assumptions but we're assuming that on this project products whatever of more people work on the code then you initially worked on it right so were were were saying this is not just 5 senior developers banks about 4 5 years is going to be a team is growing because more things to be done more poorly different people work on the code so that means people of different levels of experience people with different opinions about how to write code different opinions about how to write rails and the person who that 1st controller is not to be around to make radical changes that controller later right so that's another assumption and that there will be increasing demands of this code the team will make decisions based on assumptions of their taller absolutely true will never change and then those things will change and see what to do about and I think these are all pretty reasonable things that happen to to all of us and failure then is of the products right not meeting the needs of the users try to solve for must be built to serve a purpose and it's not serving the purpose then it is failing and you know this is what happens in that right simple chains become difficult and difficult changes which are also often important thing is becoming possible and its low morale acknowledge working of failing or failed project and the people sort of so I I would argue that this is all this these assumptions I mean it's very much in common but not universal and so I our gonna start up and this is exactly the trajectory that we have right were growing changing responding to change but a new project at a big company or some longer-term consulting all have this sort of shape to them right I and I said 3 years working at the US Marshal Service Government right arm and that the trajectory of the project I worked on those 3 years is very similar to the trajectory of what I'm experiencing right and now which is a start up onstage fixed right 2 totally different businesses totally different centers but still very similar shape in so growth and change that sort of so let's get into our team has been assembled to begin this project products business what have you and these rails because as we know roles also that we're doing here rails uh makes lots of things easy and in terms of how you continue to use rules what Israel starting to do tells you to put everything in the
rails right that's that's how rails like has its advantages everything is there any of you know monolith kind of has a negative connotation but it doesn't need to be adjusted the word to describe how you write your code and
and this method of coding is great early because you can ship so quickly you can respond to changes you can handle anything that comes at you feel super productive and and it's really like real sweet spot right also
so as as time progresses the team grows so initially the core developers and that no problem banging of features with highest you few more developers and and things are going pretty well and you know there's still a little bit of a difference of opinion on certain things but it's not a big deal if we have more and more developers and so you get to a certain size you want developers to not have to all think up together they're going to be working on different project at the same time parallel and interacting making the same decisions and while that's not terribly bad the do all this in the same code base and what happens is your
model the application grows and grows has more and more things that it does and since it's all the same code base since it's on rails there's the use of hidden dependencies between things so you do something like on week the CSS for our customer service for all well because on the assessors belong together at the very end that ends of 1 of the percentage at right perhaps and it's 1 of the team's decides that the UN referral section of the site is too slowly put a catch there's some hidden entanglement between referrals certain so this column searchable and these things become easier and easier to create as more and more people work on them and harder harder to identify because everything is on you also getting your business
logic entangled with real systems and of writing like really crazy stuff would you decide upon logically prove that the waters in the East Coast 1st factors they have like I How did you have rapid you ever unwind its way within to the test this week and it seems like this is rob and then there's features that seem to be really useful and turn out to be a really bad idea like suppose artsy once sent an e-mail after a user is created fully their method to run code after the creation of an active record there is schematic recall back so we do and and then another gene figures well known is in payment processor let's insert their records within a processor system while we're doing the marketing team in a marketing team is like you know we want try user creation science we don't use a pixel our website but would do the back and so we throw that into 1 not and then a 2nd marketing person thinks this working that sort which is a different marketing site and then in the 1st working version keep argue with each other and they can reach the conclusions and hearing is like final put the into the last battle later this is some problematic but what if someone now wants to write a test uses a user that energy lost profits in here this is really hard on why would we fire 1 of us working people and we get rid of 1 of these techniques at the stub the test and a modest out so they can work right so some good test becomes glacial which means shipping is hard and I will have that as a stopped scope which should show cues from things our term but because we have all these different things in the same application were connecting things that really shouldn't be connected right if we add a feature to our admin CS portal is very inefficient was a very terrible database queries take down a public website because all the same thing that's not good right simultaneous a difficult difficulties because possibly cause all those entanglements and no 1 likes working as a whatever worked on apples like that yeah it starts right and then you know you you leave me were not all herbs and motivated by the technology they were using but it's not fun to work so we prize was so Artstein writers advise themselves back to the beginning when they all were all started and I have this came from this model is that they created and how bad it was at the end have great was beginning to the end of terror and they think we want things to be decoupled that would be the solution if things had been the couple like different like services and things that would be the way to solve this problem so let's do
that was made by the services right now but that we want so we're do that the so but before we even start micro-services the teams like OK we'll do this we gotta do a little bit of that you know and background were 1st so we have to
figure out how long will last asking have lots of different you know services employ we've got to figure out how to do authentication how these things going to talk to each other in fear versioning organ put in the Ural would put it in a header but we have found that adjacent formatting just to make it objects to have a topological and will fall and I have that discussion make that decision and it was easy to the library like 70 of them in Ruby so you figure out which 1 we want use a Devlin have to argue about what is and isn't RESTful and how to interpret to be sensitive after we do that we also
available what services like do we actually need and and this is of maybe unsurprisingly hard because at this point we're you're getting things going you have some requirements hopefully some of and you told that they will change with you know in your heart they will so it's hard to know what actually to do but the team perseveres and they make the best decisions they can this experience in the brain pretty smart free later critters amazing my
serves architecture writers react front end of course it talks to a back and front ends because we don't we have front end to know about the particular services they so we use the back and performance that will then talk to an authentication service which will then talk to the wall so as we know what authentication will also be sharing in conflicting with each other that went on to the 3rd service and get consumer data is again that has to be separate from authentication server from roles and then we can render a page says hello bob now I know you thinking this is possible but it gets even better because we have used Dr. insulated US terraformed ball bat and of course we risen go to candle is that lots of about writing doubt so it's amazing totally amazing we spend some money right this that she got supposing that the engineering time and we we all know how much we get paid is not cheap we got a blog post of 100 uses a lot dishes and break it we think that a few persons need will show also we your and delivery actual value it is a whole lot that's right nothing nothing really show is there any money left if this were a start up that's a very real question like we always where we have we can do some math figure how many days is for all have a job I was on a non-starter thing someone might say hey what I just money to have these developers do nothing for 3 months of mediation from this project it's not that I know of course remember those services that we felt we needed well some because we all instances of prime symbol changes are not difficult we wanna say at let's say we want to add Bob's e-mail to our whole OK Filipinos and e-mail service and that's huge aim to make that change difficulties in now really hard because if we made the wrong decisions about services we have online all that and they the ones we should be made up from the beginning and not fun to work on and it's you at the beginning was deliver value the corrective in you can be because you've pre abstract all this stuff the and the people even if those people are a reason that this is happening and so again the principles so this team miraculously by themselves back to being again and the paler that microsurfacing is is in them and they remember how great it was to do the model is like it initially was so fast and easy natives crank up the stuff and so the thinking OK let's revisit that maybe take a
different approach to the problem was we let things get messy and we never cleaned up to this big masses compiling compiling on to so maybe if we pay
attention to when things get messy and then we clean up the mess before it's too late the that's the way through we get all the benefits of a model of and of this will get to omega services by clean up the mess and coupling cream services that way that things play out largely as they
did before teams people and things I
also happens now like parrots it is now too messy to continue we're going to fix we're not going to make it worse women now sir extracting services and all the stuff that we want to do that my courses now the whole team which at this point is somewhat large they can just stop and and do this couple reasons 1 of managing a large change into a single part this very tricky to the business or the software or whoever means that means things and keep going changes to be made in need of features to be delivered we did not doing to form a
tiger team right tiger team is the sum of its we take our best engineers and we get them on this task of extracting and coupling and all that stuff and now this is you know it's it's it's a bit of of problems of think about like noticing that's right is anybody ever clean the bathroom Mary so that the day after you've been about it you also raise your hands on it that's OK if you solve the problem in a way I don't understand what does you have thing about the day after you clean about it still looks pretty plate and the day after that cancels pretty clean doesn't change today but then when your roommates or a significant other friend comes over this year disgusting mapping of what you do is discussed in Africa and so that's just a bad thing like I mentioned you're coding lovingly created you have emotional investment and it's really hard to see that the thing you need is messy so we're starting way afterwards the tiger team person trot
tries tries events so they extract 1 thing but then the rest of the the sum also has place their events to an airport that right there's always some poor person in there cleaning it but then there's all these people using it so never actually cleaning is keeping the mess in the bathroom at this some sort of don't acceptable level of messiness and never executing point so that's what happens here is you've got these 1 really great esteem redevelop is doing all this stuff the other developers alike I don't do is challenge in this model of is known only like 1 of the thank you of so doing this
requires like the best engineers right that is not only the edges you have the technical capability was off but also who understand the business to make the right decisions we know it's rule work it's not it's not fun it's hard and it's you know I'm not something we would ideally want your best engineers working in afterwards they're gonna be very unhappy about the whole thing because it's not fun small seniors right they become difficult because more sort of just keeping things going on and trying to make a better on working bigger change become the label possibly never happen and uh maybe the rest of is OK be your best and brightest you put on the citing they're not going to be too happy when this is done some and they may leave that's not good and then again principles of again so our team somehow miraculously has gone before chants and solving from and they're like I don't know
what to do we try model we tried my services we tried model of the nucleon up and not making them as well as it did work what we must be fundamentally thinking about this problem in the wrong way so and they they think it's all about like a predicting the future right you you do this monolithic agile approach because you don't want pretty future so you just solve the problems in front of you and then the micro-services approach was like completely was predicting the future when making all the decisions based on information we don't know so maybe we need to think about
it a little more fluid manner right we know we can predict it will have to be blind to what the future holds we know kind of where we're going right we
know that there's more developers more code more features more chains that's that happened what they are looking those developers result we know we're going to be coming up and we know we want things to be decoupled we know what those parts are we know that's the way that this works the way that this can succeed is if things can be the couple so they decided OK let's not make a mess in the 1st place as a sort of number 1 rule were not in the business of cleaning the airport Batman is never going to make a mess the they also inside a few other things they think might help and they're making these decisions to enable the changes that they think they're going to have to make even though they don't know the specifics of this so they decided 1 rails at for business function were not making 1 apple as everything in it and we will win when a 2nd business function leads us to do something we put that in a 2nd at and that will naturally create some de-coupling but not the opposite into this crazy like Services architecture they also decided well leading to the couple things those parts of your business logic right so they decided they were not going to put the business logic in the Active Record models because of the business logic is in separate classes there's basically Ruby will be easier to extract when we need to it's actually not that much more work to just put them in some other class is really not a huge gain for lots of interactive record model so that figure that's a really good compromise and then they decide to be very diligent about identifying patterns the happen as they work so the this thing called the rule 3 to decide when to trade abstractions when to stop and fix problems when to create tooling of generally identified patterns of specific to them yeah so the rule of 3
is in a way different patterns you something once is this is not a meeting at making it easier you might never do again factor probably you do a 2nd time and you really think there's a package drawn line things so therefore that's a pattern right but it's not necessarily a pattern lots of things happen only twice so again you don't do anything different in fact you might just copy copy-paste things to do things in the less ideal because 2 times and have the 3rd time is about very time is when you say alright this is finding out while observing what we experience and what we've done that there is a pattern and were now going to take the necessary steps to make 4th 5th 6th times easier right and so you can see in this graph below here that the idea is you spend a little extra effort on time number 3 and that is to pay off times 4 5 and 6 and the reason you're doing that is because you've seen it happen 3 times and that's that this is like an engineering culture thing and everyone has to be on board with that and and you need to publicize that you're doing this because you are going to have to say hey I need to take more time on something and that so that we can scale RT and please business people trust that I know what I'm doing but it's not a big deal it's not a huge request to me sometimes you level to the rule to you know the Tenia well so the team decides yes this is how we do things right so here's a few examples
but you know the the technical rails out of create a generator and generate that 3rd rails at with the generator and then the 4th that is almost for free 32 region right a command line tool that generates the region scaffolding us so that the 4th and 5th RubyGems just be created not going easily but also applies to problems the time you are faced with making a messenger where the 1st couple times of agreements no big deal you you can handle them for the 3rd time maybe our front end needs are not being met by making a message acquire maybe we need something else from a from a person but also also for outages bodes support for times of ways about something maybe it's time to stop were doing and fix the problem right so this lets the team identify patterns based on their actual experience and not what someone running some blog posted in a conference talk is selling them to do so the team decides to let this play out so they made a decision that decisions about the specifics of the architecture they just created some rules and guidelines to help them know have changed so they made the 1st rails out public website use it it's not problem now because research team needs some functionality and so because they're not putting that in the public website making a separate rules that they create that rails up by copying the 1st of the sharing database which he knows this is not ideal but this this will be a problem later that's our problem now and they copy get directed models of because those active models of the business logic in them is not really much there and so keeping the 2 copies in sync is not a big deal because they don't really change that much so again it is making a reasonable trade-off they haven't been 100 essentially gene patents and is doing the simplest now the marketing team needs some functionality different business remain separate rails out but is the 3rd 1 so we make a ap generator use that create the app for the marking to this another pattern another 3 which is that we could be copying Active record models into the marking Avenue 3 copies of these accurate models of prominent in less extract those into a shared right it's not perfect but but whatever changes are made to the database will change the genome that about the genomes revision and then each team is doing a regular bundle updates so they will get it even if they completely forget to keep things in sync so not too bad and the feature need to make for marking was around promo codes and requires some logic to be both in the customer service and and the marketing at and it's going to copy for now again these are directed record models a separate classes and it seems like this can be a pattern but they're not ready for rule to yet so they the so later it turns out that the customer service application is very slow at searching for customers so they had a cash so that searches fast but they need a way to keep the catch of to date because customers are created in the public website not in the customer service and so then you wouldn't know the constant when the public website creates a person how we update our catch the perhaps how we solve this problem we could create some sort of service or we could prove database but that's actually turned out to be too slow for them so they decided upon it can be a common set up the rabbit and the message bus and then the public websites and message whenever a customer created or modified in the customer service will listen prevent message update its internal catch and so now these 2 things can talk to each other but they're still very coupled as long as the messages are happening everything is fine and no 1 team can easily break that feature and as a side benefit when we hire some of business intelligence people out because are consuming these messages and get real data out of itself without having to do anything on any of the engineering systems again more de-coupling because of somebody's decisions now finance you need something fortunately our rails app generator create displays are super fast and realize those gains of spending time before that's great the finance that means access to promo code information right that's something goes on accounting are books and all that but the team doesn't copy it and over and they they could make a jam like it did with the shared Active Record models but they decide this is simple enough that I think now's a good time for us to like see what it's like to make service right from making his early my preserves mimic 1 service and see how that goes fortunately because the proper logic is not entangled with active recordists regular code they have a perfectly defined interface with the service will look like so they set it up all of the other apps can consume that service instead of using the copy logic and accessing a database and as it turns out the marketing application no longer has any needed the shared database is always looking at was the promo code stuff and now that is hidden behind this service and a so we've actually can improve things decoupled from shared just you know what happens to us and of course the finance out can store all the data it once in its private the so what were designed this architecture who would sit down and be like God our ideal architecture is going to be some contemplates encode some regions are couple of private databases a shared database of radical he misses bus in and then some of them and a 1 http server no 1 would ever like design right but but I think we can see the advantages here at team is working on this marketing can make massive changes without breaking everything else like the ability to break stuff is very difficult of and because things recover lying on business areas that sort of the you know where change tends to have the
the team basically what they realize that the air was the 1st 3 times this time was that they follow the architecture of Spain diversity to create and then we'll be done that's not actually true what they realized is that the plans on the architecture of our process for changing changing allowing it to evolve in whatever way it needs to so they set up a few guidelines a few battles away to detect patterns in a way to responding to detect a pattern and let the architecture of the law however it means user serve the purposes right so
their prices of all of the escape time of everything is going I so what we want don't be blind to
the future right that something is predicting you can acknowledge you can read the future we kind of you can see the winds of change right right so that enables chamber that's where it gets confusing you don't write code that is the change you want to make in the future you write code to allow it to change when it needs to be and that's part of the enduring culture right the rule of 3 is a very way maybe there's a better way for you to detect these patterns but that's a great way to do it and acknowledge that the architecture is something that evolves it's never please but just omega Mexican volume was only commenced like a lot of good things good things have and so
that's all I've got something good thing I describe so that a great way to work in your our working that crazy attention in the bottom because I can make that happen but also a couple books you can buy for cheaper files have few free copies if you ask me a question that you know a question that I will give you forgot the of here um en fomenter so as it thank you thank you probably my thing you
Bit
Hardware
Rechter Winkel
Projektive Ebene
Schlussregel
Biprodukt
Skalarproduktraum
Code
Computeranimation
Soundverarbeitung
Teilmenge
Rahmenproblem
Physikalischer Effekt
Dichotomie
Unternehmensarchitektur
Stoß
Mathematisierung
Schlussregel
Raum-Zeit
Quick-Sort
Computeranimation
Programmfehler
Entscheidungstheorie
Kritischer Punkt
Kontrollstruktur
Information
Normalvektor
Unternehmensarchitektur
Shape <Informatik>
Subtraktion
Kontrolltheorie
Mathematisierung
EDV-Beratung
Schreiben <Datenverarbeitung>
Schlussregel
Ähnlichkeitsgeometrie
Biprodukt
Trajektorie <Mathematik>
Term
Code
Quick-Sort
Computeranimation
Entscheidungstheorie
Übergang
Verkettung <Informatik>
Rechter Winkel
Wort <Informatik>
Projektive Ebene
Softwareentwickler
Bit
Subtraktion
Mathematisierung
Code
Computeranimation
Entscheidungstheorie
Rechter Winkel
Reelle Zahl
Codierung
Speicherabzug
Projektive Ebene
Softwareentwickler
Parallele Schnittstelle
Softwaretest
Subtraktion
Web Site
Pixel
Wasserdampftafel
sinc-Funktion
Datenbank
Systemverwaltung
Versionsverwaltung
Kartesische Koordinaten
Physikalisches System
Mathematische Logik
Teilbarkeit
Quick-Sort
Code
Computeranimation
Energiedichte
Dienst <Informatik>
Datensatz
Web Services
Verschränkter Zustand
Reelle Zahl
Garbentheorie
Coprozessor
Modelltheorie
Figurierte Zahl
E-Mail
Objekt <Kategorie>
Dienst <Informatik>
Selbst organisierendes System
Programmbibliothek
Authentifikation
Dateiformat
Figurierte Zahl
E-Mail
Computeranimation
Entscheidungstheorie
Punkt
Web log
Mathematisierung
Symboltabelle
Primideal
Computeranimation
Homepage
Eins
Entscheidungstheorie
Dienst <Informatik>
Web Services
Prozess <Informatik>
Rechter Winkel
Debugging
Server
Authentifikation
Projektive Ebene
Modelltheorie
Softwareentwickler
Unternehmensarchitektur
Drei
E-Mail
Figurierte Zahl
Instantiierung
Dienst <Informatik>
Ruhmasse
Computeranimation
Dienst <Informatik>
Punkt
Software
Mereologie
Mathematisierung
Computeranimation
Bit
Gewichtete Summe
Punkt
Mathematisierung
Ereignishorizont
Quick-Sort
Computeranimation
Übergang
Teilmenge
Task
Mapping <Computergraphik>
Rechter Winkel
Modelltheorie
Softwareentwickler
Dienst <Informatik>
Rechter Winkel
Mathematisierung
Schlussregel
Information
Modelltheorie
Quick-Sort
Computeranimation
Entscheidungstheorie
Umwandlungsenthalpie
Lineares Funktional
Fluid
Abstraktionsebene
Mathematisierung
Klasse <Mathematik>
Zahlenbereich
Interaktives Fernsehen
Schlussregel
Mathematische Logik
Quick-Sort
Code
Computeranimation
Entscheidungstheorie
Datensatz
Verkettung <Informatik>
Web Services
Rechter Winkel
Mereologie
Mustersprache
Modelltheorie
Softwareentwickler
Unternehmensarchitektur
Figurierte Zahl
Web Site
Subtraktion
Web log
Gemeinsamer Speicher
Datensichtgerät
Mathematisierung
Klasse <Mathematik>
Versionsverwaltung
Zahlenbereich
Kartesische Koordinaten
Mathematische Logik
Synchronisierung
Whiteboard
Code
Computeranimation
Datensatz
Web Services
Regulärer Graph
Reelle Zahl
Mustersprache
Modelltheorie
Gerade
Schnittstelle
Umwandlungsenthalpie
Zentrische Streckung
App <Programm>
Lineares Funktional
Graph
Datenhaltung
Ideal <Mathematik>
Schlussregel
Physikalisches System
Quick-Sort
Dialekt
Teilbarkeit
Entscheidungstheorie
Verbandstheorie
Rechter Winkel
Beweistheorie
Debugging
Codierung
Server
Identifizierbarkeit
Information
Unternehmensarchitektur
Faserbündel
Message-Passing
Prozess <Physik>
Maskierung <Informatik>
Mustersprache
Automatische Handlungsplanung
Gesetz <Physik>
Unternehmensarchitektur
Computeranimation
Rechter Winkel
Minimum
Mathematisierung
Mustersprache
Güte der Anpassung
Mereologie
Schlussregel
Spezifisches Volumen
Elektronische Publikation
Unternehmensarchitektur
Code
Computeranimation

Metadaten

Formale Metadaten

Titel Can Time-Travel keep you from blowing up the Enterprise?
Serientitel RailsConf 2016
Teil 73
Anzahl der Teile 89
Autor Copeland, David
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.
DOI 10.5446/31501
Herausgeber Confreaks, LLC
Erscheinungsjahr 2016
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Hindsight is 20/20, and there's a lot of advice out there telling you to do what the author wishes they had done at their last company to avoid disaster. Let's try to follow their advice and see where it lands us. We'll take four journeys from rails new into a reasonable future. The first three, “dedicated team pulling apart the monolith a year later than hoped”, "nothin' beats a monolith", "services from day one" will blow up the Enterprise, while the fourth, “take reasonable steps to let the system evolve”, won't.

Ähnliche Filme

Loading...