Migrating a Monolithic App to Microservices on Cloud Foundry

Migrating a Monolithic App to Microservices on Cloud Foundry

Brian K. Martin, Bluemix Architect, @bkmartin Tony Erwin, Bluemix UI Architect, @tonyerwin

Agenda

•  Introduction to the Bluemix UI •  Bluemix UI Microservices Architecture •  Features for Cloud Foundry to Support

Microservices

@bkmartin @tonyerwin

Agenda


Microservices


IBM Bluemix

•  IBM Bluemix: –  Open-standards, cloud platform for building,

running, and managing apps –  PaaS layer built on CloudFoundry

•  Bluemix UI is the front-end, providing an alternative to the CF command line

Bluemix UI Home

Solutions (Marketing)

Pricing

Dashboard

Catalog

Orgs/Spaces

Bluemix UI Monolith •  Single-page application (SPA) to provide

desktop-like experience in the browser •  All HTML, CSS, and JavaScript loaded within

single web page and 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 –  SPA still popular (AngularJS, Ember.js etc.)

Monolithic Architecture

Home Solu)ons Catalog Dashboard Pricing Orgs/ Spaces

CF Cloud Controller (and other APIs)

SQL DB Bluemix UI Server

(Java)

Bluemix UI (Client)

Bluemix PaaS

Challenges of Monolith •  How can we improve performance?

–  Volume of client-side requests create bottlenecks •  How do we integrate code from other teams

using different stacks? •  How can we push smaller changes as they are

ready? •  Where do we find developers with Dojo

experience? •  How can we improve SEO?

Agenda


Microservices


Promises of Microservices •  Aids migration to more modern, lighter-weight stack without starting over •  Improves performance and developer productivity

–  Small services optimized for speed and page size •  Use simplest approach that works •  Bare bones HTML, CSS, JS •  Node.js w/ Dust.js server-side templates

–  Easier to find answers on Google, easier to find skilled developers •  Allows more regular updates as 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

Phase 1

Solu)ons

Catalog Dashboard Pricing Orgs/ Spaces


SQLDB

Bluemix UI Server (Monolith)

Bluemix UI (Client)

Bluemix PaaS Proxy

Common

Session Store No SQL Msq

Queue Monitor

Home

Composition w/ Microservices header

footer

inline

combined

Common

Home

End Goal

Home Solu)ons Catalog Dashboard Pricing Orgs/ Spaces


Bluemix UI (Client)

Bluemix PaaS Proxy

Common

Session Store No SQL Msq

Queue Monitor

New Challenges

•  More moving parts, more complexity •  Collecting federated status, monitoring

health of the system •  Seamless navigation with existing monolith •  Developer skills (need to learn new stack,

but will ultimately be more productive) •  Blue-green deployments

An Approach for Blue-Green – Just Change Route on Proxy

Home home-‐XXX.bluemix.net

Solu)ons solu1ons-‐XXX.bluemix.net

Bluemix UI Server classic-‐XXX.bluemix.net

Proxy

Common common-‐XXX.bluemix.net

Home Home-‐YYY.bluemix.net

Solu)ons solu1ons-‐YYY.bluemix.net

Bluemix UI Server classic-‐YYY.bluemix.net

Proxy

Common common-‐YYY.bluemix.net

Router

console.ng.bluemix.net console-YYY.ng.bluemix.net

Agenda


Microservices


Context Path Routing •  bluemix.net/login ->

login.bluemix.net/login •  bluemix.net/account ->

account.bluemix.net/account •  To efficiently share user state and

allow individual microservices to be updated independently, we need a built-in ability to bind context paths to apps and have gorouter routing

Application Versions •  CF has no formal concept of an application

version •  Would it be helpful to add a formal concept

of version so that a given application name can have many versions installed formally

•  Current way –  myapp-1.0 à myapp-1.1

•  The app name may be constantly changing which is harder for mgmt, CMDB, etc

Advanced Routing Policies •  When rolling out new versions of

microservices how can you control which users are routed to the new version?

•  Advanced routing policies could allow policies like random selection of a percentage of the popultion, specific user groups, etc

“Private” Applications

•  An ability to hide microservices applications from public routing

•  Applications to be declared public or private

•  SDN for a space or org •  How to authenticate/grant access for

routing

Composite Applications •  What if you want to understand the health

and status of your complete microservice based application?

•  A composite application could allow applications to be grouped for status and control (the latter seeming less useful)

•  Could simplify blue-green deployment if multiple functions could be selected simultaneously

Service Registry

•  Need a new way to discover the active endpoints for the microservices rather then hard coded paths and/or application names

•  Service registry should have live status to allow fast failover to alternative services

Performance and Monitoring •  When your application is broken into

many components, monitoring the performance and response time of each component becomes even more important to diagnose problems

•  Common dashboards that can aggregate stats from many applications are required

Log Analysis for Problems

•  Common log aggregation platforms (ELK) solve most of the problem but it has been hard to correlate across applications for a given user

•  Solution: use common correlators across your microservices to track individual users

Testing

•  How to insure compatibility of microservices as they are being deployed

•  Integrated to your CI/CD pipeline, but is there anything else that could be done?

IBM Bluemix

Free 30 day trial at http://www.bluemix.net Email: [email protected] Twitter: @bkmartin Email: [email protected] Twitter: @tonyerwin

Software

Migrating a Monolithic App to Microservices on Cloud Foundry