Independent Deployment of the Frontend with Docker and Kubernetes

[Music] hey everybody super great to be here today thanks so much for having me I'm going to talk today about independent deployment for the front end specifically when it comes to single page applications and one way that you can achieve this using tools like docker and kubernetes so before I talk about what's possible I want to talk about where we are today probably you have a diagram in your office that looks something like this or maybe you've read it in an architecture book at some point the base of your diagram it begins with your microservices writes each of these lives in Nice bounded context they may be owned the data that's you're operating on they can be deployed and maintained independently and you have an autonomous team that owns and operates them end to end so far so good on top of that we have maybe an API gateway that handles how you're going to access these things and then on the very top of this you know immaculate architecture diagram is the UI layer I like to think about it like the icing on the cake because that's kind of like the best part but in reality when you look at this and you see it in in an architecture book oftentimes you think is that all you're gonna tell me it's just like this box at the top and that's that's the only details I get out of it and it can feel like you know these days the UI layer is becoming responsible for more and more and yet all we get in terms of information on how it should be organized is this one big box on the top and a natural question that can come up is why didn't we just naturally start to break this down like we did microservices who here has ever been asked by your boss your CTO why can't we just have Micro Services in the UI anybody has have you been asked this I think it's completely normal right and you're like it doesn't work that way right and there are a couple of made reasons for that the first of which being well cross component communication is a bit different right we have different frameworks we're not just talking with data but we're talking also with more complex objects we also know that visual consistency is super important for us maybe you know you see an API you get some document on it which was made by back-end team it's in a micro service and it doesn't really matter that it's inconsistent maybe to you as a developer you care a lot but the user is never gonna see that inconsistent API so that's one way that these also differ and finally most of our bill tools assume that everything that I need to build and run my app is gonna be available at Build time but that's not exactly the way we want to build distributed systems right so all of these things impose upon us some different limitations that make them unique when compared to how micro services work in the world of back-end and as we have probably all felt a bit if you worked in a team that starts to grow and then it keeps growing and growing some more you're like is this gonna be sustainable to keep doing things that way that I have always been doing it becomes challenging because you have one way to get to prod maybe we'll use some strategies like feature toggles or you practice trunk based development but the end you've got one path we also have the topic of getting buy-in from more people the bigger the codebase the more developers the more people you need to get on board when you want to make a change and sometimes this can lead to stagnation because getting enough people on board is really really hard to do it also creates a single point of failure how many times has it happened that you deployed something and a totally unrelated change that you promised to QA was not gonna affect anything else resulted in a totally random bug you just could not possibly foresee and you might be thinking tests are the answer to this obviously mónica if you had the right test pyramid all filled out with all of your tests well then you could just deploy all the time and you wouldn't have an issue but we all know that having a reliable test especially the higher you go up in the pyramid it is very difficult to do that and you're gonna spend a lot of time maintaining them we also have the topic of shared tools some people love to maintain webpack I don't that's okay but but do you really want to have people in your team and their only job is to maintain and you know upgrade everything all the time with all these new releases that are coming out and at the end things just get slower you have more people more communication and things start to slow down and the reality is we're working against Conway's law as you probably know if you've heard of this term before when you design a system you're very likely to copy the way that your teams and communication structures are set up in your company but here we are having this cross-functional teams that are men's who own something in two end but that vertical slice of ownership ends at the front end right and then they need to go into the UI layer to communicate with all these people and get the job done so how do other people solve this problem it's the buzzword of I don't know the last couple of years micro front-ends rights it sounds a very sexy you're like it's micro like micro services but for the front end and your boss loves it right because they're like finally you're listening to me and yeah it's it promises us that we can decompose the UI into blocks we can deploy individually sounds like the panacea to all of our problems well as you may know if you have ever watch to talk about micro friends and guessing a lot of you have there are so many different approaches no two companies do it the same and sometimes it can be hard to find out is there a standard or best practice or anything like that and and the main question the main thing that distinguishes between them is where does integration happen and which point of integration makes sense for you is going to depend a lot on the requirements that you have so you can do this from links you have one app it links to another app through a hyperlink that's micro front-ends for some people that's very nice it's probably the technically simplest way you can get away with it you also have built time integration this is common in a mono repo so I have all my nice packages but when I build it all comes together because that's how my tools are organized and then I deploy everything to production is this a month is this microfinance maybe up to you to decide you also have server-side integration so the server's responsible for bringing together all of the artifacts and you have client-side integration so I click something I request something I put it in the Dom more or less all of these different kinds of approaches have their own benefits and their own drawbacks I don't have time to go into all of them and maybe you'll learn more about that tomorrow but the fact of the matter is when I researched a lot of these things I felt like they really neglected a lot of the things that we believe in front end are kind of important right we want our bundle sizes to be reasonably small we want a good user experience so people don't need to reload the page when they navigate we want that the developers experience is really great because we are so spoiled in the front-end for amazing tools and when something doesn't work just the way we wanted to we're gonna complain on Twitter what about micro services I mean one of the things that I found a lot when I looked at these solutions is we kind of took the micro from my cursor verses and we thought that was enough but in reality there are so many best practices and great ways you can shoot yourself in the foot by just breaking up your app willy-nilly for example development and production parity so many of these options just say I develop my thing I'll see how it looks once I deploy it I don't really have a reasonable way to run it on my local machine and deploying independently maybe there in different packages but they're gonna get together at Build time and we still tend to centralize a lot of these things so this made me sad because my boss asked me Monica can't we have micro services for the front end and I said I will try so in the meantime I found all of these things and I was not super happy with them so meanwhile at my company we started to introduce a suite of new tools the first one that we began to introduce a stalker how many people here are running docker in production okay so this is like actually more than I expect it to be honest which is pretty cool so this talk is even applicable for you in your personal life and so darker allows you to bundle together your application in a way you can distribute it and what's neat about this as developers we can read our dockerfile we can ship it and we can actually have control over the image the things that are installed on it and so on that's pretty neat then on top of this we have kubernetes and kubernetes is one of these things that is infamous for being hard to explain it's billed as container orchestration and what this basically means is I have containers and I need to control them somehow they need to talk to each other they need to replicate I need more copies maybe one of them goes down and I need to bring them back up again and kubernetes takes care of that for us and one thing that is super cool about kubernetes is that you can define your infrastructure in yeah Mille so it's actually in data so it's lower on the ladder of abstraction than if you were to program all of it and not write any tests for it so that's kind of cool and then kind of coupled with kubernetes we have helm and helm gives us a lot of capabilities but one of the most important ones is that we can take a lot of the repetitive bits out of our manifests and we can put them into variables that we can later interpolate depending on if we're in dev we're in production or some other environment and I should mention both both kubernetes and helm can do so much more than we need here but something that I think is so cool about this is that you only need certain parts of each of these things to achieve what we want to achieve so you don't need to know like the deep depths of kubernetes in order to accomplish something meaningful so looking at this and spending some time really learning this I thought can this help me is there some way that the things being introduced by dr. Cooper Nettie's and helm could some of some other things I didn't really like about the micro front-ends approaches that I had seen so far so looking at the basic anatomy of a web app I mean I'm sure a lot of you guys are working on Web Apps that probably kind of look like this so you have your site navigation and you have the main stuff right it's like pretty standard and I was thinking to myself why can't I just take this this part on the outside the host application it's going to be deployed the way that it would be absolutely anyways run inside of our kubernetes cluster but I can take out a part in the middle whether it's one page or another page and I can make this independently deployable I don't necessarily need to deploy my entire app together because this this fragment is a component it needs some data but more or less it operates on its own so how does this actually work and there's a concept in kubernetes called ingress and ingress basically allows you to route traffic that is coming from the outside Internet and given a hostname and a path you can direct this traffic to a service that is living inside of your cluster so I was like ok I just bring up a service for each of these parts of my application and let's see if it works so I want to show you guys actually how this works in code and go a little bit deeper we're gonna start by looking actually at what the app does what kind of communication is possible and we're going to look at that in the browser then we're also going to look at what does it look like to bring in a component from somewhere else from from another server then we're gonna look very briefly at the configuration there is a lot of llamó you can see there's there's a lot of data here but we're gonna see what what interesting bits we can find and if the internet works we're gonna do a deployments so let's let's give this a shot and so first things first let's come over to our web interface so here you can see I have two boxes so I have my host application here and I have my fragment application here okay these things are both coming from different services that are running in suit side of my kubernetes cluster what's neat about this is that from the user standpoint it's completely normal I'm able to send data inside of my little fragment and I'm able to do the same from inside my fragment to the outside so I have bi-directional communication I want to do things like styling so I'm able to do this here I'm using CSS and J's but you can also ship separate assets if that's something that you want to do how does this actually work well when I go to a specific route I'm going to get some information I know this is so tiny does it get bigger it does I'm here yeah so so I'm here in my in the the route that is going to my service and this gives me information about the bundle I need and the name of the component and I can just load that JavaScript cool what does this look like now in code so here you can see that I have two totally separate repositories if I go into one of them you can see I have everything I think I should have here I have my disk I have my node modules etc and when I actually open up my two separate files for the first thing that you'll notice is I'm actually using a helper called async component which is going to create a component for me and what's neat about this is yeah I'm gonna be loading everything I'm going to be loading everything remotely but ultimately this component operates the same way as literally any react component would I have my fragments I'm able to pass it in data I'm able to pass in callbacks exactly what you would expect so from the developer experience standpoint it's actually not so different than working on a normal react app despite the fact that all of my tasks and everything is running in a local cluster on my machine and this is actually inside of docker at the moment and the way I get it in is by using mounting the the disk directory into the container cool so what happens when I want to make a change so I want to change this message from hello beautiful people - hello jeaious Congress okay I want to write this and I want to see how this actually works so you see it made this update and even though I'm running inside of docker the change is instant it's exactly the same as you would expect nice so let's actually let's change this and let's deploy it so I once you actually add whoops add this and well that's fine I can do this hello the best commit message you've ever seen promoting good good practices in public as is my sacred duty nice so we're gonna push this and we're going to come back to this and like to in like two minutes once the deployment has happened in the meantime let's go back add two to the talk itself great so right now what's happening is this is going to run inside of circle CI it's gonna bring up a new pod that contains my code what are some of the winds that we get simply by having this set up the first thing is that we end up with better technical autonomy for our teams imagine you're in a team and you have the opportunity to define for yourself what what kind of machine am i running on maybe I don't want to use node maybe I just want to use nginx but I get to choose you also have the fact that you as a team get to own a fully vertical part of your stack so you own not only the micro services you own the tooling you own what's happening in the front-end and you actually get to own this slice as opposed to needing to go there and kind of like barter with all of the developers over what gets deployed next you deploy one thing at a time like really one thing not one massive thing but one one part and a major win for this is that you have the option to have more granular and safer releases so instead of rolling out your whole app at once and maybe doing that gradually you can roll out individual parts and if you're working in a business scenario where being up all the time is super important like in my scenario I'm working in finance it is so important that things don't go down so being able to make them smaller and less risky is very very critical you also don't necessarily need to run the whole app right so we all know things like web pack things like just they get slower the bigger your app gets so what this allows you to do is bring take out part of that and run and operate on a smaller piece and finally you don't have to take your whole app and do this you can take just the parts that are interesting or relevant for you with the places you might maybe want more safety or more autonomy you can take a page a section an individual component whatever level of granularity is appropriate for your scenario all right now we get to the danger zone I think this is something that is really easy to have happen if you apply all of the front-end best practices you're familiar with and you just take them and you say I'm going to keep doing that but then I'm gonna deploy this bit separately you know you kind of don't get to don't don't get to have both parts so there are just a couple of small points I want to make that will help you kind of change your your mindset a little bit in terms of the architecture you need for a setup like this the first thing is that central configuration is something we want to avoid when it's feasible in my example we are using a router that is still in the house application but as this grows and scales there's a good chance that we would want to take this out and deploy it separately then we want to also separate code that changes at a different cadence if you have one team in the code base in some area that is moving really fast super experiments or you have another team that is maybe more cautious because their code is much more sensitive if something goes wrong there's a good chance that you want to separate these things because otherwise you will have either technical conflicts or team conflicts and finally when it comes to having consistent UI if this is something that is important to you I would suggest to invest in either building a design system or using something that already exists and not relying on custom CSS because this is just the path to disaster and all right so at this point in the talk I want to answer a question that is probably on the mind of at least 50% of the people in this room if not more and that is this one is this totally over engineered so the first time that I ever explained this concept to another developer he's working at a different company with quite a different set up and different size he told me it sounds like dropping bombs on ants and I was like okay I can relate to that I can understand how you feel and there are a couple of things I think you should just keep in mind when you're evaluating whether you want to break down your your large application the first thing is that your solution is so contextual there are so many talks that are going to be happening over the next rest of the conference and there are different solutions for different companies with different team setups everything is unique so whether this is a right approach for you depends on so many factors you don't need to think you know because I'm watching this talk because I'm up here on stage that this is exactly the right solution for me it depends a lot on context the other thing is that the tools are not the end game so doctrine kubernetes are very cool and definitely something I would encourage you to look into but let's be honest maybe they're not even going to be here in five years maybe we're gonna have something way better by then I hope so I mean that's the point of technology right we keep advancing and if we just get married to the idea of how using these tools we're missing out on the benefits which is that we can architect our application differently so that it's more modular and more resilient to change in different areas and finally as I said it's not all or nothing maybe look for some opportunities in your app and say hey would this benefit from more safety or more granularity or more autonomy so let's have a quick look back at our deployments internets please if anybody is on the speaker internet mic please stop that oh it worked that was surprising okay fabulous okay so our message has updated okay and if I run cube CT I'll get pods this is the command that is going to get the pod pod is what wraps a container in kubernetes you can see that my host application has been running for 11 days but my individual fragment has been running for only 3 minutes so you can see I was able to deploy that part of the application totally separately from the main app nice cool so I just want to come to the last point here the last thing that I really want you to take away from this talk it's not that I think that micro front-ends whether it's the solution or any other solution is absolutely the right choice for everybody as I said there is context there is the way your team is working there are so many different things it's also not that you should drop everything and learn doctor and kubernetes because those are cool technologies but maybe they want to be around forever it's more important instead than I think we as developers who are working on the front end be open to learning tools from different areas that aren't necessarily created by our own community and I want to encourage you guys just to be open-minded and to go out sort of your comfort zone in order to really grasp what possibilities are there for what I want to build so many times when it comes to operations deployment we say it's ops problem and by giving this away to them the reality is is that we miss out on a lot of chances to optimize things and to understand what kind of capabilities could be in our hands if we just decided to learn the basics of these tools but maybe not every front-end developer is so interested in but I hope why you're listening to this talk is because you're different you're interested in these tools and I would encourage you it's totally attainable you can do it and thank you okay one last thing and I have some resources here just if you are curious I'll also post the sample code up on github later and if your interest in this topic do attend tomorrow's talks there's going to be a talk on micro apps and there's going to be a talk about dr. Cooper Danny's anode which are going to go way deeper into those topics so do check them up [Applause] [Music]

Channel: Coding Tech

Views: 32,177

Rating: 4.9410682 out of 5

Keywords: front-end, docker, containers, kubernetes

Id: Td7w0_nD5_4

Length: 24min 22sec (1462 seconds)

Published: Wed Aug 28 2019

Reddit Comments

[u/prof_hobart]

As far as I can tell, there's two separate problems she's looking to solve for a microfrontend

• pulling the bundles for sub-components from different locations
• merging them seamlessly in the UI of a single page app.

It sounded like Docker/Kubernetes was providing a solution to the first bit, although any form of gateway that can route subpaths could presumably achieve the same thing.

It's the latter part that's far more interesting to me as it's a problem I'm actively trying to figure out a sensible answer to, and that seemed to be quite quickly skimmed over. It looked like she was using asyncComponent - is that all it takes? And is this the standard/best way to achieve this?

[u/nickthemagicman]

Why not just host the front end in an s3 bucket?

I might be missing something.

[u/nickthemagicman]

If we're putting individual react components into docker containers...what about putting each letter of a font into a docker container? That way you could dynamically provision your fonts with no build time performance hit?