Enterprise Architectures with Ruby (and Rails)

Enterprise Architecture withRuby (and Rails)Building amazing products, companies andtechnology using Ruby on Rails and friends.An opinionated overview for MagmaRails.MX byKonstantin Gredeskoul, CTO, Wanelo, Inctwitter: @kig, github.com/kigster

My Background CTO @ Wanelo.com — “Pinterest for shopping” Principal @ ModCloth.com — is one of the largest independent e-commerce Rails sites Principal @ Blurb.com — print-on-demand bookstore, and a large e-commerce web site Professionally building enterprise software since 1995 Converted from Java/Perl/C to ruby in 2006

What is Enterprise?

What is Enterprise?It’s an organization with many people,services, technologies

What is Enterprise?It’s an organization with many people,services, technologiesEnterprise architecture is an ongoingbusiness function that helps an enterpriseﬁgure out how to best execute the strategiesthat drive its development [ref: wikipedia]

From Start-Up To Enterprise

From Start-Up To EnterpriseMany modern enterprises started small, astiny start-ups

From Start-Up To EnterpriseMany modern enterprises started small, astiny start-upsMany start-ups choose RoR for productivity

From Start-Up To EnterpriseMany modern enterprises started small, astiny start-upsMany start-ups choose RoR for productivityAs the start-up grows, so does the technology,applications, and the stack.

Teams using RoR can bevery productive

Teams using RoR can bevery productiveProductivity is super important for unprovenyoung companies trying things out

Teams using RoR can bevery productiveProductivity is super important for unprovenyoung companies trying things out“Build quickly, iterate, avoid building featuresusers don’t need” — Lean Start-Up Movement

Teams using RoR can bevery productiveProductivity is super important for unprovenyoung companies trying things out“Build quickly, iterate, avoid building featuresusers don’t need” — Lean Start-Up MovementDo not optimize “prematurely”, but think abouttomorrow’s scalability when building today.

Productivity vs Scale:The Dilemma!

Productivity vs Scale:The Dilemma!To move fast - we use Ruby (dynamiclanguages), a framework (Rails), cloud, afamiliar database, and keep the team small

Productivity vs Scale:The Dilemma!To move fast - we use Ruby (dynamiclanguages), a framework (Rails), cloud, afamiliar database, and keep the team smallTo truly scale an application - need multiplelanguages (Java, C/C++, Scala), custom or noframeworks, datacenter, large team

But does everyone needmega scale?

But does everyone needmega scale?Majority of Rails projects are OK without mega-scale (only a tiny fraction is like Twitter or Facebook)

But does everyone needmega scale?Majority of Rails projects are OK without mega-scale (only a tiny fraction is like Twitter or Facebook)Ruby/Rails can happily grow into a largeapplications without major rewrites

But does everyone needmega scale?Majority of Rails projects are OK without mega-scale (only a tiny fraction is like Twitter or Facebook)Ruby/Rails can happily grow into a largeapplications without major rewritesBest assurance that an application will growwell with it’s use, is to follow best practices.

So what is this talk about?

So what is this talk about? How to start small But move fast

So what is this talk about? How to start small But move fast How to evolve a Rails app But keep it scalable

So what is this talk about? How to start small But move fast How to evolve a Rails app But keep it scalable How to split things up When the app gets large, and keep everyone sane

Part 1:How to start small, but move fast

Get a great team together

Get a great team together Keep team size small, 4-6 developers is ideal

Get a great team together Keep team size small, 4-6 developers is ideal Have at least 2-3 ruby/rails/front-end experts on the team

Get a great team together Keep team size small, 4-6 developers is ideal Have at least 2-3 ruby/rails/front-end experts on the team Do automated testing (and TDD) from the beginning. Hard to add later.

Process matters

Process matters Paired Programming is amazing. Level the ﬁeld, transfer knowledge, build trust within the team, move faster

Process matters Paired Programming is amazing. Level the ﬁeld, transfer knowledge, build trust within the team, move faster Morning stand-ups, weekly sprint planners, technical discussions as needed, retrospectives

Process matters Paired Programming is amazing. Level the ﬁeld, transfer knowledge, build trust within the team, move faster Morning stand-ups, weekly sprint planners, technical discussions as needed, retrospectives Dedicated graphic designer/UXR, and a Product Manager

Everyday tools matter

Everyday tools matter RubyMine IDE is very powerful, but $69 Other tools also work, VIM, TextMate

Everyday tools matter RubyMine IDE is very powerful, but $69 Other tools also work, VIM, TextMate When pairing, using consistent toolset is very important. Pick it and stick to it.

Everyday tools matter RubyMine IDE is very powerful, but $69 Other tools also work, VIM, TextMate When pairing, using consistent toolset is very important. Pick it and stick to it. If everyone has their own laptop, create a common OS account and use it to pair

Communication is key

Communication is key Continuous Integration server runs all automated tests (Jenkins is great!) Everyone knows when tests break!

Communication is key Continuous Integration server runs all automated tests (Jenkins is great!) Everyone knows when tests break! Pivotal CI Monitor open source app pulls from Jenkins

Communication is key

Communication is key Use Chat (eg, Campﬁre) to notify team about check-ins, deploys or failed builds

Communication is key Use Chat (eg, Campﬁre) to notify team about check-ins, deploys or failed builds Review other’s commits (ie, on GitHub) to learn as much code as possible

Communication is key Use Chat (eg, Campﬁre) to notify team about check-ins, deploys or failed builds Review other’s commits (ie, on GitHub) to learn as much code as possible Take care of your team mates, and do worry about the project. Success depends on it.

A few more awesome tools*

A few more awesome tools* iTerm2 - free mega awesome Terminal replacement (Cmd-D/Cmd-Shift-D)

A few more awesome tools* iTerm2 - free mega awesome Terminal replacement (Cmd-D/Cmd-Shift-D) SizeUp - align windows on the screen right/left/ up/down/middle.

A few more awesome tools* iTerm2 - free mega awesome Terminal replacement (Cmd-D/Cmd-Shift-D) SizeUp - align windows on the screen right/left/ up/down/middle. iStat Menus - view CPU, Network IO, Disk in Mac OS-X Toolbar

A few more awesome tools* iTerm2 - free mega awesome Terminal replacement (Cmd-D/Cmd-Shift-D) SizeUp - align windows on the screen right/left/ up/down/middle. iStat Menus - view CPU, Network IO, Disk in Mac OS-X Toolbar CCMenu - view results of CI in your toolbar

Choice of libraries matters

Choice of libraries matters MiniTest, Jasmine, Capybara (RackTest + Selenium) for testing

Choice of libraries matters MiniTest, Jasmine, Capybara (RackTest + Selenium) for testing Devise for authentication, user mgmt

Choice of libraries matters MiniTest, Jasmine, Capybara (RackTest + Selenium) for testing Devise for authentication, user mgmt Twitter Bootstrap for early UI is amazing although we prefer SCSS instead of LESS

Choice of libraries matters MiniTest, Jasmine, Capybara (RackTest + Selenium) for testing Devise for authentication, user mgmt Twitter Bootstrap for early UI is amazing although we prefer SCSS instead of LESS HAML for views, RABL for APIs

Data matters the most

Data matters the most Relational Databases: PostgreSQL, MySQL High consistency, reliability, decades of research, great performance, gets tricky at mega-scale

Data matters the most Relational Databases: PostgreSQL, MySQL High consistency, reliability, decades of research, great performance, gets tricky at mega-scale BigTable based: MongoDB, HBase Eventual consistency, recent, have indexes, almost table-like. Also tricky at mega scale.

Data matters the most Relational Databases: PostgreSQL, MySQL High consistency, reliability, decades of research, great performance, gets tricky at mega-scale BigTable based: MongoDB, HBase Eventual consistency, recent, have indexes, almost table-like. Also tricky at mega scale. Amazon Dynamo like: RIAK, Voldemort Distributed hash-table, tricky from the very beginning.

What to choose?

What to choose? Without a strong reason otherwise, choose a relational database. I prefer PostgreSQL.

What to choose? Without a strong reason otherwise, choose a relational database. I prefer PostgreSQL. Instagram scaled on PostgreSQL very well

What to choose? Without a strong reason otherwise, choose a relational database. I prefer PostgreSQL. Instagram scaled on PostgreSQL very well If under pressure and in doubt, it’s OK to choose whatever you are familiar with.

Part 2:How to evolve a Rails App

New Rails Project: Day 1

New Rails Project: Day 1rails new my-awesome-appcd my-awesome-apprake db:migrate

New Rails Project: Day 1rails new my-awesome-appcd my-awesome-apprake db:migrate ruby 1.9.3-p125 rails 3.2.3 macbook air 1.8Ghz

incoming http1. Starting Up One app server, one db, nginx 10 unicorns per app server Unicorn // Passenger Unicorn Passenger Ruby Ruby VM N) VM (times nginx for static assets PostgreSQL for data Always put your DB on a separate server DB Cloud

incoming http1. Starting Up nginx Unicorn // Passenger Unicorn Passenger Ruby Ruby VM N) VM (times DB

incoming http1. Starting Up nginxSimple, but no app server Unicorn // Passenger Unicorn Passengerredundancy, limited Ruby Ruby VM N) VM (timesthroughput DB

incoming http1. Starting Up nginxSimple, but no app server Unicorn // Passenger Unicorn Passengerredundancy, limited Ruby Ruby VM N) VM (timesthroughput10 unicorns = 10concurrent requests at any DBone time

incoming http2. Growing Up nginxSplit into multiple App Unicorn // Passenger Unicorn PassengerServers Ruby Ruby VM N) VM (timesHAProxy to distribute loadnginx for static ﬁles foundon local ﬁle system, proxyrequests otherwise DB

incoming http2. Growing Up nginx haproxySplit into multiple AppServers Unicorn Unicorn / PassengerHAProxy to distribute load Ruby VM Ruby VMnginx for static ﬁles foundon local ﬁle system, proxyrequests otherwise DB

incoming http2. Growing Up nginx haproxySite usage grows.Responses get slow. Unicorn Unicorn / Passenger Ruby VM Ruby VM DB

incoming http2. Growing Up nginx haproxySite usage grows.Responses get slow. Unicorn Unicorn / Passenger Ruby VM Ruby VMStarted at 150ms, then400ms, then 700ms.... DB

incoming http3. Scaling Up nginx haproxy Unicorn Unicorn / Passenger Ruby VM Ruby VM DB

incoming http3. Scaling Up nginx Add MemCached (1Gb+) haproxy Unicorn Unicorn / Passenger Ruby VM Ruby VM DB

incoming http3. Scaling Up nginx Add MemCached (1Gb+) haproxy Use Redis (or cookies) for sessions (reduce db load) Unicorn Unicorn / Passenger Ruby VM Ruby VM DB

incoming http3. Scaling Up nginx Add MemCached (1Gb+) haproxy Use Redis (or cookies) for sessions (reduce db load) Unicorn Unicorn / Passenger Ruby VM Ruby VM memcache redis DB

incoming http3. Scaling Up nginx Add MemCached (1Gb+) haproxy Use Redis (or cookies) for sessions (reduce db load) Unicorn Unicorn / Passenger Ruby VM Ruby VM memcache Add action caching (even short TTL helps, i.e. 1min) redis DB

incoming http3. Scaling Up nginx Add MemCached (1Gb+) haproxy Use Redis (or cookies) for sessions (reduce db load) Unicorn Unicorn / Passenger Ruby VM Ruby VM memcache Add action caching (even short TTL helps, i.e. 1min) redis Use AJAX to personalize pages to make them cacheable* DB

Personalization with AJAX -A brief de-tour

Personalization with AJAX -A brief de-tour1. Logged in (or not) user requests a page...

Personalization with AJAX -A brief de-tour1. Logged in (or not) user requests a page...2. Page is served from the cache without any personalization (no “Hi John!”, “Logout”, etc)

Personalization with AJAX -A brief de-tour1. Logged in (or not) user requests a page...2. Page is served from the cache without any personalization (no “Hi John!”, “Logout”, etc)3. on document.ready: AJAX hits the server, gets tiny JSON data of the current user (or “not logged in”)

Personalization with AJAX -A brief de-tour1. Logged in (or not) user requests a page...2. Page is served from the cache without any personalization (no “Hi John!”, “Logout”, etc)3. on document.ready: AJAX hits the server, gets tiny JSON data of the current user (or “not logged in”)4. JS modiﬁes the DOM to show user’s logged in state, any other personalization, or “Log In”.

Personalization with AJAX -How?

Personalization with AJAX -Where?

Personalization with AJAX -Why?

Personalization with AJAX -Why? Because entire page can be served from the cache (often 50Kb+ per request)

Personalization with AJAX -Why? Because entire page can be served from the cache (often 50Kb+ per request) No ActiveRecord and no rendering makes it really fast!

Personalization with AJAX -Why? Because entire page can be served from the cache (often 50Kb+ per request) No ActiveRecord and no rendering makes it really fast! Recent rough test using Rails 3.2.3, ruby 1.9.3-p194, memcached: 4ms latency!!!

Why not page caching?

Why not page caching? Because unlike action caching, page caching is ﬁle-system based.

Why not page caching? Because unlike action caching, page caching is ﬁle-system based. Because it’s more difﬁcult to expire

Why not page caching? Because unlike action caching, page caching is file-system based. Because it’s more difficult to expire Because it’s more difficult to share across many servers

incoming http4. Scaling Images nginx haproxy We are serving lots of images. Nginx is getting slammed. Unicorn Unicorn / Passenger Ruby VM memcache Ruby VM redis DB

incoming http4. Scaling Images nginx haproxy We are serving lots of images. Nginx is getting slammed. Unicorn Unicorn / Passenger Ruby VM memcache Ruby VM Should we add more redis balancers? Write our own? DB

incoming http4. Scaling Images nginx haproxy We are serving lots of images. Nginx is getting slammed. Unicorn Unicorn / Passenger Ruby VM memcache Ruby VM Should we add more redis balancers? Write our own? DB HELLZ NO!

incoming incoming http http4. Scaling Images CDN cache images, JS nginx haproxy Unicorn // Passenger Unicorn Passenger RubyRuby VM N) VM (times memcache redis DB

incoming incoming http http4. Scaling Images CDN cache images, JS Don’t wait to use a CDN to SERVE images, especially nginx user-uploaded images. haproxy Unicorn // Passenger Unicorn Passenger RubyRuby VM N) VM (times memcache redis DB

incoming incoming http http4. Scaling Images CDN cache images, JS Don’t wait to use a CDN to SERVE images, especially nginx user-uploaded images. haproxy S3 is a popular choice to STORE images. Unicorn // Passenger Unicorn Passenger RubyRuby VM N) VM (times memcache redis DB

incoming incoming http http4. Scaling Images CDN cache images, JS Don’t wait to use a CDN to SERVE images, especially nginx user-uploaded images. haproxy S3 is a popular choice to STORE images. Unicorn // Passenger Unicorn Passenger RubyRuby VM N) VM (times memcache But it’s smart to keep a redis local backup copy... DB

incoming incoming http http5. Deployments and CDN Downtime cache images, JS Our site is popular! nginx And our users hate haproxy downtime. Unicorn // Passenger Unicorn Passenger RubyRuby VM N) VM (times memcache redis DB

incoming incoming http http5. Deployments and CDN Downtime cache images, JS Our site is popular! nginx And our users hate haproxy downtime. Unicorn // Passenger Unicorn Passenger RubyRuby VM N) VM (times memcache They really really do. redis DB

5. Deployments and Downtime

5. Deployments and Downtime We want to be able to deploy the code while the site is running. So users are happy.

5. Deployments and Downtime We want to be able to deploy the code while the site is running. So users are happy. There are several ways to do that.

5. Deployments and Downtime We want to be able to deploy the code while the site is running. So users are happy. There are several ways to do that. This solution uses DNS round robin with two balancers, and two public IP addresses.

Two Cluster Solution = Almost Zero Downtime incoming http incoming http balancer1 balancer2 nginx nginx haproxy haproxyUnicorn // PassengerUnicorn Passenger Unicorn // Passenger Unicorn PassengerRubyRuby VM N) VM (times memcache memcache RubyRuby VM N) VM (times redis DB

Temporary Redirect Rule

Two Clusters are cool!

Two Clusters are cool! Cluster 1 runs old code and is live

Two Clusters are cool! Cluster 1 runs old code and is live Cluster 2 gets new code

Two Clusters are cool! Cluster 1 runs old code and is live Cluster 2 gets new code Old and new run in parallel, but only one is serving live trafﬁc

Migrations with ZeroDowntime?

Migrations with ZeroDowntime? Almost possible on a live system, if:

Migrations with ZeroDowntime? Almost possible on a live system, if: We are not removing or renaming columns or tables in active use

Migrations with ZeroDowntime? Almost possible on a live system, if: We are not removing or renaming columns or tables in active use Migrations do not lock tables (for too long)

Migrations with ZeroDowntime? Almost possible on a live system, if: We are not removing or renaming columns or tables in active use Migrations do not lock tables (for too long) Column/Table renames/deletes can be done in two deployments instead of one

So the app is now faster, and wecan deploy without a downtime

So the app is now faster, and wecan deploy without a downtime What about email and other long-running tasks?

So the app is now faster, and wecan deploy without a downtime What about email and other long-running tasks? Don’t forget SPF records.

incoming httpBackground Jobs withResque balancer1 nginxBut monitor it’s queues haproxyMust restart on reboot Resque Workers Unicorn memcache redis DB

incoming httpBackground Jobs withResque balancer1 nginxBut monitor it’s queues haproxyMust restart on reboot Resque Workers Unicorn memcache redisresque-cleaner isawesome! DB

Different queues for different types of jobs

Different queues for different types of jobsRelatively easy to implement priorities for Jobs(order queues by priority)

Different queues for different types of jobsRelatively easy to implement priorities for Jobs(order queues by priority)Group Jobs by execution times to avoid delays

Different queues for different types of jobsRelatively easy to implement priorities for Jobs(order queues by priority)Group Jobs by execution times to avoid delays Resque::Worker x N QUEUE=SlowQueue1,SlowQueue2 redis Resque::Worker x M QUEUE=FastQueue1,FastQueue2

DB Usage and complexity grows.We are doing big joins with manytables, and they are taking their sweettime.

Solr to the Resque

Solr to the Resque Use Solr instead of doing complex joins

Solr to the Resque Use Solr instead of doing complex joins Solr reads are < 10ms

Solr to the Resque Use Solr instead of doing complex joins Solr reads are < 10ms Sunspot Gem by default writes to Solr from each ruby VM (i.e. unicorn)!

Solr to the Resque Use Solr instead of doing complex joins Solr reads are < 10ms Sunspot Gem by default writes to Solr from each ruby VM (i.e. unicorn)! Serialize writes with Resque!

Solr to the Resque Use Solr instead of doing complex joins Solr reads are < 10ms Sunspot Gem by default writes to Solr from each ruby VM (i.e. unicorn)! Serialize writes with Resque! One master for writes

Solr to the Resque Use Solr instead of doing complex joins Solr reads are < 10ms Sunspot Gem by default writes to Solr from each ruby VM (i.e. unicorn)! Serialize writes with Resque! One master for writes Read replicas on each app server

Putting it together Unicorn Unicorn / Workers Resque Passenger Unicorn / Passenger Ruby VM Ruby VM 3. Update Solr solr_replica 4. Replicate solr_master 2. Read Model Info 1. Model Changed redis DB

At this size...

At this size...Automate everythingChef or Puppet is awesome

At this size...Automate everythingChef or Puppet is awesomeMonitor everythingTolerate reboots, restarts, partial failures

At this size...Automate everythingChef or Puppet is awesomeMonitor everythingTolerate reboots, restarts, partial failuresUse OS services layer to start/stop everythingEnsures recovery after reboot

At this size...Automate everythingChef or Puppet is awesomeMonitor everythingTolerate reboots, restarts, partial failuresUse OS services layer to start/stop everythingEnsures recovery after rebootCapistrano tends to gets “complex”Can also deploy with Chef

Choose Vendors WiselyYou can pick your own, but here is my list:

Choose Vendors WiselyYou can pick your own, but here is my list: Clouds - JOYENT, EngineYard fastest I/O cloud, but on Solaris derivative

Choose Vendors WiselyYou can pick your own, but here is my list: Clouds - JOYENT, EngineYard fastest I/O cloud, but on Solaris derivative Automation - Chef + OPSCODE

Choose Vendors WiselyYou can pick your own, but here is my list: Clouds - JOYENT, EngineYard fastest I/O cloud, but on Solaris derivative Automation - Chef + OPSCODE Caching/CDN - FASTLY.COM varnish based CDN, very fast, full power of VCL conﬁguration

Choose Vendors WiselyYou can pick your own, but here is my list: Clouds - JOYENT, EngineYard fastest I/O cloud, but on Solaris derivative Automation - Chef + OPSCODE Caching/CDN - FASTLY.COM varnish based CDN, very fast, full power of VCL conﬁguration Metrics and Performance - NewRelic Turnkey solution, getting better every day

In Development

In DevelopmentUse foreman to start dependent services (Solr,Redis, Resque) from a Procﬁle

In DevelopmentUse foreman to start dependent services (Solr,Redis, Resque) from a ProcﬁleDo “Just enough” testing with Solr - it’s slow!

In DevelopmentUse foreman to start dependent services (Solr,Redis, Resque) from a ProcﬁleDo “Just enough” testing with Solr - it’s slow!Deploy to single-box demo servers often usingthe same Capistrano scripts used forproduction

Mature App: Day 700

Mature App: Day 700cd my-awesome-apprake rspec:models rspec:controllers rspec:libsrake cucumber:webrat cucumber:selenium jasmine

How Big Exactly?

How Big Exactly?200+ models200K+ lines of RUBY source code without gems100K+ lines of ERB, HTML and HAML templates100+ gem dependencies

How Big Exactly?200+ models200K+ lines of RUBY source code without gems100K+ lines of ERB, HTML and HAML templates100+ gem dependenciesthis is a real world application that’s in production today.

Is that too big?

Is that too big? This cat’s name is Lenin

Here is why I think it is.

Here is why I think it is.1.5+ hours for the full the test suite to complete10 mins of db seeds, 30 minutes for unit tests only, etc

Here is why I think it is.1.5+ hours for the full the test suite to complete10 mins of db seeds, 30 minutes for unit tests only, etcmerges often result in integration tests going RED

Here is why I think it is.1.5+ hours for the full the test suite to complete10 mins of db seeds, 30 minutes for unit tests only, etcmerges often result in integration tests going RED20 seconds boot-up time for Rails env (r console, etc)!

Here is why I think it is.1.5+ hours for the full the test suite to complete10 mins of db seeds, 30 minutes for unit tests only, etcmerges often result in integration tests going RED20 seconds boot-up time for Rails env (r console, etc)!500Mb of RSS RAM for one single-threaded web process

Here is why I think it is.1.5+ hours for the full the test suite to complete10 mins of db seeds, 30 minutes for unit tests only, etcmerges often result in integration tests going RED20 seconds boot-up time for Rails env (r console, etc)!500Mb of RSS RAM for one single-threaded web processit’s a difﬁcult undertaking to upgrade dependencies and rails

It was much nicer when it was a bit smaller..

Let’s zoom in...

Let’s zoom in...Is PERFORMANCE of the app an issue?

Let’s zoom in...Is PERFORMANCE of the app an issue? NO! 150ms per request avg

Let’s zoom in...Is PERFORMANCE of the app an issue? NO! 150ms per request avgIs SCALABILITY of the app an issue?

Let’s zoom in...Is PERFORMANCE of the app an issue? NO! 150ms per request avgIs SCALABILITY of the app an issue? NO! 8000+ concurrent users

Let’s zoom in...Is PERFORMANCE of the app an issue? NO! 150ms per request avgIs SCALABILITY of the app an issue? NO! 8000+ concurrent usersIs RELIABILITY of the app an issue?

Let’s zoom in...Is PERFORMANCE of the app an issue? NO! 150ms per request avgIs SCALABILITY of the app an issue? NO! 8000+ concurrent usersIs RELIABILITY of the app an issue? NO! barely any downtime in over one year

Then WTF is the Problem?

Then WTF is the Problem?Is PRODUCTIVITY of developing the app an issue?

Then WTF is the Problem?Is PRODUCTIVITY of developing the app an issue? YES! Lots of waiting all the time

Then WTF is the Problem?Is PRODUCTIVITY of developing the app an issue? YES! Lots of waiting all the timeIs MERGING source code between parallel projects difﬁcult?

Then WTF is the Problem?Is PRODUCTIVITY of developing the app an issue? YES! Lots of waiting all the timeIs MERGING source code between parallel projects difﬁcult? YES! 30+ people sharing large codebase

Then WTF is the Problem?Is PRODUCTIVITY of developing the app an issue? YES! Lots of waiting all the timeIs MERGING source code between parallel projects difﬁcult? YES! 30+ people sharing large codebaseIs KEEPING TEST SUIT GREEN challenging?

Then WTF is the Problem?Is PRODUCTIVITY of developing the app an issue? YES! Lots of waiting all the timeIs MERGING source code between parallel projects difﬁcult? YES! 30+ people sharing large codebaseIs KEEPING TEST SUIT GREEN challenging? YES! tests are brittle and long running

But wait, there’s more!

But wait, there’s more! What about DEPLOYMENT of a large app? Takes a long time, and small tweaks require full deploys

But wait, there’s more! What about DEPLOYMENT of a large app? Takes a long time, and small tweaks require full deploys What about HOSTING COSTS? Necessary to provide enough RAM for the app to be scalable.

RAM? Latency matters...

RAM? Latency matters... 1 Request = 200ms on average latency 5 reqs/second on a single-threaded ruby VM process

RAM? Latency matters... 1 Request = 200ms on average latency 5 reqs/second on a single-threaded ruby VM process 30,000 RPM = 500 r/sec = 100 processes 50Gb of RAM @ 200ms latency If average latency is 600ms, need 150Gb of RAM !!!

Smaller is actually better.

So how do we solve this?

Part 3:How to split things up

Couple of main themes

Couple of main themes Break up into smaller applications

Couple of main themes Break up into smaller applications Extract services and create APIs

Couple of main themes Break up into smaller applications Extract services and create APIs Extract libraries (gems)

Smaller Applications

Smaller Applications Contain web GUI, logic, and data

Smaller Applications Contain web GUI, logic, and data May combine with other apps

Smaller Applications Contain web GUI, logic, and data May combine with other apps May rely on common libraries

Smaller Applications Contain web GUI, logic, and data May combine with other apps May rely on common libraries May rely on services

Smaller Applications Contain web GUI, logic, and data May combine with other apps May rely on common libraries May rely on services Typically run in their own Ruby VM

Consider a Typical E-Commerce Store

Consider a Typical E-Commerce Store Users must be able to register, login, logout (proﬁles)

Consider a Typical E-Commerce Store Users must be able to register, login, logout (proﬁles) Users must be able to browse and search products, view, and add to cart

Consider a Typical E-Commerce Store Users must be able to register, login, logout (proﬁles) Users must be able to browse and search products, view, and add to cart Users must be able to checkout

Consider a Typical E-Commerce Store Users must be able to register, login, logout (proﬁles) Users must be able to browse and search products, view, and add to cart Users must be able to checkout Probably many other stories, such as admin, but we’ll ignore for now.

One idea...

One idea... Application 1: Marketing, Product Catalog Browser, Search + Product Detail Page

One idea... Application 1: Marketing, Product Catalog Browser, Search + Product Detail Page Application 2: Checkout, Payment, Order History, Returns Fulﬁllment

One idea... Application 1: Marketing, Product Catalog Browser, Search + Product Detail Page Application 2: Checkout, Payment, Order History, Returns Fulﬁllment Very clear user ﬂow transfer and data separation.

Some things can be shared

Some things can be shared Service: Single Sign-on, User proﬁles, Login/Registration [devise?, rest-full authentication?]

Some things can be shared Service: Single Sign-on, User proﬁles, Login/Registration [devise?, rest-full authentication?] Service: Product Catalog data, Inventory Data

Some things can be shared Service: Single Sign-on, User proﬁles, Login/Registration [devise?, rest-full authentication?] Service: Product Catalog data, Inventory Data Service: Comments, Votes, Ratings, Reviews

Services Technologies

Services Technologies Rack/Sinatra/Rails are popular, and are often an entirely sufﬁcient choice

Services Technologies Rack/Sinatra/Rails are popular, and are often an entirely sufﬁcient choice Goliath is awesome if performance is important, and if the service is mostly I/O bound

Services Technologies Rack/Sinatra/Rails are popular, and are often an entirely sufﬁcient choice Goliath is awesome if performance is important, and if the service is mostly I/O bound node.js is also a popular choice

Services Technologies Rack/Sinatra/Rails are popular, and are often an entirely sufﬁcient choice Goliath is awesome if performance is important, and if the service is mostly I/O bound node.js is also a popular choice Implementation may change in the future, as long as the API stays consistent

http balancer / router /checkout → checkout app /* → catalog app catalog app checkout app cart DB CSS/UI Library DBProduct Service Reviews, User Auth / Login Inventory Comments, Proﬁles Votes, Ratings DB DB DB

http balancer / router /checkout → checkout app /* → catalog app catalog app checkout app CSS/UI Library DB DBProduct Service Reviews, User Auth / Login Inventory Comments, Proﬁles Votes, Ratings DB DB DB

http balancer / routerExtract look and feel /checkout → checkout app /* → catalog app(CSS/UI) into a gem to catalog app checkout appshare across apps CSS/UI Library DB DB Product Service Reviews, User Auth / Login Inventory Comments, Proﬁles Votes, Ratings DB DB DB

http balancer / routerExtract look and feel /checkout → checkout app /* → catalog app(CSS/UI) into a gem to catalog app checkout appshare across apps CSS/UI Library DB DBCreate client API wrapper Product Service Reviews, User Auth / Logingems for consumers Inventory Comments, Proﬁles Votes, Ratings DB DB DB

http balancer / routerExtract look and feel /checkout → checkout app /* → catalog app(CSS/UI) into a gem to catalog app checkout appshare across apps CSS/UI Library DB DBCreate client API wrapper Product Service Reviews, User Auth / Logingems for consumers Inventory Comments, Proﬁles Votes, Ratings DB DB DBCreate a single shared“base” client gem library

Rails App with < 30 Models

Rails App with < 30 Models Can run tests pretty quickly, hopefully under 5 minutes

Rails App with < 30 Models Can run tests pretty quickly, hopefully under 5 minutes Is often large enough to describe typical “clusters of functionality”, i.e. - mini apps

Rails App with < 30 Models Can run tests pretty quickly, hopefully under 5 minutes Is often large enough to describe typical “clusters of functionality”, i.e. - mini apps Ruby VM might actually stay under 100Mb of RSS RAM

Rails App with < 30 Models Can run tests pretty quickly, hopefully under 5 minutes Is often large enough to describe typical “clusters of functionality”, i.e. - mini apps Ruby VM might actually stay under 100Mb of RSS RAM Is more comprehensible and can be effectively maintained by a small dev team.

3rd Party Integrations catalog app checkout app analytics ﬁnancial warehouse and ERP system management reporting system CSS/UI LibraryDB DB Product Service Reviews, User Auth / Login Inventory Comments, Proﬁles Votes, Ratings DB DB DB

Ecosystem of Applications

Ecosystem of Applications Is inevitable in large companies

Ecosystem of Applications Is inevitable in large companies Scale better from team perspective

Ecosystem of Applications Is inevitable in large companies Scale better from team perspective Offer decoupling and implementation hiding

Ecosystem of Applications Is inevitable in large companies Scale better from team perspective Offer decoupling and implementation hiding Can be individually optimized and scaled

But then...Must every app know aboutevery other app?

API Proxy / Router catalog app checkout app analytics ﬁnancial and ERP CSS/UI LibraryDB DB reporting system http://api.mycompany.com/ Product Service Reviews, User Auth / Login Inventory Comments, Proﬁles Votes, Ratings DB DB DB

Example: Order Placed

Example: Order Placed Warehouse Management System needs to be updated

Example: Order Placed Warehouse Management System needs to be updated Analytics Engine needs to be notiﬁed

Example: Order Placed Warehouse Management System needs to be updated Analytics Engine needs to be notiﬁed Financials needs to be updated

Example: Order Placed Warehouse Management System needs to be updated Analytics Engine needs to be notiﬁed Financials needs to be updated Question: which component is responsible for updating each application?

1995 Was Great

1995 Was Great GoF Design Patterns: Observer “...One-to-Many dependency between objects so that when one object changes state, all its dependents are notiﬁed and updated automatically...”

Distributed Version

Distributed VersionPublish/Subscribe and Point-to-Point Asynchronous Middleware

RabbitMQ is Great

Some Options for Pub/Sub

Some Options for Pub/SubRabbitMQ ruby-amqp gem to interface

Some Options for Pub/SubRabbitMQ ruby-amqp gem to interfaceEventMachine::Channel

Other Distributed Options

Other Distributed OptionsDRb - distributed Ruby (also Rinda, Starﬁsh,beanstalkd, etc)

Other Distributed OptionsDRb - distributed Ruby (also Rinda, Starﬁsh,beanstalkd, etc)DCell - actor based based on 0MQhttp://www.unlimitednovelty.com/2012/04/introducing-dcell-actor-based.html

Other Distributed OptionsDRb - distributed Ruby (also Rinda, Starﬁsh,beanstalkd, etc)DCell - actor based based on 0MQhttp://www.unlimitednovelty.com/2012/04/introducing-dcell-actor-based.htmlAll of them are a bit too low level for sharingand consuming business events

I would love a library forpublishing business eventsbuilt on top

Dependency Stack Business Events Collection Commerce::OrderPlaced SharedEvent::Base AMQP-ruby Library AMQP::connect RabbitMQ Middleware

Future Library

Future Library Hides complexities of queues and exchanges

Future Library Hides complexities of queues and exchanges Consumers declare interest in events they care about, deﬁne persistence and retry policy

Future Library Hides complexities of queues and exchanges Consumers declare interest in events they care about, deﬁne persistence and retry policy Publishers ﬁre! events and forget about it

Future Library, ctd.

Future Library, ctd. Once registered, consumers get messages even after being ofﬂine

Future Library, ctd. Once registered, consumers get messages even after being ofﬂine When publisher can submit an event to the queue, it’s job is done.

Future Library, ctd. Once registered, consumers get messages even after being ofﬂine When publisher can submit an event to the queue, it’s job is done. Library of business events becomes a compliment to the set of business APIs

Untangle Communications catalog app checkout app 4. consume InventoryChanged 1. publish OrderPlaced Messaging Bus 3. publish InventoryChanged 4. consume InventoryChanged 2. consume OrderPlacedanalytics and ﬁnancial ERP inventory management reporting system

I don’t think this libraryexists yet, but I wouldlike to write one soon =)

Distributed Ruby Reading

Thank you.

Thank you.twitter: @kiggithub/kigster

http://tektastic.com	1112
http://www.linkedin.com	10
http://blaze.apphb.com	6
http://webcache.googleusercontent.com	4
http://feeds.feedburner.com	3
https://si0.twimg.com	3
http://seekr-artemis.heroku.com	2
https://twitter.com	2
http://pinterest.com	2
http://tweetedtimes.com	2
http://www.brijj.com	1
http://translate.googleusercontent.com	1
http://www.hanrss.com	1
http://2136289839485858746_4bd4af292022dce3fd13239d70d3e6c0afba4e1f.blogspot.com	1

Enterprise Architectures with Ruby (and Rails)

by Konstantin Gredeskoul on Jun 08, 2012

Accessibility

Categories

Upload Details

Usage Rights

14 Embeds 1,150

Statistics

Enterprise Architectures with Ruby (and Rails) Presentation Transcript