 So my name is Mattel Today, I'm gonna speak about components from microservices and front-end So today my thought is gonna be a long talk Hopefully hopefully it's gonna be a little bit interactive. So I'm gonna try to ask things to you and We're gonna see how it goes The main goal of this talk for you I think is to be inspired by our case study. So today I'm mainly Going to speak about our experience about The company work for we decided to go to continuous delivery and to apply a lot of practices a couple of years ago And today I'm gonna tell you a little bit about the story what happened what I think we did right what I think we did maybe less right or wrong and Probably I think I will be happy if after this talk you will be inspired to See if we can do something like that in your company or if you think about this approach to be interesting So let me introduce myself. I am a software engineer. So I've been writing codes of since I was 15 so more than an half life ago many years ago and I like technology sometimes I speak in conferences. I mainly speak about what I do because I I Okay, oh, yes, sorry, I've been covering these lights in myself and I Usually speak about what I do. I I am a big fanatic of open source So usually when I try to do something that I love I try to open source it by default I think that's the best thing about our job because we can share what we do and with openness and I based in London But I'm Italian and I work for a company called open table So just introduce a little bit the context So open table is an American company. We mainly provide software for restaurants. So The core of the business is that we have a system that allow people to make free Instantly confirmed reservations on the website on restaurants that are our clients these restaurants are more than 30,000 restaurants worldwide and Every month we have something around 16 million reservations and we have almost half million reviews per month And I think this is useful to understand a little bit the scale of the problem and so We are our business Operates in Europe America Asia and we have software engineers in Located in mainly in San Francisco, London and Mumbai, India So we need to make these engineers work well together and this is not very easy Every time we make a comment every time we actually make a change to our code We know that as soon as this code is gonna be in production We are gonna have millions of requests per minute to be handled So our code needs to be stable and needs to actually scale The talk today is gonna be about our front end and In specifically for our front end. We have something around 15 engineers that every day make changes to the code We have I think something around 200 engineers working on many projects today. I'm gonna focus about the front end What I mean for front end is The consumer websites that we have so when I mentioned our our how our business works I basically I should mention that The restaurants that are our clients actually run our software on the restaurants But this interacts with their our data centers, which are mainly located in Europe and US Then we have a consumer website, which is actually where all the users can for free subscribe and make reservations We have mobile apps. We have software written in basically any language probably and legacy code And something around 15 years of experience on this field So as you can imagine where there is a lot of legacy code a lot of new code Softly written in many language and 15 years of engineers coming and going and writing pieces of this code So I will say something that realistically is not beautiful. It's normal. It's real life Sometimes it's great. Sometimes it's not and we need to deal with it. So the agenda for this talk So I'm gonna speak about the microsize architecture, which is something we implemented. We call it like that I don't know if anyone else in the world call it microsize But if you want is something around something similar to the concept of microservice, but apply to the web I'm gonna speak about the second step, which is actually the second level of componentization I'm gonna mention a framework that we build and be open source business open components But I'm also going to speak about the architecture level. So something a little bit useful hopefully for both an engineering point of view, but there's a cultural and point of view Then I'm gonna speak a little bit more about the agile implication of these choices So just to understand a little bit how many of you are software engineers? Okay, quite a big number. How many of you are people that work in product the product owners? Okay, and so basically the for me When I submitted the talk to agile India I thought well that actually makes sense because for me. I am a big fan of agile The problem I think in our job when we write software is Sometimes we agile is just a buzzword. It's actually yes. Do you do agile? Yes When you do an interview you ask someone what about a child and say yeah, we do this stuff I know about this and this but the reality is a child is not really just setting up some meetings on your calendar He's actually making engineers and product work very well together And if you don't do that, you know, you are not just doing a child Sometimes as engineers, we actually are very used to actually make compromises We want to deliver something we know about technical depth We want to find the best way to deliver the job Sometimes it's quite easy attempting to say We are just gonna try to avoid speaking with you with the others So the engineers are gonna try to agree with product and then we are gonna try to do our stuff And then maybe they are gonna come back, but it's gonna be something like a complicated relationship I would say for me it's important to have this relationship keep it alive and deal every day so Let's start. Let's get started. So The story starts a couple of years ago I've been in this company for three years today I'm gonna speak a bit a little bit about the story. I'm gonna tell you a couple of secrets and I'm gonna try to put you through the path we follow So just to give you a quick introduction So in 2012 is I joined in 2013, but I think the dates are quite right Given what my colleagues told me. So in 2012 we actually set up for the first time a homogeneous continuous integration pipeline Before we used to do something different. Each project used to do what they wanted In 2012 we set up an integrated continuous delivery a continuous integration pipeline All the projects are to be integrated there and that was 2012 2013 we decided that Gita was a very good way to actually be productive as engineers. We moved all the source control to get we used We used to use a little bit of githam already, but in combination of subversion and other systems We decided that githam the cool request method was something that was Something that could deliver some value to us and we decided to go to there So since 2013 we decided to move everything there and when we actually moved to githam We decided that we actually want one answer to do open source if possible So githam was if you want a good vehicle for maybe start thinking about that So when you do something very little something small And you actually can open source it because it's small enough is nice and is nice tested It's good to be in githam because you can create a private repository and then you can say snow I'm gonna open it and that's very easy if you are already there because you don't need an extra Extra work for doing that so 2014 I think We implemented the first project that was Implemented fully continuous deployment and this was a quite big cultural change. So speaking about agile This means that since 2013 We were using our continuous integration pipeline our software was going to be in githam We used to do a commit automatically our platform was taking the code running some tests We actually at staging environments. I don't know how many of you have seen the talk this morning About continuous delivery. I loved it and I ate Environments as well. So but that was part of the legacy and really and necessary for our job So this is one of the first things I I wasn't sure about that we did that and we still did it do it And in the real life probably you still do this kind of things. So When we decided to do continuous deployment, so one comment to actually go to production That was difficult mainly because my company is Is a big company? We have a big legal department. We are public in the US So we actually need to be careful with regulations and we actually need to Document everything that goes to production. We need to follow some procedures when we actually started speaking with product And we say we want actually our code to go to production straight away. That wasn't doable So actually it took a lot even if in 2012 and 13 we already had everything in place We still needed to push a button and this button had to be pushed by someone that had to ask the product and had to be approved by Director or a little lead and that then was going to production so we found out that in order to do that we actually needed to apply some cultural change because we couldn't agree about things and Usually we used to have a deployment such as okay. I do my code I agree with product on doing a planning that I want to release this feature or I want to fix this We are gonna do the coding. We are gonna deploy this To the stage environment someone else maybe from the same team is gonna Validate that the tests are all right or maybe someone is gonna do even some manual QA to understand that everything is all right And then someone from product and one from engineer are gonna say yes, we agree. Let's go to product is So in order to do that we needed to change this flow completely and reverse it So what we changed was okay when we are gonna plan to release something Product engineers are actually sitting together and they are exactly deciding what this feature is and they are gonna set up some Acceptance from the beginning not after the code is done but before so if you actually define that you say This is gonna do this. This is gonna do this and as soon as you release your feature You can say this is the test that proves that this is exactly what we agreed This is the test that proves that this is actually what we agreed So why you product need to have a final word. We actually don't so what we decided was we are gonna start working differently First we are gonna agree about what we want to do then the after that that's basically the sign off As soon as it's prioritized it means that engineers can start start working on that and as soon as the code is ready That's gonna go to the stage environments and straight away to prod if all the tests are green That took like two years and that's just a little thing and the infrastructure was ready But I think that the point of my talk today is gonna be I'm gonna go a little bit deeper with a lot of technicalities I'm gonna show a lot of code But I feel like the thing that I want you to keep in mind is there are changes that seem easy But take years and that's because you need to involve a lot of people you need to prove that things work And you actually need time for people to understand and sometimes it seems like Something requires just a technical approach, but actually requires cultural shifts the way people think yes, so Yes, so what you used to do was okay, we want to use this feature We are gonna put the acceptance criteria But then before going to production product users say you know what I think that this is not enough to satisfy this acceptance Let's validate that this is like that and that and then to actually do this shift means That we actually are to rediscuss this and say no the acceptance needs to be locked before starting to work on something Because as soon as you start working something the engineer is gonna set up the test validate exactly what we asked for And that's gonna go to prod without asking you everybody any more the permission for doing that And we actually did that because reality is the team lead over each engineering team already knew what was happening So it was just an initial quick. Yes, I approve of course and the product used to basically take the time to actually understand what was happening And obviously when we speak about all of these practices It's worth mentioning that we didn't we don't have in we since a couple of years even like any more a specific quay Department so quay happens in the same team So the idea is more teams of ownership and encapsulation Responsibilities and teams quays is on stuff We still have like a quay department generally speaking But I think that the role shifted more on try to validate that something is done on more something like an exploratory Way to do quay like let's try to find issues and with if you if we find issues We actually can even create automation around that but it's most likely to be Something that tries to find issues more than actually validate things because that like responsibility of the team in order to validate That the acceptance are satisfied so that they can push the button And the idea is as soon as you do that you don't need any more to push a final bottom Because you actually have a platform that allows you to validate all the tests and then that goes straight away, but So today We have still something manual something that is actually continuous deployed something continuously delivered something still requires a manual but push because that is actually not required and We actually don't we are for different projects, but we follow different policies We actually trying to be as more Consistent as possible and try to push for continuous deployment But some things just don't need it or they deploy every day and they just can push a button But I think that the cultural shift that if you want about the workflow with product and business That is something that we are really trying to push for every project so 2015 means that Last year we were Complexively for all the projects all the teams doing at least something around 10 deployments per day for many projects This means that in production for mobile apps or APIs or from 10 Things were changing every day. She's beautiful for a big company Couple of days ago, I think that's worth mentioning a new engineer comes to the office Usually the first day of your job when you actually join a company you Mainly spend your time on getting your machine ready Couple of meetings with HR the finding things but it's good that we had the opportunity to see together at the end of the day and We paired a little bit he seated with someone I think he wasn't me or someone else and he was there looking and he knows what GitHub is He just got the permission he found a little thing which was let's fix a little translation in this project It was cool that you made a little request and as soon as that PR got merged that went straight away to production So you can say a new hire when I actually joined the company my first production So the first time my code went to production was after three moms I think because I started with a new project that wasn't in production yet I didn't know anything today and you engineer can join the company. I can go to production the first day I think that's pretty cool because you can actually feel empowered and Enthusiast and it's very important to actually keep the end of the ride. I think so Now let's speak about the front-end project a little bit So this may sound familiar to many people we added huge monolith and a huge database that used to manage everything It was simple if you want to understand from our architectural point of view, but we had a lot of problems so We had store procedures around this database to interact with data to write and read So DBAs used to be their own department. They used to manage the data They used to scale the databases to care about everything around that Store procedures used to be something like okay, you need to access some data in your way You actually submit a request to have a new store procedures merged inside the repository of the sort of procedures Then we are going to analyze it. Maybe we are going to merge it and then you are going to be able to have your facade to the data Then we use we used to have a couple of use dot net applications use the dialing directly with the store procedures if you want So mainly we add this big dot net application, which was a single code base for the public website Public API is used by mobile public API is used by some partners that used to integrate some of our data and That was a single project as you can imagine. It was a huge dot net application It was like a solution with something like 100 sub projects It required I remember when I joined that was like the initial initialization phase for a new engineer Make it run was meaning like dealing one day with actually installing all the dependencies And making all the test screen and installing everything and fixing these little hacks It was not ideal both for actually approaching to the code because it was a huge very difficult to understand it to approach our application And that wasn't very great for many reasons. I'm gonna listen here. So first we were deploying every 15 days So that wasn't great It means that every 15 days we had a schedule deployment and this means that the the colleagues from San Francisco used to actually kick deployment everybody needed to be ready and All the sprints for all the things were two week sprints just organized to actually consider with the deployment and Two or three days before the deployment. We had kind of a code freeze No merges to the main repository because we had to run all the tests that needed like 24 hours was crazy And then a deployment Not very resilient Everybody was scared actually about approaching to this project because We didn't you didn't know if that was going okay And you were scared because it was a big huge code base and it was complicated to approach Not really robust. So every time we were deploying 15 days We were deploying something we didn't know if he was okay As soon as he was there if we had a problem The only option was to immediately roll back and when we were to roll back We had to spend another two weeks most likely to understand what went wrong and actually trying to fix it And then wait another two weeks before going live and perhaps we were going live with that plus something else that totally needed to Go to production and it was complicated. I remember sometimes and say, okay They're gonna deploy in 15 days. Oh, you need to wait another 15 days Oh another 15 days that was one month and all for actually getting a little change Maybe in production and that was because the workflow was kind of broken And Still we add something good. So what goes consistency? So one single language we were good on writing C sharp and we used to hire good C sharp developers And people were pretty good on helping each other because that was a single language. We were expert on that We had a dedicated thing for infrastructure. So every time you need provisioning and you needed a new box. You needed to Enter to a machine to see what happens if you want it was easy because we were consistent We used to have windows architecture We are people that were very expert on that and every time you had a problem was easy to find out So if you want to engineering teams were more focused on writing code less on taking care about infrastructure or those problems They wrote their tests that they record as soon as that was done That was an ops problem Hi, so we are dedicating team for testing So engineers used to write their code and then usually was in a two-week sprint something around one week of development Then two or three days for the quiz to actually analyze everything and then two or three ways two or three days To go code freeze waiting to deploy that wasn't great for productivity. I mean honestly You can make things better, but that wasn't working. We needed to do something on that So what we did was to try the S way Root so we decided to go to the service oriented architecture was the new thing And we decided to actually start splitting all the domain logic on the back end To lay those small services. So instead of accessing the database We say we are gonna be a little services in our case the business is restaurants So let's do a locations API a restaurant API availability API user API, I don't know These little services each of these services could be maybe initially just to actually do the switch Just a facade for the store procedures and the old database and then ultimately it will be Services that own their data. So if you want approaching the service oriented architecture was let's create first a layer of Interfaces and then these interfaces are going to interact on the back end Initially with the old infrastructure, then they are gonna evolve in order to have more encapsulation and be more independent And that worked and it took a couple of years But the result was more something like that. So we had a website that was interacting with these little services for doing their stuff We were able to split the partners API to a new project and this new project was working Integrating just in the API's so we were able to have two smaller code bases and the mobile apps were actually able also to use the services to so that was good for many reasons and This talk is not really about service oriented architecture, but I'm gonna mention just a couple things because it's important So obviously we were able to release changes very often to these API's because if we wanted to deploy Availability API and that was a very small code code base and project. We didn't need anywhere to wait for two weeks We we were we were able to use good practices software practices design patterns in API Is we have versioning we can actually we were able to release very quick In addition, we were able to distribute this ownership to smaller teams So instead of having these big teams that didn't know what they were working on and they were mainly Mainly feature teams working on features They were also able to have a specific code base that they could own and they could take care of and that Translated to have smaller code bases smaller teams that were able to have ownership Especially on the backhand because they were very complex system that are very little product involvement But still he was born to prove the value of the product. So obviously I'm not saying that they were not dealing with product And the teams switched culturally we changed a lot When we basically started working on this We started creating teams are free for people and this is a little bit not really It's still quite not very Common I think because usually minimum people have people of teams of six or seven people But the point is if a project was small enough and free for people were enough to actually work on something Do some per programming do some quay and work on something very small That was very good because the team could actually be also blocked on deploying with they wanted They were also able to deploy in the way they wanted and they were able to have a lot of ownership and Lead freedom That worked and it took again many years to actually get to a state where this wasn't really just a mess but was something that had Logic something that was kind of working nicely and this means Halloween people to do First justice services then try to sit on the table and say let's try to do monitoring all together in the new better way because instead of actually do monitoring everybody how we want it and that's the login profiling and Integrating for party and in-house build services to actually be able to have Insights about all the systems how to deploy them how to scale them and that meant create an ecosystem of tools, but the consequence was Creating an ecosystem of engineers that actually cared about to be involved not anymore on just writing code but actually on writing the tests and actually making those test screen on Setting up a deployment pipeline themselves on the continuous integration pipeline knowing exactly was was the step for making your application live And actually having the freedom to push the buttons to make it live So not any more approved us by people a totally reverted Flow for actually working on new things, but also a new flow for when things were in production That wasn't anymore something that you could forget about now That was something you needed to care about and you needed to have your dashboards You need to know when something was going wrong because that goes on your shoulders So a lot of power with more responsibilities And that seems something that scares a lot of people But actually something that engineers were so happy about because they were totally Passionate about what they were doing and they were empowered on being not any more blocked by other people for doing their job so given this worked very well after Two or three years when we try to do something nice something wrong And we try to reassess how we were doing things We decided to approach to this problem and to try to apply the same principles to the front end so After we created a lot of legal services on the back end We used to have still this huge dot net application, which was the legacy application which was the consumer website and Realistically, I was complicated to work on that because mainly I Think the most cultural challenges were we were working together on the London office on the San Francisco office to this and that was complicated because we needed to coordinate sometimes with people and When we actually have a pay tower of difference on the time zone is not easy Usually you need in the UK to work all day and when he's like five So when you actually want to go home, San Francisco people are coming to the office Usually if you want to have a meeting you need to stay up late and sometimes someone from San Francisco is late and then you end up being a home at seven and that's like annoying and We decided that we wanted to try to be more encapsulated so If that worked for the services because we are teams in London that used to have Ownership for a service and team in San Francisco to own another service that they use to deploy when they want it We said how can we try to do something like that for the web? So we started working on the idea of these microsites So what we used to call microsites we still call them microsites. So the idea was very simple So we had this huge legacy application and we say let's stop working on something and let's try to do a rewrite So we are the first thing we wanted to start was the search So we are the new search team in the UK It was I think five people and they used to own the availability API in the search API on the back end So the cool thing is that this team already are the quite deep knowledge about the domain logic of the systems They so they used to actually on the last year or two work a lot with these kind of problems So they created new algorithms for actually try to display the results in a better way They worked on features like that, but every time they wanted to bring it on the front end It was complicated Because they actually had to depend on another team and they had to wait two weeks again to release this thing So we say it let's try to do this little experiment So the search team is gonna be a little website We call it microsite and that's gonna be just one page or two pages is probably gonna be just the search page Plus the search results page something very simple That's gonna be a new project Very simple very small is gonna do a couple of things very well very simple contracts It's gonna have a set of links so the from the on page you're gonna go to the search page and then We are gonna try to put a little hack on the top of the huge monolith And we are gonna say on the routing level if the user want to actually go to this URL go to the little microsite instead of the real website and If actually and then obviously that was just the entry point to going back to the other So if you actually have your result and you wanted to make a reservation or see a restaurant profile You actually were going back to the other one obviously everything was hidden from the users So everything was underneath Not using any more the single code base and the single deployed unit. I was actually using two things So we tried to do that and it was quite exciting because at the beginning it was quite easy It was just a simple project a little hack on the top of the routing level was I Empowered actually this team to have everything hidden from the end user and This page looked exactly like the rest of the website, but it was a simple Separated project so this team started releasing like every two or three days Where they were able to release changes into production and the cool thing is that because the same team were owning also The back end they were able to do things like okay Now we are gonna experiment with this new search algorithm We are gonna deploy the changes on the back end on the backend API, but we own the front end too So actually now we can deploy the changes live also to the back to the front end and we can do experiments We can do a bit testing we can do a lot of cool stuff that other people do and that was fantastic because it worked so After that we decided okay, what if we try to do the same thing for another piece of the website let's try it with the homepage Maybe that can work. So as soon as we started working on the second one realized that it wasn't that easy so In principle it was very good, but as soon as we started working on the second and thinking about the third micro site It was good because we were working on bringing something from the legacy to a new system So with a little rewrite we were actually able to kill a lot of old bad stuff But we wanted a way to find a way to make this system scale So obviously when you have a little hack on the top it is acceptable And obviously when we had search we had a lot of duplication like all the assets all the logos all the CSS Everything was duplicated because obviously it didn't make make sense to use the other resources because that will result on our dependency they actually wanted to be undefended so they Started duplicating a lot of stuff But that was acceptable because that was the necessary condition to make them able to be totally unblocked and totally independent But thinking about doing the second in the third and the fourth micro site we found out well That's not sustainable that doesn't scale if you want Really realistically to do this for the entire legacy website that would result on 1015 micro site we can't afford to actually do this thing in this way, so Things changed and today on 2015 ish We basically were running exclusively on micro sites and all the legacy stuff was basically killed I think we still run a couple of things there just because we we don't we don't want to re-implement it But it's really just something we don't change anymore So how we actually achieved this so I'm gonna try to give you an example about what happens today, so Today you go to open table of common you go to slash San Francisco restaurants, so this Internally converts on this is the start micro site So this is like the start page is what we call a say a page for like the on page for that city This means that this city needs to be rendered for the San Francisco metro location And what happens is that we have a service that we built which is actually something we call from the service Which organizes all the routing in a specific in a nice way So this translates to something like an internal instance of the start micro site And then he's gonna convert to some kind of a translation like specifying explicit parameters for naturalized URL starting point so we have something like a nice SEO URLs, but they convert internally to an instance of a micro site with some specific parameters and What happened with micro sites so today all the micro sites are Very simple we have teams of true to fool for developers not more and That works very well because the team needs to care about a very small piece of functionality Well, we try to aim for minimal complexity So this means that we try to keep things small and we try to think about the domain logic of this system. So We try to still aim for minimal dependencies and fail over tolerance, so Obviously if a micro site today is He is Working alone. We actually try to have still minimal dependencies, but actually we try to optimize the usage of code and that's playing you out And obviously we have a lot of advantages is easier to test So when we used to deploy the old application We used to have like one way of one day of running tests because of like 3000 of tested of features that we didn't know even if we still wanted to support here It was easy it is easy all the micro sites are one page or maybe two pages and You can write your tests in a nice way It actually is easier to maintain because the code is smaller a new hire can approach to the code More quickly quickly. It's easier to extend. So every time you actually have someone from product that wants to ask for something It's easier because instead of asking someone of 50 people can we change this thing in the homepage? You actually can go to the on-page team I guess I can we do this thing and that's gonna be one of those tools to for people not 50 who know who so it's actually easier or even from an agile perspective to redistribute work so Obviously these results on multiple day the daily deployments which means that we can make product very happy which means that we can make the business happy and This works because we try to apply this service-oriented architecture. So try to make things more granular on the front-end level But I think that the most important thing is ownership. So ownership is an important concept because Ownership is something that translates to having people empowered to actually do their job on the rate on the rate base on the base so Being able to deliver when they are ready without having dependencies that are totally and useful Honorship means so that when you have engineers that feel empowered because they don't depend on each other are more likely to be enthusiast about what they do and they can be more free to actually make ideas flow and the release cycle becomes smaller people are more confident and This translates to an increase of productivity an incredible increase of productivity and then to see how So as you can imagine, yes that's That's a good question. I I don't know if I have a definition myself for full stack developers because many people today Think about full stack us about a person that writes both front-end and the can or maybe someone that is light Bops, you take about you care about culture. You care about code. You care about testing I think that the my idea what I meant with this full stack engineers is that we are not anymore engineers that just write code We are engineers that work in products that are from the back-end to the front-end. Yes But most importantly we are also people that not only write code But test code because that's part of actually getting your job done if you don't test your stuff Is basically you didn't do your stuff and this means that you have a knowledge about what happens underneath the system You know how to find a problem as soon as it happens, you know how to do profiling of your application and you actually have the possibility to hone also that the full stack kind of life of the your software, so I Think that's what I meant. I guess so Honorship means also that you don't you can't delegate anymore to hops to actually make your application live You actually need to know when it's live And you know need to know when there is a problem and you are the first that can fix that problem Because you can't have any more anyone that tells you how to fix things now you own it and you are the only one That knows how to do it So I'm gonna go deeper with this a little bit later. Do you have another question? Sorry cross cross What do you mean? Yes, so The way we handle it is At the moment so we used to have a like an ops department use the people that used to care about deploying the application and monitoring the application I think that when we switch to this kind of cultural model We have seen the ops people Transicting to be more something that today we call infrastructure people But I think that the idea is they are not any more people that fix the stuff for you He's blown mainly people that go to team and help them to actually do their stuff So as soon as they team gets the knowledge about how to use the shared system Actually, they are empowered to go alone and obviously these systems needs to be maintained For example, we have our deployment pipeline. We are investing on we have a puppet infrastructure for provisioning that basically the hops that we call a Infrastructure team now built but this works with a pull request model so we have a huge repository for all the code that manages the infrastructure and When a new team starts, perhaps the new team pairs with the ops to understand How to get a new box but as soon as they learn how to do it then it's everything's in service So the team needs to make a pull request to actually implement monitoring For a new system needs to make a pull request for actually getting provisioning and all of this system are continuously deployed to production So somehow the infrastructure team is the team that maintains the shared system, but also But we actually try to invest on making the system In a way that they are kindness of service So the infrastructure team is more like the team that helps people to get the knowledge I Guess so did I answer it? Yeah, so now let's speak about how we achieved the result with the microsize So the first problem you have is the common parts. So Now that we've thought about a huge application You can see microsite as slicing this little application on vertical slices so you have teams that can deploy just this page, which is the on page and This team is able to achieve beautiful things For example, he can deploy without waiting for the other people. He can deploy multiple times a day he can investigate and resolve issues quicker because Instead of deploying a huge application now we deploy a lot of smaller application if something is wrong with one You actually can focus on that one You don't have any more to think about something using that you don't know how to approach when We want to scale our application in our infrastructure We can scale better because we can scale just the applications that we need more traffic We can actually scale down things that are required less traffic, etc. So it's actually also a better way to manage the infrastructure so How to solve the common parts so As engineers we care about quality and one of the problems we have here is okay I want to be independent. So I'm gonna accept some trade-offs and At the beginning we saw okay, the first Microsoft said okay We are gonna duplicate everything and we don't care how to make it scale. So we have to think about how to connect all these vertical slices in a horizontal way, so We wanted to have to have more code usage and we wanted actually to have a Better way to handle common parts. So specifically on the front end a little example could be On the old monolith, I wanted to change a little link on the footer I actually needed to find someone to do it and then that was going to the master branch And then I needed to wait two weeks and that was life everywhere on the website Because the footer was a shared component beside the single project So how to change a link today that we have 15 microsites. So we decided to Think about how to componentize pages on a new level on a smaller level. So how to share the common parts for the web and We actually build a service to actually serve the common parts. So Again, let me try to give you an example So if today I go to search and I try to make a search for San Francisco for a specific daytime This goes to the search microsite. So internally if we have something that resolves or something like that That's an instance of that application So what this does is you execute logic. For example, if your search page you go to search Service you'll try to get availability. You get some data that you need Then you go to components API to actually get the shared components for example the header and the footer Etc. And then you render a page that looks like something like that So if you want we created a service that you needed to as a page to Consume every time on runtime a request was coming to you To actually get the source of truth. So which means that every time we wanted to make a change in the footer We were able to actually make a change in just the footer component And at that point everybody in production was getting this change because we were deploying the footer so How does it work? So today we work in this way we try to approach many ways this problem and We consolidated this which is a kind of a combination of a simple API to serve components Which was something we had at the beginning to something a little bit more dynamic Which I'm gonna describe on the second part of this talk So when you actually try to get a component for example the other of the consumer website We have something similar. So we have an internal instance Of the other it goes to a service that shares all the components You ask for the other and then we implemented a couple of things. So first we implemented semantic versioning Which means that we were able to roll out a lot of changes here because we have The problem that the possibility to have simple contracts to describe what was happening So when you actually make changes on the other or pieces that that client side JavaScript The last thing you want is to have a system like that that at some point breaks everything So if you have a system like to share the other and you put some JavaScript and that JavaScript is broken If you actually make it live all the microsites are gonna be broken how to do that It's complicated from an integration point of view to run tests and ensure that everybody that integrates the component is actually gonna be Okay, I mean it's simple maybe for some simple components that perhaps a simple market But it can be quite challenging for components that you start to have CSS shared client side JavaScript Things like that So when we try to approach to this problem we thought about a couple of Ideas so the API was just one of them we thought about server side includes before the ball CDN Integrated CDN for actually getting these contents check context in a static way But we found out that they didn't work because the main point of the SOA was let's have simple contracts to actually Define interfaces. I have specific service to do something very small something very well something simple to understand and integrate Having server side includes or mechanism like that was actually against The general philosophy and people didn't like it. So we try to investigate something like that So something like a layer on top of the microsite that could automatically Render all the share parts, but that was crazy because at some point the microsite was seeing something wrong And they didn't know how to fix it because they didn't have control So the microsite wanted to have control and with semantic version We achieved that to say you want the other but you want version one version one is gonna have a clear a block a kind of a specific interface Specific parameters and specific conventions and you know that we are not gonna break it As soon as we are apply a new breaking change because we are gonna switch to a new library for a front-end client side dependency We are gonna push the truth and if you consume the one of the other like the latest Minor and patch version of the other you know that you are safe And you know what if you consume a component that is owned by a team that you don't trust You can consume version 1.2.3 and that's never gonna break and every time you release your microsite You can upgrade your dependency for the shared components that you are totally safe. So the idea is still Having something shared but something that could empower the microsite owners to still have controlling ownership of route across what was going to the page as I mentioned We decided to implement something like an API very clear for the components So that they could handle logic. So the cool thing about this is that if you want is a little bit unusual when you see system like that nowadays especially with Kind of gold era of new JavaScript frameworks. It's quite common to see a quite Clear a separation between what is in the front-end and what is in the back-end so systems like that Usually don't handle logic. So you get just the assets and then that's pretty much something like a clear a simple template that then gets replaced with Translations if you implement the same thing in many languages logic if you actually For example in the case of the other you want to handle the same component for the logged in either or the logged out either so you need to show the sign up or the sign out button instead and The cool thing is that With a system like that instead we actually tried to challenge this So we said if either if components are something like little partials that can handle logic themselves It's easier than to for the microsite integrate because components like that could have a logic like give me the metro ID Which is the identifier for the location and the component could do itself a request to location API To get some data and to share you the beautiful sitting name on the top you are here so It was good because we were able to have a new level of encapsulation and In a way to make two teams work together one team wanted to add to handle the other one team wanted to under the microsite now The header maintainer were able to share a simple interface. That's the contract the microsite were able to see the contract integration was easier other things like Conventions we decided to use accept language for all the translations so that the header could come exactly on that language Ready for you simple The output was basically something like that a little piece of HTML that the microsite could just take and put in the page So the contract was a very easy. Give me the header. Give me the American header for in American English For this specific location For this user type and then that gets HTML This HTML gets resources links for example a logo in case of the other and that logo is Responsibility for the component to all this logo somewhere so that the microsite could have a very simple way to integrate things But also we were able to remove the duplication So one problem we had with the the first problem of people duplicating resources was not only that it was bad for Engineering engineering general for pure code was that people were actually going to a website They looked like just a giant website going to page by page But the logo was downloaded every time because that was duplicating in each side So that was also not really performant for client side upon the view In this way having a single source of truth We could have the same URL for the logo in the same place So the markup could be exactly the same and the problem could be solved and we did that and it worked So What we achieved with this combination of the two so we have consistency so defer instead of actually having Something that we didn't know when was going live Because it was something like 15 applications now with the simple contract We were able to say we are gonna make a change in the footer We are gonna release the footer the footer is gonna be live on all the microsites and that's gonna be live in the Exactly the same moment so consistency Coordination so coordination basically wasn't required So we didn't need to ask 15 people to release a new thing because instead of having a library to share the assets Which is usually what you have with a clear from 10 and the can separation. We actually add something like a runtime system So we didn't need to ask the footer team to ask 15 people to redeploy their application and these 15 people didn't know when we were releasing things in the future So basically these two teams Even if they were geolocating into different parts of the world were totally able to do their job independently Optimal front-end loading because as I said, we didn't have duplication of resources anymore So the user navigating to page by page was actually Navigating to something that from a point of view of the resources was exactly the same website and It was easy to spin up new microsites So we realized that having a system like that was easy to say we are gonna move this thing away we are gonna create this new idea for the business and We integrate the shared components You have something like a skeleton page that already has all the layout now the team can focus just on the main logic about this new thing So you don't need to care about the front-end because we build components for the other the footer things like the adverts But then so something like for the shirt CSS for the search CSS of the website So we have like a project with the CSS of the style guide on the styling a project for the shared core Java script libraries So basically if you wanted to create something new everything was ready to go and that would work very well also for retiring the old model Because in a couple in one here and so we build first the first critical part and then at the end We actually were able to run a new infrastructure that was a lot of little Applications but handled by a lot of little teams and teams were able to go very quickly So the last thing I wanted to to to mention is what happens on the cultural point of view? So on the product point of view So what happened two or three years ago when we had this huge monolithic application you used to happen something like okay the business realized that we want to change this thing and Now we are gonna try to speak with someone on engineering We are gonna try to set up some meetings to ask who is the people that are gonna do that Maybe this team is gonna do it. Maybe this other team Then that's get prioritized and then the teams needs to do the coding and then the testing and then they need to wait for actually deploying that and then the business gets Noticed the says well this in production now. Thanks. And that was like two months later So that was crazy because of the whole the interactions all the steps and all the unusual steps That actually we need to pull before going to production So the cool thing that is that if you think about what happens here, I think Home when you make a little search. I think that the cool thing is that We actually make our code to look more like our business So as I mentioned at the beginning you are a user the digital you have a service that tells you that this is start Micro site then he convert he finds out information for you then he translates to a specific URL And then start micro sites does his own thing So the cool thing is that if you think about culturally it's pretty much the same now So the product needs to make a change of the website and usually what happens is that Someone says what is this change is this on the on page is on the search. What is it is on start? Okay, so that's the start team. I'm gonna go speaking directly with that team I already skipped like a lot of unusual meetings to understand who is gonna do that and who is gonna prioritize it Because from the point the product point of view the business now know exactly who asked for doing something And that's not anymore something like a team of ten people is a team of two people And these people are gonna have less stuff to do and they are gonna be Working on a very small code base that they can release it when they want So these people are gonna be able to do what they want and they are gonna be able to deal directly with business And product as soon as that's gonna be done. So culturally We build this as a projection of actually the cultural need that we are and I think that works very well because today our code looks more like the business and our product needs and This may sound very complicated But you need to understand also that one very key element of our complexity was making it work like In a very optimal way people geolocated in many different places. So sometimes you say We need to be coordinated to deploy something and we are I don't know ten teams But we are sitting on the same room and there are like ten tables and we need to say well tomorrow We need to release these all together because there is like this critical thing and we need to be coordinated Maybe that's not a problem really because we are in the same room. You can say let's do this together Well, you're gonna do it but the problem is that and Then so think about when two teams work together on the second base you say, can you review this thing? Yes Can you change this thing because I don't like it? Yes, and they can sit together They can do it. What happens when you have people working on UK and US you have people that says Can we can we can do a meeting to actually discuss this? Yes, that's gonna be free for days before doing a point of the calendar that is good for both and then Okay, we are gonna do a full request to do this repository And then that's goes there and then maybe the team that needs to review it He's busy that day and the team the other guy goes to the office back and says Do I have an email for me? Oh, no, okay. I need to wait from tomorrow I'm gonna send another email and say can you review it today because I'm blocked by you and the other guys Oh, yeah, I apologize. I'm sorry. I forgot Can you change these things and then he goes back and does these things and that's gonna be two weeks So I think that part of us actually making all of these Choices from an architectural point of view was also to try to solve this cultural problem of working on multiple time zones and I think that what we try to do is if we have an infrastructure that maybe is Topologically a little bit more complicated because you have like a lot of little points that communicated together But they communicate together with very simple and clear interfaces. Well, baby, that's actually the key because When a team like this used to have on the other and a Microsoft used to be in the US They could go to a page with a documentation They could consume the other without waking up the other team And if they had an issue or maybe a feature request, they could do it, but So I think that the first part of this talk here is this one, how's the timer? Okay I need to be quicker and so basically The idea for being more agile on the first part was Simple contracts simple interfaces at the cost of actually something a little bit more complicated but the main point was you need to Understand that code implies a lot of cultural shifts so In my experience we did a lot of changes on the code but that implied a lot of change on the culture and today We actually are working better because we made the code look like what it needed to be for the culture And then we found out that we needed something different because the cultural evolve as well and the code evolved as well So on the second part I'm gonna show you how this thing evolved even more because this is like the representation of like one here and half ago So we made other stuff and I'm gonna show you it on the second part. So what we wait for the screen Are there any questions now? Maybe we can spend a couple of minutes on that if you have No Yes The ten times a day was like an estimate for like one year ago I think I would say that they we have been even more than that When I say the releases I meant I mean actually releases of one of the systems that somehow have a consequence on what you see in production Which means that maybe ten teams are releasing once a day It's not the same thing that is listening today ten times But sometimes we have also the same thing that releases 10 to 20 times because they have 20 little Fixes or features that actually go live straight away In regards of the future toggle. Yes. So we use them a lot. We actually created I'm gonna show the link at the end. Maybe we actually open source a little framework for doing that which is called op-nop and It's basically a system that allows Access to engineers and product to a set of future targets So an engineer wants to release something when he creates a new toggle He can create it with a little UI web interface and both the product and engineers For their team have ownership of actually flipping the toggle both on the staging environment and on the production environment I mean obviously it's a system that in theory should aim of for not having a query environment and a staging environment But in theory but in practice we have it anyway and The cool thing about that is that you can say okay The team is ready to go live with ten things but product wants to release them once a week that's fine because the team is gonna be done and Then that's gonna go to the product version shoulders and he's gonna have authority to actually flip things on and off And usually what happens is that we have Two types of features usually one is a feature that you want to make live, but you still don't know if you want it So usually that's more something that we go we associate today a bit testing Kind of thing and we have actually an a bit testing framework as well for actually integrating these two systems together And usually what happens is you you create a feature you actually put a toggle in an a bit testing in it So you have metrics after a period you decide if you want to keep it up And when you do that then you can release you can basically Put the full feature off can do rework on the code to do the cleanup and you can just release it As soon as you're ready The second thing instead is when you actually Want to release something and you know that you definitely want it, but you actually can't because you have dependencies so for example, you want to release a new design of the website we did that and We worked on that a couple of months So we used to have a feature toggle to actually put who use the old design and the future toggle was on just in the Staging so that we could wait everybody to do the changes and that's some point when we were ready We actually toggle one thing in product Champagne We released a new website, but that was actually not deployment. It was just Toggling a little feature and that was cool because that happened when I was sleeping Because we're my course are in South Francisco and I'm lazy in London. And so I didn't I didn't need to stay up at night for that Which is cool? So other questions Yes Yeah So I think at the beginning it was really just a combination of Trying to do the same thing we did on the back end because on the back end We already were coming from one or your chubo service oriented architecture So we reorganized anyway the back end in order to To connect to the database to the mobile apps and to other things in a better way And we actually Understood how to do a lot of things well So we say now we get the knowledge to actually try to do this thing on the front end And I think that at the beginning was just really just an experiment and the motivations were to one to get away from the Monolith and if you want the microsite was a way to actually rebuild partially But keeping it alive the old monster on the side and that was good because it could do it progressively and the second thing was To test the idea of actually having something that could at some day be totally Powered by micro size and actually that revealed to be to be good and successful both for their productivity And both for the culture because it's easier today to to to organize things in this way I mean it works very well for us. I don't think is is very good for everybody, but I don't think in this talk I'm trying to aim for Telling anyone to do what we did I think is the main purpose of this talk is more likely to Tell our story and to maybe inspire you to maybe do something like that How many of you for example work with colleagues that are geolocated in different places? Yeah, so do you think so you probably recognize a little bit the coordination problem, right and I mean, it's not really to criticize people. I'm not saying that The UK office was better than the US or they well, it's just that sometimes you need Three work the way you communicate and work because there are realistically a limits on not being in the same office and You want to actually improve These people's work flow and I think it's totally possible Personally, I actually feel like the future for engineering is actually remote working all the way through and I believe that's the future But I feel like that before going to there We actually need Companies and people to understand that we need to reworking to work in a better way So we need to go online first We need to apply a lot of cultural shifts and perhaps in these that sometimes your software involves in such ways that You could decompose things in order to be more empowered and more independent and I think that works Other questions Okay, so now I'm gonna Go to the next stage. So 22 So in the next part I'm gonna speak about open components, which is like a framework another framework we open sourced and This is mainly what we found out when we were working on the microsite. So Again, we out now One year and a half ago, we had a couple of teams doing handling basically owning one or two microsites We had one team which happened to be my team that used to actually own the shared components API Which used to have the other the footer the advert share components And we found out that this was going very well But at some point the shared components thing which was my team was going to be a little bit saturated So the problems were mainly People got excited about this. So at some point we went receiving people requests and saying, okay I have this I developed this shared component, but I think this is needed by other two or three microsites So we were trying to evangelizing the principle that if you need to do something on the front end It is like a widget that needs to be shared. You should create a component for that but the only the team that was actually on being this components API was receiving so many poor requests and the Components were growing so much So we wanted to find a better way to scale this component isystem And that's what we wanted to introduce new things something like a semantic version Which is something we were not doing very well on the old system and improve Things so we built this framework and this is pretty much like where it works. I'm gonna show you the basics So we basically created a cell service service to create components as a service so We created something that is called the open components registry which is Basically similar to the old API to serve the components and this could actually be used to consume components So actually to retrieve these components are also for components creator to create components and to publish them so this system became Something like an interface which is a rest interface which was running all the time and then we created Something like an open component CLI which was an utility that people could use to create the test and to publish components And obviously as soon as that was created and published they could publish new versions and they could create keep maintaining that and The way it works is that as soon as a component is published The registry finds out what it is try to may analyze it tries to decompose the code and make some testing and sees everything is ready and then it publishes to the CDN So for example if this component contains images and CSS shirt static resources An automatic by plan is gonna publish this to something that is gonna be production ready Connecting the CDN and everything and in a couple of seconds these people are gonna have a URL Which is the components URL that is ready to be consumed in production And obviously then we have something like the runtime agents that are the things that consume the server side part of the component so I'm gonna try to do a little demo now and I'm gonna try Not really to go really deeper into this framework because I think that's not really the purpose of this presentation But I think like I want to show you How we actually try to make easy to make changes in such way that the business could have something really Useful very soon. So How many of you have I've seen a lot of engineers. So how many of you are familiar with Node.js? A couple yeah Okay, so this is basically the framework itself is in Node But the cool thing is that as soon as you have an endpoint that actually Has a component with a clear interface you can consume it from anywhere For example, we have a couple of microsites written in dotnet with one in Ruby We have other in Node, but they use the same API and they can consume components independent on the technology So now I'm gonna show you why it works so Let me try to zoom Can you see this? Yes I'm gonna try to do a little bit of a live coding So OC is open source then you can install it when you actually just win npm install GeoC and I'm not gonna do this because the network is I don't know and after you do that you actually have a little CLI so Do something like see the Let's create a components folder Make here Agile India and CD Agile India I have a blank folder. I do what you see meet my component I Will call it Agile India and how many of you are familiar with Jade? right view engine couple Okay, we support both Jade and handlebars. I'm gonna use Jade because someone knows but it's gonna be very simple to understand So I created the small components and that's basically a folder. I'm gonna show you how it looks It's gonna be very simple. I promise This is my components folder and this is my component my component contains a view Contains a little server side part and contains a description of the package It's very simple Basically what we are here if you think about an MVC architecture on the web is basically a system to provide Partials and You can include them on the websites like they will be a high frames, but they are not high frames So that you can integrate them easily and do crazy stuff with them I'm gonna show you in five minutes promise So we created a new components and I'm gonna say this is a test component This is version one. I can include a repository and I'm gonna save this so next thing I want to do is I want to set up a test environment and I can do a seed of Listening to this folder this is gonna basically start a test registry in my Computer that has gonna be able enable me to test this component So this is an example of my registry and I'm gonna go to my component I'm gonna have an auto-generated documentation in my component. That's nothing for now because it's a new component So I'm gonna go here. I'm gonna open a new Well, I'm gonna keep running my registry and I'm gonna start making changes so I'm gonna go to my editor and I'm gonna say Okay, Dave. Hello. My name is Mattel and I'm gonna create so this is Jade for saying like a div without my name is very simple and Now I want to create a little server-side part, which is gonna say something like I'm just gonna call back View model, which is gonna use by my view to render the html to be transformed to a view to an html Name is basically something like context arms name and if not So if I do this I Can go to my page. I can refresh that I can see hello. My name is Mattel and The component to include this component on the client side. I need basically just something like this So this is an OC component type with an hr app and I can do this if I do something like Name equal Jack This is gonna be a flow of my name is Jack So we have clear parameters and another thing I can do here is actually to make these things explicit So optionally I can go here and I can say something like parameters I can say name I can say type Is a string I'm gonna say that Is not mandatory. So it's an optional parameter I'm gonna provide an example something like Jack What it is your name If I save this and now I go to the web interface and I refresh this page I think you can see that I have like an automatically generated documentation So I worked a very simple component and I can have static resources here The framework automatically does a lot of magic for you But the point is I found out that now I have my component and if I totally want to test this And I'm gonna show you how it works. This is the web interface, but I can go to my Registry and I can make actually a request to agile India So here you have something that contains your HTML contains some data and is ready to be integrated When I actually want to put it in a page. I do something simple like that new page source This is server-side rendered Let me go to the other one I'm gonna show you it like that. So if I do OC review HTTP localhost India I Can see my component and how it looks like so now that I'm happy I want to publish this and I actually do something very simple I see I connect a registry to my folder. So I see something like a C Registry and here I created a registry for this presentation We have one table higher basically Connection if the connection works, this is gonna go to the registry. It's gonna find out that registry is valid and then it's gonna connect it He says that he's not valid. Maybe my connection is off Yes, it is. Let's retry But it won't. Yes. Now the connection worked. So now I can say something like a C publish Agile India. Oh, what are you? Oh, I moved to another folder. Sure. Okay, let's go to the right one Sorry. Okay They should be the right one Where my components are C publish Agile India, which is my component and Oh I need of the more recent version. Let's try Hopefully my connection is gonna work. So this is just me being bad on preparing demos. I apologize. I should get more prepared So the cool thing is as soon as I do this I go something I create a component and obviously I'm a good developer So I create some tests I actually ensure that everything works and then I have the possibility to publish this in production and These takes like two seconds. So the cool thing about this is that I have Something that allows me to use a shared interface, which is the whole C registry let's retry now and Hallows me to create new something new and that's production ready for the business So if I go to this URL now and I do who see preview this which is in the public Internet this is gonna work and That's it. So the cool thing is that we have Not this we have things like I can consume the latest version of a component So I want just the latest patch and may I minor so I can do this and If I want to consume this component, I can go to the to the registry. This is now Updated so I should contain my component to let's refresh Here is so I can share this link with other engineers and I can say if you want to consume this component This is the API. This is simple and that's done. So Let me share The list of the slides are gonna be just a couple just to explain you why we did this So we did this we ship it you can have static resources like images You assess the framework actually buy bundles everything for you that is ready And the cool thing is that you can integrate it on the client side in a such a way that is very simple like that This script here is like a library of five kilobytes. So it's very small and supports all the browsers like I ate And I can actually if I create a component that I want to integrate in a microsite Or I want to create an AB test to put it everywhere in the website I can ask someone to integrate one two lines of code So if you actually want to share a new component, which is an experiment is actually something new is a widget I can ask people to make a PR for two lines of code So how complicated is gonna be for someone to review this pull request if I actually need to wait for another one That is located in another continent review this They basically they need to agree that they are consuming the right version with the right parameters, and that's it If you actually want to consume things on the server side, you can actually make a request on the server side using the API so that's that the previous one makes a client side rendering as soon as the page is loaded and The cool thing is that these components are totally somorphic So you can consume them on the server side as well and you can get the HTML So if you actually want something that is important for ICO you can actually do it on the server side and and There are so crazy things like if you'll use node or client side It actually is quite optimal like it gets the data first and the model it catches stuff It does a lot of magic for you. So it's actually pretty performant and It's been in production for like one year now the table Since is a release in production. We add something like 52 components on the on the old system We add nine components, which was either fruit or something like that You want to hear people use it for doing a lot of stuff like creating a test And they didn't need to ask anyone to do anything because they were out a new system that empowered them to create something and to put it live With a simple contract So what the futures are enabling people to create and publish new components independently Which is important because I'm powers people to actually do experimentation and to do stuff. Well There are a lot of ownership because we have simple contracts and people can do integrations in a very simple way We are performances because the framework has a lot of things and the health So you can use use a more phasal as a failover strategy because if on the server side You want to render a component which is big artist taking too much or maybe the registry is not responding because You know, you don't want this dependency You can use client side rendering as a failover so you can actually return When you try to publish this to render this if this doesn't respond You actually put this on the client side and that's gonna render on the client side as a failover So if you want a bad thing about the cloud that the old system was that we add a new hard dependency for all the Micro-sides if the system of the components were down as low hold the micro-side for down here We have actually a new failover strategy, which is agreed and works very well Yeah So the OC tag is rendered by a little client So when you actually integrate this you have like a little piece of JavaScript here and This actually automatically goes this as a little API on the client to do more complicated stuff like Rendered it on on the go Having a set of events to actually listen to what is rendered a lot and you can do stuff like testing components You can do everything So this is just a very simple things and the cool thing is that you serve as framework for Experimenting with a be testing so a be testing we used to do it a lot two or three years ago We started using first third-party options And what we used to have is like third-party things that allow you to inject any piece of code in your pages And usually what you have is people that break stuff and they know that that's an experiment of someone So you disable the experiment and say oh, that's some crappy code That's someone put that and we don't know what it is with this system Actually people were able to create a new thing Put some tests on it and then the AB test could be just put this component here or put this component here And you could have a feature toggle on top of a component will say put this component here or don't put this component here So actually this integrated very well with the existing infrastructure of the feature toggle and everything and Now we could integrate the components to our continuous integration pipeline and put some tests and actually made them completely Able to be delivered the collection immediately automatically. So obviously when I show the area will see publish It's good for a demonstration, but in our real use case This actually goes to a git commit poor request get merged Automatically this goes to the continent integration You do nothing and these takes if you have a recent amount of this amount of tests basically To go to production the time of executing the test for us one second So this is actually pretty cool because he usually empowers teams to I've seen team I've seen teams releasing components like 20 times in a day Because actually you don't have anything that blocks you and if you use semantic versioning everything is priest, so everything is Immutable so you actually need to create a new version every time and with the interface you can navigate previous versions and Microsoft's every control so I'm gonna go to the last piece of my talk, which is the conclusions. I don't know how much time I have One minute. Oh, sorry. So what is a microservice? Good question Oh, I'm gonna try to answer this question I feel like when I heard the word microservice for the first time I say what is a microservice? That's just a new word, but it's just service like you want to do it Well, the design service you have encapsulation. You have control to testing. That's just a good characteristic of a service Microservice is just a word that I've seen myself change in my mind. I feel like the secret of microservices is a little bit understanding that Something is doing something nice for a technology point of view Something is actually applying the cultural shifts that doesn't needs Microservice for me is like telling today that we actually are doing this after five years of failures and successes and Today is something like that is something very macro. So I've seen this talk. I would recommend it to watch it. It's beautiful and Basically approaches to the idea of what is that we do for doing very good software. We actually try to do highly maintainable software What about making the software is more than us that is actually highly destroyable so that you can actually rebuild it every time You need because it's so small that actually and you have the infrastructure that allows you to do something new very easily Without actually blockers. So perhaps the secret is a Microservice is something that you can easily destroy and you don't care because you can just rebuild it And that requires no effort from an infrastructure point of view or cultural point of view Other couple of recommendations. I will say let's stay always close to the business The reason why we did this is to be more agile. This book is something I love It's gonna start with why and allows you to approach to the why are you doing things? Are you feeling it in this complexity? I'm gonna go very quickly. This is another book. I will recommend about ownership. I'm gonna share my slides later on Twitter so I don't know if I have the time for my conclusions But I will say this is the secrets for me for microservices minimal dependencies minimal complexity Stay close to the business and trust people hire good people and power them and trust them. That's the secret for being agile and Yeah, that's Failure is a feature think about failure when you actually do something and componentize everything. Thank you That was it questions. No time for it. I guess Yeah, thank you Follow me on Twitter. I'm gonna share my slides and everything later And I'm gonna be around to speak about this more given the time is over. Thank you