Jeff Yeary gave a presentation about seamlessly migrating platforms from .NET to Rails. He discussed his company's history with various platforms and why they chose to build a new global responsive Rails platform. Their basic approach was to transition APIs, create a responsive mobile site, adopt OAuth authentication, and use Zuul as a reverse proxy to route between the existing and new platforms. Zuul provides a simple way to route requests and choose which application to send them to while logging statistics.

1. The journey to rails
Seamless Migration
Jeffery Yeary
jeff@debug.ninja | http://debug.ninja

2. Who am I?
❖ Jeff Yeary
❖ Yes I made a slide with my name on it, otherwise I
would forget to have an introduction
❖ Software Architect
❖ 10 + Years, unique perspective

3. Outline
❖ Platform [ ~5 min ]
❖ History (~2 min)
❖ Why a new platform? (~2 min)
❖ Rails? (~1 min)
❖ Our basic approach [ ~15 min ]
❖ APIs (~3 min)
❖ Mobile / responsive site (~2 min)
❖ Authentication (~2 min)
❖ Zuul (~8 min)
❖ Q/A

4. Platform: History
❖ Tibco Platform (ASP / C++ / VB)
❖ Matrix Platform [US / INTL / MINI] (.Net)
❖ Hero Platform (.Net)
❖ Niche Platform (Rails 3.0)
❖ Highlander (Rails 3.0)
❖ Punchkick Tablet Platform (PHP outsourced)
❖ Mobile Site (PHP outsourced)
❖ Global Responsive Rails Platform (Rails 4)

5. Which of these is a competitive
advantage?
❖ Ability to scale to millions of users
❖ Ability to deploy multiple times a day
❖ Continuous Integration / Delivery
❖ Agile software development process
❖ Providing a compelling and engaging user experience

6. Why write another platform?
❖ Consistent user experience
❖ Focus our resources
❖ Actually think globally
❖ Global feature set
❖ Chance to name something (GRRP)

7. Platform: Rails
❖ Fast to deploy (.net was taking an hour to deploy)
❖ Fast to develop on (no local compilation)
❖ Community (rubygems > nuget packages)
❖ Mature

8. Our basic approach
❖ Changing the tires while the car is in motion
❖ Make the change with minimal disruption to the user
❖ Same URLs when needed
❖ Consistent look and feel
❖ Stay logged in across platforms
❖ Adopt SOA -> Create responsive website -> Maintain
login state between platforms -> Proxy between the
applications

9. Transitioning: APIs
❖ service-oriented architecture (SOA) is a style of
software architecture for designing and developing
software in the form of interoperable services. These
services have well-defined business functionalities that
are built as software components which can be reused
for different purposes
❖ Public API
❖ Delivery Mechanism

10. Transitioning: APIs
❖ 8 years ago
❖ Experiment
❖ Supports job search / job application
❖ Used to build an accessibility site
❖ 6 years ago
❖ Emerging
❖ Powers iOS, Android
❖ 4 years ago
❖ Established
❖ Powers our niche sites, some international sites
❖ 3 years ago
❖ Dogfooding stage
❖ Transition pages on the matrix platform to call the
same APIs

11. Transitioning: Mobile site
❖ Started with something impactful (nearly 50% off all of
our users are on non-desktop devices)
❖ Opportunity to end desktop / mobile divide
❖ Responsive (foundation)
❖ First version of this is two separate domains

12. Transitioning: Authentication
❖ Adopt an oauth authentication flow
❖ Two step flow (think facebook connect)
❖ Follow the facebook JS sdk methodology
❖ Each platform has its own session but checks back to
the mothership
❖ Javascript says something changed, we make a server to
server call to update our session

13. Transitioning: Reverse Proxy
❖ Now that we have feature parity on our rails platform
and we have a central authentication authority we need
a way to select between the platforms
❖ Previous experience using HAProxy, NGinx and Zuul

14. Zuul
❖ What is Zuul? ( github.com/Netflix/zuul )
❖ Why use zuul?
❖ Very low overhead
❖ Powerful language (java / groovy) for making changes
to requests
❖ Simple web app example
❖ Example does almost everything needed out of the
box

15. Zuul: High Level
❖ Pre
❖ Add a bunch of headers to the request
❖ Stats logging about the incoming urls
❖ Route
❖ Choose which application to go to, make the request
and send it back
❖ Post
❖ Stats logging about the time taken for each request

16. Zuul: It’s this simple
1. https://github.com/cbdr/consumer-zuul-www/blob/master/src/main/groovy/filters/route/SimpleHostRequest.groovy#L190
2. https://github.com/cbdr/consumer-zuul-www/blob/master/src/main/groovy/filters/route/SimpleHostRequest.groovy#L240

17. Zuul
❖ How are routes stored?
❖ Each record contains a domain, a destination and a list
of routes
{
“incoming_url” => “www.careerbuilder.com”,
“destination_elb” =>
“someelb.us-east1.elb.amazon.com”,
“routes” => [“/”, “/assets”, “/jobs/[:id]”]
}

18. Zuul
❖ Route Discovery ( bit.ly/routes-revealer )
❖ UI for turning routes on and off ( Show UI )

19. Conclusion / Questions