{"id":13290,"date":"2021-01-20T10:35:35","date_gmt":"2021-01-20T09:35:35","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=13290"},"modified":"2021-12-23T11:41:31","modified_gmt":"2021-12-23T10:41:31","slug":"microservices-migration","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/microservices\/microservices-migration\/","title":{"rendered":"Airbnb’s migration from monolith to microservices"},"content":{"rendered":"\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\tTable Of Contents\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
  1. The early days at Airbnb<\/a>
  2. Why you need a microservices migration?<\/a>
  3. Migrating to Microservices from a Service Orientated Architecture<\/a>
  4. Principles of Service Design applied to Microservices Migration\u00a0<\/a><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\n\n\n

    So you\u2019ve decided to migrate from monolith to microservices<\/span><\/strong>, what next? Such a redesign to service<\/span>-oriented architecture<\/span> (SOA<\/span>)<\/a> is a long, arduous journey that benefits from an incremental, iterative approach. Yet, such a microservices<\/span> migration often must be done while still shipping new features, accelerating developer<\/span> velocity, and growing the team<\/span> in addition to ensuring there are no performance<\/span> regressions.<\/p>\n\n\n\n

    Jessica Tai is a software engineer<\/span> at Airbnb<\/span><\/a> and works as an an infrastructure engineer<\/span> on the Core Services<\/span> team<\/span>. She leads the user service<\/span>, which integrates with all business verticals as one of Airbnb<\/span>\u2019s highest trafficked services<\/span>. In addition to driving best practices<\/span> for service<\/span> development, she focuses on Leadership<\/span> & Development as the Vice President of the Airbnb<\/span> women in tech<\/a> community.\u00a0\u00a0<\/p>\n\n\n\n

    At Codemotion<\/span> Milan<\/a>, she shared the story of Airbnb<\/span>‘s journey focusing on how Airbnb<\/span> is building, operating, and scaling<\/span> its expanding network of services<\/span> and changes to its organization<\/span> to support the migration. We sharing some of the main themes and points here, but you can gain the full story by watching her presentation below.\u00a0<\/p>\n\n\n\n

    [jwp-video n=”1″]<\/p>\n\n\n\n

    The early days at Airbnb<\/h2>\n\n\n\n

    Jessica shares,<\/p>\n\n\n\n

    “When I joined Airbnb<\/span> in 2014, the engineering<\/span> team<\/span> was much smaller, less than 100 people. We had a new hire tradition of welcoming employees to the company by having them run underneath what we call a human tunnel. At the end of this tunnel was a large beanbag for engineers<\/span> to jump onto while we all clapped and cheered. After our new hires completed their human tunnel run, we gave them an onboarding task and our monolithic<\/span> code base. At the time, almost all of our engineers<\/span> were coding and our monolith was daily.<\/p>\n\n\n\n

    Now in 2019 Airbnb<\/span> has over 2000 engineers<\/span> across the world so the human tunnel is no more. <\/p>\n\n\n\n

    Why you need a microservices migration?<\/h2>\n\n\n\n

    Jessica details:<\/p>\n\n\n\n

    “At Airbnb<\/span>, our monolithic<\/span> application<\/span><\/strong> was a Ruby on Rails<\/span> app<\/strong>. We refer to this as monorail. A monolith is a single tear unit responsible for both client and server-side<\/span> functionality. This means that the model view and controller layers<\/span> are together in a single application<\/span>.<\/p>\n\n\n\n

    And this was a really easy place for me to get started. It was super<\/span> convenient with the presentation layer<\/span> being in the same place as the business logic<\/span> and the data<\/span> accessing. Airbnb<\/span> had a really large database<\/span> that had All types of data<\/span> stores shared in a single place.”<\/p>\n\n\n\n

    \"\"<\/figure><\/div>\n\n\n\n

    In terms of the booking flow, Jessica detailed the work that preceded the microservices<\/span> migration<\/strong>: “My onboarding task was to create a feature requiring a guest to send a message to their host. This required some new text in the view, accessing the messaging data<\/span> model and some business validation logic. Together my new hire changes shipped in one up MonoRail so if MonoRail could handle everything, why did we bother taking the time to move away from it?”<\/p>\n\n\n\n

    The short answer is for the people. Airbnb<\/span>‘s engineering<\/span> team<\/span> was growing rapidly, often doubling year over year. The need of the business was also evolving quickly<\/strong>. Jessica explains, “So we needed an architecture<\/span> that could move quickly and grow with our team<\/span>. In MonoRail<\/span>, we were seeing difficulties with more production incidents. Engineers<\/span> had to spend more time firefighting instead of developing features. Our codebase was tightly coupled and difficult to navigate and debug. It also took a long time to deploy<\/span> our code. When I first joined, I could deploy<\/span> a code change on MonoRail in just a few minutes. Now it took several hours just to get a single change out.<\/p>\n\n\n\n

    This made engineers<\/span> very frustrated and productivity<\/span><\/strong> was at an all-time low. So we need to figure out a way to improve our <\/strong>architecture so we could continue growing our business.” Enter microservices<\/a>.<\/p>\n\n\n\n

    Migrating to Microservices from a Service Orientated Architecture<\/h2>\n\n\n\n
    \"microservices<\/figure><\/div>\n\n\n\n

    \u00a0Airbnb<\/span> opted for service<\/span>-oriented architecture<\/span> (SOA<\/span>) – a network of loosely coupled services<\/span>, where some client makes a request flows through an API<\/span><\/a> gateway<\/span>, and that fans out to various other services<\/span>, which can call services<\/span> or other data<\/span> stores. According to Jessica, “the benefits that we saw for SOA<\/span> is that each service<\/span> is built independently and can be scaled separatel<\/strong>y as well. Smaller teams<\/span> of engineers<\/span> could work on a service<\/span> so it’s much easier to manage the changes. We hoped this would help solve our developer<\/span> velocity problems, as well as being able to introduce new verticals.”<\/p>\n\n\n\n

    Using<\/span> an SOA<\/span> lens we could now break a checkout page into different components. An example is the reservation service<\/span> pricing service<\/span>. And now there are beginning to look like a lot of services<\/span> on this one page that used to be handled by a single application<\/span>. How can we ensure that we’re not actually making a bigger mess and entanglement for ourselves?<\/p>\n\n\n\n

    Principles of Service Design applied to Microservices Migration <\/h2>\n\n\n\n