Lessons for frontend development at scale | Hannes Obweger | #LeadDevBerlin
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.
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.