These slides were originally presented as part of a workshop on microservices at CASCON in Markham, ON on Oct. 29, 2018.

1. Evolution of the IBM Cloud Console:
From Monolith to Microservices and Beyond
Tony Erwin
Senior Technical Staff Member
Lead Architect, IBM Cloud Console
aerwin@us.ibm.com

2. Agenda
• IBM Cloud Console & Early Days as a Monolith
• Modernization with Microservices
• New Problems Created by Microservices
• Continued Evolution of the Architecture to Achieve Higher Availability

3. IBM Cloud Console & Early Days as a Monolith

4. What is the IBM Cloud Console?
• Large UI serving as front-end to the IBM
Cloud
• Lets users create, view, and manage
PaaS/IaaS resources
• Kubernetes clusters
• Virtual servers
• Bare metal
• Cloud Foundry apps & services
• Provides additional functionality for:
• Registration/onboarding
• Identity and Access Management (IAM)
• Billing/usage
• Docs
• Serves as the front-end to IBM Cloud

5. Console History: Origins as Monolith
• Released in 2014
as monolithic
single-page app
(SPA)
• All HTML, CSS, and
JavaScript loaded
within single web
page
• Served from a
single Java app
(which also
provided APIs)
• Totally centered
around Cloud
Foundry
Home Catalog … Dashboard
Resource
Details
Account
Backend APIs
(CF, MCCP, BSS, UAA, etc.)
DB/2
Cloud Console UI Server
(Java)
Cloud Console UI (Client)
Cloud Foundry

6. Problems with the Monolith
• Bad performance
• Heavy weight JavaScript loaded to browser was slow (used Dojo framework)
• Volume of client-initiated AJAX requests created bottlenecks
• Difficult to integrate code from other teams
• Have to push whole product even for small changes
• Poor Search Engine Optimization (SEO)
• New hires wanted nothing to do with Dojo

7. Modernization with Microservices

8. Solution: New Microservice Architecture
• Allows paced 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 microservices can deploy at their own schedule
• Teams use stack of their choosing
• Teams don’t have to wait on others
• Improves cross-team UI consistency via microservice composition
• Leads to improved SEO
• Proxy facilitates “clean” URLs
• Server side generation results in crawlable content

9. Today’s Microservice Architecture
• Starting in 2015,
steadily
refactored to new
architecture over
next ~2 years
• Introduced proxy
to route requests
based on URL
path
• Core pipleline
now deploys 40+
microservices
• Expanded
beyond Cloud
Foundry
beginnings to
include other
PaaS and IaaS
offerings
Home Catalog …
Resource
Details
Dashboard
Watson and Cloud Platform APIs
(CF, Containers, BSS, RC, RG, IAM, GhoST, Hyperwarp, etc.)
Kubernetes
Proxy
Common
Monitoring
Framework
Console (Client)
Java API
Server
Redis
Cloudant

10. Typical UI Microservice Pattern
• Written with Node.js
• Serves lightweight HTML, CSS, JS
based on Carbon Design System
• When framework needed, React is the most
common choice
• Uses server-side templating (Dust.js) to
make as much data available to the
client as possible for fast rendering &
SEO
• Invokes Common Header API to get
HTML for shared header to include in
initial payload
• Consults shared session store (Redis)
for user token, etc.
• Leverages backend APIs and/or API
microservices as appropriate
Node.js (w/
Dust.js)
Cloud Console UI (Client)
Kubernetes
Proxy
Common
Header
• HTML
• CSS
• JavaScript (Vanilla, Polymer.js, React, Angular)
API
Microservice
Watson and Cloud Platform APIs
(CF, Containers, BSS, RC, RG, IAM, GhoST, Hyperwarp, etc.)

11. Page Composition with Microservices
header
inline
combined
Common
Microservice

12. Architecture for Supporting Plugins
• Console team adds proxy
rules that pass requests
through to plugin endpoints
• 30+ teams outside core
console contribute plugins
Home Catalog … Dashboard
Resource
Details
Console UI (Client)
Proxy
Common
Monitoring
Framework
Kubernetes
Watson DevOps
Functions Containers
Mobile Etc.
Watson and Cloud Platform APIs
(CF, Containers, BSS, RC, RG, IAM, GhoST, Hyperwarp, etc.)

13. New Problems to Solve

14. New Problems to Solve
• 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 (before move to
Kube)
• 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

15. 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

16. Continued Evolution of the Architecture to Achieve Higher Availability

17. Geo Load Balancing and Failover for HA
• One global URL (console.bluemix.net)
went live in Summer 2017
• 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 regions being down at the
same time much less than one region
being down
• Outages, PagerDuty’s, etc. decreased
dramatically after going live

18. Geo Load Balancing Impact to Microservices
• Microservices
should not be tied
to specific region
• E.g., Dallas
microservice ought
to be able to work
with API &
resources in
London

19. Runtime Environment: Moving to Kubernetes
• Originally the console was deployed to several Cloud Foundry public regions
• Migrated to Kubernetes clusters in early 2018, to gain advantages such as:
• More granular control to better manage our large, complex microservice system
• Dedicated clusters to avoid performance/availability problems from friendly fire
• Simpler “front door” stack with built-in Ingress proxy (NGINX) to avoid extra network hops
• Private host names
• All apps in CF have public host names, so not possible to have a “private” microservice
• Private networking
• Calls between microservices in CF require going out over the public internet
• Improved memory and CPU usage (dynamic allocation)
• Ability to run our own services (like Redis)
• Integrated monitoring with Prometheus

20. Wrapping Up

21. Conclusion
• Original monolithic app had many limitations given how we wanted to
grow the console ecosystem
• Nothing is free, and we had to solve several new problems along the
way as we migrated to a microservice architecture
• Allowed us to achieve greater performance, scalability, reliability, and
security than we had before
• Paved the way for continued architectural evolution

22. Any Questions?
Tony Erwin
Email: aerwin@us.ibm.com
Twitter: @tonyerwin