The Bluemix UI (which runs on CloudFoundry) is the front-end to Bluemix, IBM's open cloud hosting platform. The original implementation as a single-page, monolithic Java web app brought with it many demons, such as poor performance, lack of scalability, inability to push small updates, and difficulty for other teams to contribute code. Over the last 2 years, the team has been on a mission to slay these demons by embracing cloud native principles and splitting the monolith into smaller Node.js microservices. The effort to migrate to a more modern and scalable architecture has paid large dividends, but has also left behind a few battle scars from wrestling with the added complexity cloud native can bring. The team had to tackle problems in a wide variety of areas, including: large-scale deployments, continuous integration, monitoring, problem determination, high availability, and security. Tony Erwin will discuss the advantages of microservice architectures, ways that Node.js has increased developer productivity, approaches to phasing microservices into a live product, and real-life lessons learned in the deployment and management of Node.js microservices across multiple CloudFoundry environments. His war stories will prepare you to wage your own battles against monoliths everywhere -- happy slaying! Presented at Cloud Foundry Summit 2017: http://sched.co/AJmh

1. To Kill a Monolith: Slaying the Demons of a Monolith with
Node.js Microservices on CloudFoundry
Tony Erwin, aerwin@us.ibm.com

2. Agenda
• Origins of the Bluemix UI
• Demons of the Monolith
• Slaying Demons with a Microservices Architecture
• New Demons to Slay

3. Bluemix UI – Origins as a Monolith
• Serves as front-end to Bluemix (IBM’s open cloud offering)
• Lets users create, view, and manage CF resources, containers,
virtual servers, user accounts, billing/usage, etc.
• Runs on top of Bluemix PaaS Layer (CloudFoundry)
• Started as single-page application (SPA) to provide desktop-like
experience in the browser
– All HTML, CSS, and JavaScript loaded within single web page
– Served from a single Java app
• State-of-the-art not all that long ago
– Dojo + J2EE was the most common stack in IBM when Bluemix UI dev
started (~4 years ago)
– SPA still popular (AngularJS, Ember.js etc.)

4. Bluemix UI – Many Components
4
Home Dashboard Catalog
Users Billing
And
More!Resource Details

5. Monolithic Architecture
Home Catalog … Dashboard
Resource
Details
Account
Backend APIs (CF, Containers, VMs, Billing, Authentication, etc.)
DB/2
Bluemix UI Server
(Java)
Bluemix UI (Client)
Cloud Foundry

6. Demons of the Monolith
• Bad performance
– Heavy weight JavaScript loaded to browser is slow
– Volume of client-initiated AJAX requests creates
bottlenecks
• Difficult to integrate code from other teams
(especially when they use different stacks)
• Have to push whole product even for small changes
• Poor SEO
• New hires want nothing to do with Dojo

7. Bluemix UI Microservices Architecture

8. Weapons of Microservices
• Aids migration to more modern, lighter-weight stack without starting
over
• Improves performance with small services optimized for speed and
page size
• Increases developer productivity with less chance of breaking other
parts of the product
• Loosely-coupled services can deploy at their own schedule
– Teams use stack of their choosing
– Teams don’t have to wait on others
• Leads to improved SEO
– Proxy facilitates “clean” URLs
– Server side generation results in crawlable content
• Improves cross-team UI consistency via microservice composition

9. Microservice Pattern
UI microservice:
• Written with Node.js
• Serves lightweight HTML, CSS,
JS (simplest approach that works)
• Uses server-side templating
(Dust.js) to make as much data
available to the client as possible
for fast rendering & SEO
• Invokes Common Header
microservice to get HTML for
shared header to include in initial
payload
• Consults shared session store for
user token, etc.
• Leverages backend APIs and/or
API microservices as appropriate
Node.js (w/
Dust.js)
Backend APIs (CF, Containers, VMs, BSS, MCCP, etc.)
Bluemix UI (Client)
Cloud Foundry
Proxy
Common
Header
• HTML
• CSS
• JavaScript (Vanilla, Polymer.js, React, Angular)
API Microservice

10. Page Composition w/ Microservices
header
inline
combined
Common
Microservice

11. Migration, Phase 1
• Delivered Feb 2015
• Introduced proxy layer to route
requests to different services
based on URL path
• Added three microservices
behind the proxy (alongside
Java code)
• Leveraged two additional CF
services:
– Data Cache for shared session
– NoSQL DB for data storage
Solutions
Catalog Dashboard
Resource
Details
Account
Backend APIs (CF, Containers, VMs, BSS, MCCP, etc.)
DB/2
Bluemix UI Server
(Monolith)
Bluemix UI (Client)
Cloud Foundry
Proxy
Common
Header
Session
Store
NoSQL
DB
Home
…

12. Migration, Phase 2
• Delivered
Feb 2016
• 90%+ of
migration
complete
Home Catalog …
Resource
Details
Dashboard
Backend APIs (CF, Containers, VMs, BSS, MCCP, etc.)
Cloud
Foundry Proxy
Common
Monitoring
Framework
Account
Bluemix UI (Client)
Java Server
(Monolith)
Session
Store
NoSQL
DB
DB/2

13. Migration End Goal
• More or less
current state in
production,
except for:
– Java app for
certain APIs still
exists
– Small amount of
legacy Dojo code
Home Catalog … DashboardPricing
Orgs/
Spaces
Backend APIs (CF, Containers, VMs, BSS, MCCP, etc.)
Bluemix UI (Client)
Bluemix
PaaS Proxy
Common
Monitoring
Framework
Session
Store
NoSQL
DB
Cloud Foundry

14. Plugin Architecture
• Roughly 15 teams
outside of the core UI
team plugin via the
proxy to look and
behave like one large
product
Home Catalog … DashboardPricing
Orgs/
Spaces
Backend APIs (CF, Containers, VMs, BSS, MCCP, etc.)
Bluemix UI (Client)
Bluemix
PaaS Proxy
Common
Monitoring
Framework
Cloud Foundry
Watson
Internet of
Things
OpenWhisk Containers
Mobile …

15. New Demons to Slay

16. New Demons to Slay
• More moving parts, more complexity
– Build pipeline becomes all the more important
• Collecting federated status, monitoring health of the system
• Granularity of microservices vs. memory allocation
– Monolith: 3 instances of Java app = 6 GB
– New console: ~27 apps, ~95 instances, ~55.5 GB
• Seamless navigation with existing monolith
• Blue-green deployments
• Promoting uniformity & consistency while still giving teams freedom
• Geo-load balancing and failover
– Taking lessons learned with resiliency in one Cloud Foundry deployment and
applying globally across several

17. Importance of Monitoring
• We quickly learned that you can’t run a microservice-based system without monitoring
– Lots of things can go wrong
– Root cause determination can be difficult
• Examples of needed metrics:
– Data for every inbound/outbound request for every microservice
• Response time
• Response code
– Memory usage, CPU usage, and uptime for every microservice
– General health of ourselves and dependencies
– Synthetic page load data with Sitespeed.io & WebPageTest

18. Global Load Balancing Across CF
• Bluemix UI (with all of its microservices) is available for our 4 public regions:
Dallas, London, Frankfurt, and Sydney
– UI deployed in each region has its own URL (console.<region>.bluemix.net) pointing
at the proxy shown in previous slides
– If a region goes down due to CF issue, networking, etc. any user of that region can’t
access the UI to manage their resources
• If CF down (for example) there are still a lot of non-CF resources the user may want to
manage
• Currently rolling out what we call “global console”
– One global URL (console.bluemix.net)
• UI region switcher filters the current view rather than redirect to different URL
– Use Dyn geo load balancing to serve UI from the nearest healthy region
– If healthcheck in a region shows a problem, Dyn routes to the next closest healthy
region
• Odds of all four regions being down at the same time much less than one region being down –
so, user much less likely to experience down time

19. The End
Questions?
Tony Erwin
Email: aerwin@us.ibm.com
Twitter: @tonyerwin
See also presentation later this week:
Monitoring Node.js Microservices on CloudFoundry with
Open Source Tools and a Shoestring Budget
http://sched.co/AJmn