All. Right well, this is awesome. Hello. I'm. Hannes. And, it's. Correct, I am a engineering. Manager at Atlassian. Specifically. On Kyra and. There's. The office hour later so you can you can come over and we have it have, a chat so. Over. The past couple of years my, team and I have been busy with giving Cheever a big UX, update, so, we're moving JIRA from something like this to. Something like that. But. Know. What not a joke but. But. Keep in mind that sheera is also a 17, year old product, that's on my personal, top. Con Top Gun to Top Gun 2 timeline. JIRA. 1.0. Is actually, close at the top gun. So. My. Team and I also took the opportunity to, you. Know give. Give give a bit of a technology. Update and move. It from from 17, years of JavaScript. History. To. A nice and tidy modern. Front. And stack now. There's a bit of logo. Born left, it right of me but don't, over index on it it's it really boils down to a reactor, plication I could stack, reacted. The fabric, that, ties it all together, and. Our new react, based front-end, repository, is. As, we're talking well, beyond, a million, lines of code and has, more than 400, contributors. In total and roughly. 250. Contributors, every month so. This is a solid, piece of software, but. And. That made me made, me reflect a little bit, because. In. The past, the. World looked much more like this right, where. All the all the complexity, all the heavy lifting all. The high textual challenges, all, the system, design was. Done in a back-end the. Fronton was a relatively, lightweight relatively. Sin layer that, was primarily concerned with making things pretty. This. Is changing. Today. We see a lot of the complexity, that, was traditionally. Associated, with a backhand. Also. In the front-end of, course, the backend didn't get any easier. But. Now keep in mind folks. Over. The last. Over. The last 30, 40, 50. Years a lot. Of incredibly. Smart minds have, been thinking about how to do software. Development at, scale right in the backend but, and it, would be stupid, I want to say it would be irresponsible of, us. Do. Not leverage, their. Knowledge their ideas the ideas, and see, how we can transfer. Transform. Them over to, the front end all right what can we learn from that. And, this really brings me to that do they do the idea. Of the talk today and so what I want to do is I want to share six six, stories, six, lessons that, we learned over the past two or three years, and. Actually want to categorize them into one of three categories where. The first category, is. Adopt. So, that's something that works in the back hand and we can just, move it over to the front and easy done. Second. Category, is to resync, so these are these are lessons, that we can generally, apply but. We may have to change them a little bit and and the, third category is stop this, is something that works in the back hand but it just does not in the front that does not work in the front end nope. All. Right that's the plan for today so, let's get into it. Lesson. Number one. Decomposition. I think. A lot of people in, the audience you can relate to that right like we have these big monolithic, legacy, systems, and we, want nothing more than, to. Decompose. Them into into micro services and, micro services are great we love them they have a lot of fantastic. Qualities. They. Are well encapsulated. They have a clearly defined scope, they. Can be composed together into, something bigger and. These are fantastic quality. Right Desai I want, to say Universal engineering. Qualities, that go well beyond, software. Development. And. We, obviously also want them on the front end interestingly. Enough there is a concept. In the front that that implements, these qualities, pretty, well and. That's components. So. When to cheer developers, talk, to each other they, really talk about the Geo UI in. Its, entirety, right, they would talk about, the.
Navigation Come. Which takes care of navigation. Concerns at this owned by the navigation, team, what. We talk about the. Board component, which takes care for the board concerns, disowned by the board. Already. We'll talk about the issue component, which shows, issues one but issue te and, that's a recursive, concept right you can break that further down you can talk about the header the sidebar. The main area. So, another way to look at components really the de provide, the. Visual representation. Or. The state management, or, the beta fetching, concerns, of a, particular of a, particular feature, right of a particular concern and. Most importantly. Components. Encapsulate. This complexity, and expose. All the API is through, well-defined. Through. Well defined property some I'm leaning, on the react lingo, here but it's it's it's actually a concept. That goes beyond react and that's, a very powerful concept I said, if you think about the JIRA issue view that's a reasonably complex UI right, if I as a developer want, to mount an issue, all, I need to do is well. Mount an issue component, and parse, an issue key beautiful. Right, and. That, that concept is actually very very old you can trace it back to do mootools, in the in the early 2000, some probably beyond, that but. I think who reacted the first framework that truly made the syntax, and truly made it accessible to a, lot of developers I think that's a huge achievement. There. Is another, quality of microservices that. We really, really like and that's. Independence. What, I can. Write my micro service in Kotlin, and run it on AWS, you can you write your micro service in I don't know Haskell, and and run it in Asia that, that's all fine that all works that's good right we love that that's a that's a great thing and, that sparked a really really interesting conversation. In the front and community and test it. Goes under the label of micro. Front ends, so. The idea is that now. That we have these nicely encapsulated. Components. It's not too far of a stretch to, say maybe we can push this a little bit further alright can, we have one. Of these components be written in angular and not a compound. Be written in ember and the third one maybe be written in vanilla. JavaScript and, can it be hosted. Independently, I. Love. This discussion, this is this is a fantastic conversation to have, but, we always got to keep in mind that, the front end is is unique, but there are differences between the back end at the front end and, they often boil down to, the. Same the. Browser. The. Browser today. Provides. A shared. Runtime. For. All code, that runs within the window the, browser does not have a notion of code isolation. Within, a window The. Closer that we get here is an iframe and, I will touch on that in a, second. So. If one components, wrote an error everything. Blows up right, if one component is slow everything. Is slow that's, a that's a pretty big difference at the back end that we need to be mindful of and the. Second thing is is. This. There. Is a human. Being in, front, of the browser and. That. Human, being is the reason, why all of us are here but, at. The customer and, the. Customer expects, a fast consistent.
Delightful. Experience. And I. Think we can all agree that, creating. A fast consistent, delightful experience, is bloody hard right. And, it becomes only harder. When. The different parts, of my of. My UI, would, be in the implemented. Completely independently, and run completely independently it's not impossible it's, just really really hard. At. Atlassian we, we, don't really see. Components. Versus micro front and as a black, or white discussion, I think there are there are million shades of grey between. Between them and it's, really a spectrum, of independence. Right how independent, do. You want to your, units of code to be and, that's something that you can move I can force on it that's something that you should find the right point for, your application. So. Lesson, number one be composition, I, could. Take it as categorize. That as resync. Right, the model is the model is here but, we need to rethink it a little bit. Second. Lesson that I would like to touch, on is, don't. Big Bang right. I don't I don't know about you but if I see kind of a monolid, in front of me I would want to take a really really big ham I just smash the thing in. In, two thousand pieces but, that's not really, how it works so I'd impressed is what you want to do is you want to slowly carve, off, from. There from the edge of the monolith until it gets smaller and smaller and smaller and, ultimately. Disappears. In, the, front and this is similar but, it's. Same same but different right so that lesson we talked a lot about. Inside. Out and, outside. In, models, of, front. And modernization, so what's dead. When. You start. A modernization journey, on day, one you're. Sitting in front of a legacy front, end right this is where you start and, it, is very natural and a very reasonable. Thing to do to say look I'm taking, one component, of that URI and I'm, replacing that, one component, by. A modern. Counterpart, that, and, that something is very well supported, by react it's a very well. Proven. Patent so. What you have is you you get this dissolution, of legacy code with little islands, of modern code these, islands can pick and pick and pick up and. At. Some. Point you will notice that this, island kind of start bumping against, each other and it all becomes a little bit awkward and you get this this itchy feeling, that, something is not right and, that's.
A Really, really good point in time to think about, turning. This equation around and transitioning. It to an outside-in. Model. Here. The. Foundation, of your front-end, is it's fundamentally modern. Right react owns the routing, react, owns the the page layout you may still have islands. Of legacy, code but. They are getting now smaller and smaller and smaller another, way to look at that is as, a. Complexity, curve right and inside out model it's really easy to start you really just replace one component, by another one but. It gets harder and harder over time with. The outside-in model you need to make a lot, of really really, hard and really influential decisions, early on but, then it gets easier and easier easier, the big challenge I think is to find a sweet spot right we. Can kind of dive below. The wave. So. Lesson number two don't Big Bang again. I think it's something that we can absolutely learn, from the front end again. Something we need to rethink a. Little, bit. Lesson. Number three. Scaling. Vertically, and horizontally. In. The back and this is a very very well-established mental. Model right where you, scale. Vertically. By, by. Kind of getting a bigger and bigger and bigger machine, and you, scale horizontally by. Just getting more machines and, typically, you start somewhere in the in the bottom left. Corner and kind of you slowly work yourself, up to, the top right, in. The front and the world is a little bit differently different, because. By. Definition and, necessarily, your. Application. Runs. On millions, of browsers, all, over. The world. Which. Means that large parts, of this chart are, simply inaccessible, to you you can't go there right you radically scale, horizontally this, is really how the web works. On. A vertical axis this. Is kind of the customer, hardware alright and unfortunately. We don't have a huge amount of control over that right, the only thing that we know for sure is that as developers we. Are typically privileged, because that's a four thousand dollar MacBook and, our customers don't necessarily, have that, so. All that we can do is assume kind, of a reasonably. Lower end of our, customer hardware which, positions, us in the bottom right corner of the, scalability, chart, so. There's no call to action here it's just really really important, to understand that I think that's really the gist of all, kinds, of web performance engineering. At. Atlassian we also think about vertical. And horizontal scaling. A little bit differently, where. We call refer, as, horizontal. Scaling, if an, application gets more and more routes, more, and more distinct, experiences. And. Vertical. Scaling. When. These experiences. Get richer, and richer and richer and, more and more complex and more and more powerful. And ultimately you end up with a large amount of very very complex, experiences. The. Interesting thing is that on the horizontal, axis you can actually solve a lot of these things on.
A Platform level. So that when you're doing you know everyday feature development you don't really need, to bother yourself with them too much, when, the vertical axis is a bit hard all right like you hear you really rely on education. And conventions, and I get back to that a little bit later so. Scaling the vertical and horizontally. Again. Something that we, can absolutely learn, from the backend again, something that is needs. To be sort, a little bit differently. All. Right halfway through less number for. You. Oh. Yeah, you build, it you run it right. So, in in, the past. We. Really, liked building, walls, across. Across companies sometimes. Also across cities. Where. On. The. One side of the wall we have the people that write the code and. Developers and on. The other side of the wall we have the people who actually run, that code in production let's, call it operations, and what. Developers really like doing is they kind of you know they package up their their. Artifact, lift. It up and. Throw. It over a wall and. Stop. Worrying about it. So. That's not that's not a particularly, cool model right and over the last 10 years we kind of get rid of that a little bit and kind. Of try to bring these two, parts. Of the equation together, not. Only to bring them together but really to merge them, right this is where the term DevOps, is. Coming from. And. This, is this shift. Towards, DevOps. Really. Really. Improved. Our our game in terms of kind of reliability, and, operational, maturity right like service. Level indicator, seven service level objectives. 24/7. On-call post. Incidents, reviews. Progressive. Rollout, and rollbacks. Anomaly. Detection for. A lot of companies these are kind of table stakes today which is awesome. Especially. In the services, world in. The. Front end, the. Word often really, still, looks like that well, not exactly because, DevOps, is cool and we get rid of operations, so. It's now more like that right throw it over the wall and then don't worry about it and. And. And. And that's not cool and I, think it's, really our job as engineering leaders to do, start thinking, about keep, thinking about that right and kind of level. Up our game here a little bit and and, close, that gap. And. I want to be perfectly frank with you folks it's something that at last and we we struggle with and something that keeps me up at night so. That's something we're definitely working on. I'm. Working a lot with our, service. Reliability engineering, team SRE team and. We. Realized, that both on the back end and on the front end it. Often boils down to very, very simple, simple, question a simple challenges, right and that, is how. Does the you and. You build it you run it relate. To the it right, what what is that saying in between and that's. Really. Ownership. And. I. Can't I can't iterate that enough ownership. Is the most critical thing that you can do it for, engineering a scale on, the day where there's a single line of code that doesn't have an owner this. Is a five alarm fire this, is escalation. So. Ensure. At Atlassian we are very very open, later on ownership and, we pushed it so far that we actually codify. Our, ownership, so ownership, of code, lives, in code. How does it look like. So. Cheers. Structured, it into modules we call it packages, in the front-end and fibre. Package, we are very very explicit about who owns this, package you, can see here there's, this piece. Of Chasen here that says that this package is owned by KitKat. And. This, is actually tooling in forest so there can't be a single line of code in sheer affronted repository, that is not owned by a team. And, this, is actually pretty cool it allows it to do pretty sophisticated tooling. So we can for example automatically. Add people to be ours and ping them on slack and stuff like that pretty cool, next, step here is really to transition. That in transition, this into the runtime. So. Imagine you have this this, composition. Of component, this nesting of components. Well. We can do now because we have that information our code base is we, can. Explicitly. Assign. The, ownership at, runtime, to, this component now, this is nothing that you need to code whether you can do that via a translation. But. What we can do now is if, there is for example an exception, thrown somewhere, in a component we know at the runtime who. Owns that component and can. Paige team. In. This specific scenario that. Error could also it could be in that component. Owned by by Team KitKat but, it could also be an integration, problem right maybe the parent passes down the wrong properties, in, this case we can just page the parent or. We page both of them really because we probably wouldn't know at runtime, and, this is really only possible because, we have codified, our ownership. So. You build it you run it what do we do with that I oh I. Think i classified, as as resync, but, but, really this is this is an area where we are probably the furthest behind, so.
More. Than resyncing. I think we really need to think about it to start with. Less. Number five being opinionated. So. You can have all these teams in, in your company right all this rocket scientists, with. Clear ownership, with clear, responsibilities, beautiful, but. We always need to keep in mind. That. The teams, that work on your front end, operate. In, a, shared, limited. Resource. And. This. Shared limited, resource, is. The browser, and. In. The history, of mankind. There. Has really been only one way, to. Sustainably. Consume, a shared, limited resource, and. That is by rules, and conventions. So. I can only encourage you folks, to. Think really really really, hard about. The patterns practices. And technologies, that, you want to align on as an, engineering team, in. JIRA, we started, an initiative called tangerine this is actually the slide that I used to pitch, the program. And. We. Managed to transform. The basket. Of fruits that our repository, was a while, ago into. Something that looks a bit more like this all, right so every. Package is still is still different of course but some of them are smaller some of them are bigger some of them are. Sweet some of them are a little bit sour but they at least follow the same basic, conventions. We're. Quite proud about that so we will looking. At the open sourcing it not. Not, quite there yet but stay, tuned. So. Being opinionated I think we all our opinionated, right but I would argue that in the front-end you, probably want to be even more opinionated. Which. Brings me to my last lesson. Automation. You. Can have the. Best rules the, best conventions, in the world, they. Are completely. Useless. If. People don't follow them and. Engineers. Actually want to follow good. Patterns, good conventions, the thing is we're all humans, but, and as, humans, we make mistakes we let things slip through that's. What what makes us human. Robots. Don't. So. That lesson we're borderline, obsessed, with all kinds of static code analysis, specifically. Lint we, actually have a huge, amount that don't don't read that but should indicate it just. Trying to indicate that we have a huge, amount of custom, years limit rules and other tools that, implement. The patterns and practices and technologies, that we agree on I can, only encourage to actually look into coding years limp rules it is it is it is pleasure it's great fun. Just. To brag, about one. Of the routes that we have my favorite they, called the so called import order rule so what you're seeing here is, a. Probably. Too large but that's a different story. Javascript. Component. Javascript. File and you can see it imports, a lot of stuff and there. Is no structure, whatsoever right there are relative imports they're absolute, imports there's first, party library imports there are certain, library imports I hate, it. So. What. You can do in insurers, you just press, save and you. Will get this. Look. At that. It's. All it's all nice and tidy grouped. Cement. There's some you know relative, imports absolute imports, party, libraries party libraries there's a bit of semantic sorting in they are beautiful, I love it. There. Is also tool that we developed ourselves called, stricte and i won't, go into too much detail but it's basically it's, like yes lint but, for a file system so one of the roots that we have is the so called project, structure rule again don't read this and we, really just. Indicating. How opinionated we are so what this rule is doing it describes, in quite, a bit of detail what. Folder, names and what file names you can have in your package so. This really means that all our packages, all our libraries look, exactly the same I love, it. So, this actually is open source already so if you're interested in that and want to contribute please, have a look at. Slash. Stricte. So. Automation, I think we all do some level of automation today again, I want to argue that in the front end you want to do it even more.
Which. Brings. Me to my final slide so, we talked about 6 6 less than 6 to do, we talked about decomposition. We, talked about do. Not Big Bang we talked about horizontal scaling, vertical scaling you build it you run it being. Opinionated and, automation. And, you. May have noticed that I was a, little bit cheeky when, I introduced, these three categories, because. They really all fall into the same category which. Is resync and I. Think this is this is this is really important right because I think in all, of these areas we, can learn from this huge, body of knowledge from this huge body of experience, that we have assembled in the back hand over, the last 30, 40, 50, years but. There's the same time we need to be mindful right, there are fundamental. Differences between the front and in the back hand and we, need to take them into account. Thank. You very much.
2019-12-22