33. Boxcar
High Performance SOA Framework
http://go.indeed.com/boxcar
Image used with permission of O Scale Trains Magazine (oscalemag.com), photo credit Don McFall of Old Line Graphics
36. Challenge: Compatibility over Time
● Any service can be updated at any time
● Any client can be updated at any time
● Any service or client can be rolled back
unexpectedly
Every service conversation must be forward
and backwards compatible
37. Boxcar: API Compatibility
Represent complex data types
Extremely compact and performant
Forwards and backwards compatible
39. Hard Scenarios
New API
Old server doesn't understand new client
Same API, Different Behavior
Old client doesn't understand new server
New client doesn't understand old server
58. Indeed Web Properties Goals
Provide a consistent user experience
One implementation of shared functionality
Completely decoupled applications
59.
60. Option: Shared Libraries?
Reduced flexibility of technology decisions
Requires a release of all projects
Occasional inconsistent user experience
61. Option: Shared Resources?
On every app, include:
http://www.indeed.com/global/nav.js
http://www.indeed.com/global/nav.css
http://www.indeed.com/global/nav
62. Option: Common Resource
Reduced flexibility of technology decisions
Requires a release of all projects
Occasional inconsistent user experience
No shared services
76. Shared Code Across Platforms
● One code base for mobile web, iOS, Android
● Simultaneous release of features across
platforms
● No waiting for App Store approval
● No waiting for job seekers to upgrade
77. Easy To Reuse Infrastructure
● A/B testing in native apps challenging
● Activity tracking challenging
● Performance monitoring challenging
We have battle-hardened solutions to all these.
82. But what about the hard stuff?
● Configuration changes
● Resource re-allocation
● Database schema updates
● Internationalization
83. But what about the hard stuff?
● Configuration changes
● Resource re-allocation
● Database schema updates
● Internationalization
http://go.indeed.com/i18n
85. tek arama. bütün işler.
one search. all jobs.
uma busca. todos os empregos.
één klik. alle vacatures.
una búsqueda. todos los empleos.
Ein Klick. Alle Jobs.
一站搜尋,工作齊全
Jedno vyhledávání. Všechna pracovní místa.
あらゆる仕事まとめて検索
una ricerca. tutti i lavori.
117. Healthcheck Framework
● Applications and services self-report
internal state & health
● Divert traffic away from unhealthy instances
● Disable features for failing dependencies
For the rest of this I’ll focus on how Indeed delivers new functionality to jobseekers and how we’ve increased our ability to do this quickly - something we’ve started calling ENGINEERING VELOCITY.
Although the job search web app was large, it was structured well internally, with separate MODULES responsible for implementing specific pieces of functionality. This allowed individuals or small teams to focus on each MODULES and improve it’s capabilities.
This wasn’t enough though - because the entire application was released as a single DELIVERABLE, it meant all of the teams needed to be ready to release at the same time.
Before we could move the job search application to an SOA, there were some technical challenges that we needed to address.
If the overhead of a service call was more than a few milliseconds, then the AGGREGATE COST of the overhead for the service calls would have a large negative impact on jobseekers.
The logic to determine which behavior should be used for a request is dynamic and can incorporate any criteria needed to segment a visitor including
* if a jobseeker is logged in
* the device or browser they’re using,
* or their country and language
Proctor can also randomly determine the behavior to use for visitors who meet specific criteria.
Industry Trends
salary pages
Each of these pages is different.
* OFFER DIFFERENT FEATURES
* ACCESS DIFFERENT DATA
* DIFFERENT OPERATIONAL REQUIREMENT
* HAD A DIFFERENT TEAM FOCUSED ON THEM
Just like all of the components in the Job Search application, if we were to implement this functionality into separate components we can release them independently and on different schedules, allowing each product to deliver new functionality more quickly.
Here is the a company information page, which is served by the company pages webapp via navshell
The part in blue is generated by the company page webapp.
The content in orange at the top of the page is generated by Navshell.
Navshell assembles all of the content into a complete page and returns it to the browser.
We typically only implement something in native code when it’s not possible for us to do it inside of the web view.
Since we originally launched our mobile applications, the approach to deliver most of the functionality within the web view has become a strategic part of how we are able to deliver new functionality quickly for mobile users.
We have shared infrastructure for implementing the desktop and mobile search applications.
Myth of responsive design
Eng: runs releases
Product: available for game-day calls
QA: balances engineering optimism
The extra steps meant that user visible changes needed to be complete ONE DAY earlier than normal.
With our short release cycles, ONE DAY meant 20% OR MORE.
We first looked into a machine translation service. This seemed like the ideal - commit change to the UI, the user-visible strings would be immediately extracted and translated within seconds.
The results were not as good as we hoped though and there were too many cases where the results were unacceptable. For example, we used the word “CADASTRADO” to ask someone if they were already registered with Indeed. A JOBSEEKER in Brazil would understand this, but a jobseeker from Portugal would wonder why we’re asking if they have a criminal record
This has allowed us to QUICKLY DELIVER NEW FEATURES WORLDWIDE and increased our ENGINEERING VELOCITY. It also means we can make sure we’re building the best products for JOBSEEKERS all around the world.
As Indeed recognized the value of rapid iteration and moved towards a decoupled architecture, the number of releases that were being done each week grew quickly. This meant we needed to be more deliberate about how we managed risk and avoided negatively impacting jobseekers.
Source: deploy tickets in jira
2010, 2014 est
Feature toggles allow us to have all of the functionality implemented and running in production, but in code paths that will not be exercised.
For example we can use this to launch new features and test them internally in prod environment before making them available to jobseekers.
Proctor has also allowed us to make lots of small changes to group allocations when rolling out tests or new features that are especially risky or resource intensive.
We can enable a new feature for 1% of traffic, then up to 100% all within a day or even a few hours.
This allows us to identify bugs or scalability issues when they’re only affecting a few users and quickly address them.
Everything I’ve discussed tonight has been built incrementally just like our products, to meet the challenges we faced in increasing our Engineering Velocity.