Downloaded 18 times
Uploaded byTony Erwin
Evolution of the IBM Cloud Console: From Monolith to Microservices and Beyond
The document outlines the evolution of the IBM Cloud Console from a monolithic architecture launched in 2014 to a microservices-based architecture implemented between 2015 and 2018. This transition aimed to enhance performance, developer productivity, and scalability while addressing challenges like complexity and monitoring. The migration to microservices allowed for improved features, such as geo load balancing and Kubernetes for better resource management and availability.
More Related Content
![[WSO2Con EU 2017] Container-native Architecture](https://cdn.slidesharecdn.com/ss_thumbnails/containernativearchitecturelakmaledited-171107085744-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Webinar] AWS Monitoring with Site24x7](https://cdn.slidesharecdn.com/ss_thumbnails/site24x7-awsmonitoringwithsite24x704thnov2015-151105060402-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
![[WSO2Con EU 2017] WSO2 Unleashed: Full Stack Automation, Pitfalls and Solutions](https://cdn.slidesharecdn.com/ss_thumbnails/fiot-final-171107115910-thumbnail.jpg?width=640&height=640&fit=bounds)
![[WSO2Con EU 2017] How a Large Organization Weighted on a WSO2 Integration Pla...](https://cdn.slidesharecdn.com/ss_thumbnails/enioka-haute-couture-final-171107154834-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Evolution of the IBM Cloud Console: From Monolith to Microservices and Beyond
![[WSO2Con Asia 2018] Architecting for Container-native Environments](https://cdn.slidesharecdn.com/ss_thumbnails/v2-wso2con2018-architectingforcontainernativeenvironments-180810085834-thumbnail.jpg?width=640&height=640&fit=bounds)
Evolution of the IBM Cloud Console: From Monolith to Microservices and Beyond
- 1. Evolution of theIBM Cloud Console: From Monolith to Microservices and Beyond Tony Erwin Senior Technical Staff Member Lead Architect, IBM Cloud Console [email protected]
- 2. Agenda • IBM CloudConsole & 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 theIBM 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: Originsas 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 theMonolith • 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.
- 8. Solution: New MicroserviceArchitecture • 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 MicroservicePattern • 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 withMicroservices header inline combined Common Microservice
- 12. Architecture for SupportingPlugins • 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 toSolve
- 14. New Problems toSolve • 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 ofthe Architecture to Achieve Higher Availability
- 17. Geo Load Balancingand 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 BalancingImpact 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: Movingto 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.
- 21. Conclusion • Original monolithicapp 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:[email protected] Twitter: @tonyerwin