moving from monolithic architecture to spring cloud and microservices

U n l e s s o the rwi s e i nd i cate d, thes e s li d es are © 2 01 3-2 01 6 P ivo tal So f tware , In c . a nd l i cen s ed u nd er a Cr e a t i ve Co mm on s A t t r ib ut i o n-No nCom m erci al l ice ns e : h t tp: / /cr eat i ve com mo ns . or g/ l i cen s es /b y-nc/3 .0 /

Moving from Monolithic Architectureto Spring Cloud and Microservices

By Eddie Escobar, Travis Cherry and Mary Ann WayerPremier, Inc.


Legal Disclaimer

2

Certain statements made in this presentation, including those related to Premier’s financial and business outlook and products and services, are “forward-looking statements.” Forward-looking statements may involve known and unknown risks, uncertainties and other factors that may cause the actual results of Premier to be materially different from historical results or from any future results or projections expressed or implied by such forward-looking statements. Accordingly, one should not place undue reliance on any forward looking statements. Audiences are urged to consider statements in the conditional or future tenses or that include terms such as “believes,” “belief,” “expects,” “estimates,” “intends,” “anticipates” or “plans” to be uncertain and forward-looking. Forward-looking statements may include comments regarding Premier’s beliefs and expectations as to future events and trends affecting its business and are necessarily subject to uncertainties, many of which are outside Premier’s control. More information on potential risks and other factors that could affect Premier’s financial results is included, and updated, from time to time, in Premier’s periodic and current filings with the SEC, as well as those discussed in Premier’s IPO Prospectus filed with the SEC and available on Premier’s website. Forward looking statements speak only as of the date they are made. Premier undertakes no obligation to publicly update or revise any forward-looking statements.


Abstract• Our historical monolithic architectural patterns: building applications for

JBoss with server-side rendering• Our experiences and lessons learned moving to Spring MVC SPA’s• Our decision to move to a microservices-oriented architecture, and how we

leveraged Spring Boot to get there• How we use Netflix OSS / Spring Cloud to handle the new complexities of a

microservices architecture• Using Spring Cloud Config Server to drive application configuration and

a metadata-driven user interface • Securing and automating deployments for a Spring Cloud infrastructure

with Bamboo• Overall lessons learned in our evolution to a Spring Cloud microservice-

oriented architecture

3


About Premier

Premier, Inc. (NASDAQ: PINC) is a healthcare performance improvement alliance of approximately 3,600 U.S. hospitals and 120,000 other providers. Our mission is simple: To improve the health of communities.

We develop SaaS solutions that help healthcare organizations provide higher quality and safer care to patients, lower costs, improve the satisfaction of patients and their families and that stay current with changes in care delivery. We are in a constant state of evolving our solutions and associated technology stack to stay current with modern web app architectural patterns.

4


What Premier Does

• Analyze data on 40% of hospital patients nationwide• Discover and fast-track life-changing solutions, thanks to majority ownership by

U.S. healthcare systems• Improve care/costs for ¾ of U.S. community hospitals• Impact the lives of men, women and children across America• As an industry leader, the Premier alliance has created one of the most

comprehensive databases of actionable data, best practices and cost reduction strategies.

5


Our Architectural Evolution

6

war

warApp

Services

Web UI/Services App

Services

Web UI/Services

2016+Ultrathin ‘E-Skin’ makes

your hand a display

2015Aeromobile 3.0 launchedBraille printer from LEGO

2010iPad released

Google tests self-driving car

2008New Mars Rover

Commercial Bionic Hand


2008 - 2009

• Monolithic Application• Started development with WebWorks• Moved to Struts 2• Used Spring for dependency injection• Standardized on Dojo for the UI• Hibernate used for ORM framework• Scaled using additional web servers

• Dev-Ops hand-built the Linux environment

7

war

2008


Evolutionary Advantages

• Use of an ORM Framework – Hibernate• Allowed us to easily map our Java objects to database tables• Generated SQL for common functionality

• Use of an MVC Framework – Struts• Separation of concerns for JSP view layer, actions for controller layer and

model by our ORM layer• Use of an JavaScript Framework - Dojo• Allowed us to write objected oriented, browser-independent code• Large built-in widget library

8


Quality Measures Reporter™

9


Lessons Learned

• Deployments were manual and required system down time• Scaling the application was entirely manual• Invalid use and lack of Hibernate knowledge led to performance issues• JSP pages lead developers to bypass best practices• Confusing use 2 frameworks for dependency injection and building MVC apps• Lack of Dojo documentation• UI-related changes required deployment of all components

10


Next Evolutionary Goals

• Minimize the number of frameworks• Make UI layer easier to implement• Remove dependency of UI deployments from backend deployments• Create more responsive UIs• Address lack of knowledge around the use of Hibernate• Move towards more of CI/CD environment

11


2010 - 2014

• Slow move to microservices• Moved from Struts 2 to SpringMVC• Built custom application framework using Dojo for building

rich client-side web applications • Split out web UI from REST services• Setup Hibernate best practices• Introduce Jenkins for CI/CD

12

war

2010



• UI is not constrained by any backend server technology.• HTML, CSS, JSON

• Greater UI development productivity• UI development could proceed with mock data

• Applications were more responsive to the user• No need for full page refreshes

• UI and REST services could be deployed and scaled independently of each other

• Deployments required less Dev/Ops involvement• Most deployments were just one button press away

13


PhysicianFocus™

14


Lessons Learned

• Initial ramp-up time increased while learning JavaScript and client-side MVC• Browsers issues

• Legacy browser support and cross-browser inconsistencies• Programming with AJAX

• Dealing with partial results• Order of requests

• Cross-Domain issues• The importance of minification

• Too many requests• Slow page loads

15



• Make UI layer even easier to implement and more metadata driven• Streamline environment-specific configuration• Make it easier to implement enterprise logging for PHI• Make apps “container-izable” to enable scaling• Eliminate dependency on JBoss AS• Requirement for 24/7 availability • Reduce remaining monolithic codebases into microservices• General move towards building 12 Factor apps

16


• Codebase – one codebase tracked in revision control, many deploys

• Dependencies – explicitly declare and isolate dependencies

• Config – store config in the environment

• Backing services – treat backing services as attached resources

• Build, release, run – strictly separate build and run stages

• Processes – execute the app as one or more stateless processes

• Port binding – export services via port binding

• Concurrency scale out via the process model

• Disposability - maximize robustness with fast startup and graceful shutdown

• Dev/prod parity - keep development, staging, and production as similar as possible

• Logs - treat logs as event streams• Admin processes - run

admin/management tasks as one-off processes

http://12factor.net

12 Factor Apps

17


2015 – Early 2016• More than halfway to a Twelve Factor App:

• Codebases• GIT

• Dependencies• Maven

• Config• Spring Cloud Config Server

• Build, Release, Run• Transitioned to Bamboo• Canary files for Blue/Green deployments

• Improved Dev/Ops processes• Dev/Prod parity• Metadata-driven UI framework• Enterprise logging

18

2015

AppServices

Web UI/Services



• Standardization of best practices across teams• Overall architecture, frameworks/versions, enterprise logging, etc.

• Container-ready (infrastructure and process)• Externalized configuration with live updates• Zero-downtime deployments

• Standardized, automated deployments lead to dev-team enablement• Insanely fast UI development

• Minimal to no custom UI codebase to maintain per project• Development teams shift focus to data and API layers• Enterprise UX drives UI and component evolution• Consistent UI enables seamless integrations across apps

19


Provider Performance™

20


Our Current Spring Cloud Application Architecture

21

VM 2

VM 1

GitRepo

Spring Cloud Config Server

:8888

AppDB Provisioning

Microservice:9002

Dashboard Web App:8443

Common UI Widgets

Common UI Services

Firewall

F5

AdminMicroservice

:9001

UI Microservice

:9000


Disclaimer:We’re only half-way there…

22


Spring Cloud: Current Challenges

• Configuration is GIT-based; hosted in our internal Stash repo• Limited security policies in place for access control: all team members can push• Needed separate private repo owned by Dev/Ops• Establish process for pushing changes to the prod master branch• Sensitive values (e.g. db passwords) need to be encrypted at rest

• Config server needs to be secured!• All traffic with consumers must be encrypted• Consumers must authenticate using basic auth or ssh

• All Spring Boot Actuator endpoints are enabled by default except shutdown• Automating Spring Boot app deployments

23


Suggestions for Securing Spring Boot Apps

• To enable basic HTTP auth, add spring-boot-starter-security as a dependency• Be sure to update and encrypt default password (security.user.password)

• Disable built-in Actuator endpoints and only enable what you need:• endpoints.enabled=false • endpoints.info.enabled=true• endpoints.sensitive=true

• Enable security for the management endpoints• management.security.enabled=true

• Configure SSL for your app and for management (different key stores for each)• Actuator and management endpoints should only be available internally (behind

your Firewall); specify a different context path than your app

24


Additional Steps for Securing Config Server

• For encryption/decryption, install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle in your JVM

• Generate keystore for Spring Config Server • Specify keystore location, password (encrypted) and basic auth credentials • Use ssh public key for connecting GIT server

25


Encrypting Sensitive Configuration Values

• Dev/Ops encrypts the sensitive values using Config Server’s /encrypt and /decrypt endpoints (uses keystore to handle encryption/decryption)

• The call will return an encrypted string that will be given to the development team, i.e AQAkO1QG6a…Kux6CwwDuZ

• The development team will add the encrypted string to their project's property file, prefixing with {cipher} (stored in the GIT repo)

• These values are decrypted prior to being sent to authorized clients via HTTP

26

spring:profiles: proddatasource:

password: '{cipher}PMYesefklnrfqzTS+Xo…KReI&HEubi8887UDf7kH9nq’


More on Security…

• Disclaimer: these are only suggestions to get you started; this is not a comprehensive guide!

• For more information, see:• Spring Boot Security: http://docs.spring.io/spring-boot/docs/current-

SNAPSHOT/reference/htmlsingle/#boot-features-security• Config Server Security: http://cloud.spring.io/spring-cloud-config/spring-

cloud-config.html#_security

27


Deploying Spring Boot Apps with Bamboo

• Puppet can be used to deploy and configure Java with the JCE via Bamboo• The deployment task will have the following Bamboo variables that will be

environment specific (i.e non-prod vs prod):• deploy.keyStore.location = the location of the keystore file on the server

• deploy.keyStore.password = the password used to unlock the keystore• deploy.basicAuth.password = the password used for basic authentication

• To use Bamboo to deploy and start any Spring Boot App (e.g. Config Server):• Bamboo will transfer the executable JAR and start it, specifying the necessary profile

and other environment variables• When starting the app, a shell script can be used in Bamboo to retain the pid so it can

be retrieved and used to terminate the process prior to subsequent deployments

28


Config Server Meets UI

• Metadata-driven UI is a perfect match with Config Server• Config server can host metadata

• @Value & @RefreshScope can be used for property values and reloading• Support for JSON files (in addition to .yml & .properties)• Config Server exposes REST API for consuming config

• Minimal code; predominantly annotations• @Configuration, @SpringBootApplication and @EnableConfigServer

29


Metadata-Driven UI on Config Server

• We established a JSON metadata structure to represent an entire UI and its widgets, data sets, views and interactions

• Developed client-side MVC application framework and corresponding Spring/Java services to integrate the metadata-driven UI into a Spring Boot app

• Client Spring Boot web apps are skeletons that inherit common dependencies to retrieve, parse and render metadata-driven UI

• Created WYSIWYG editor for metadata management/generation• Externalized UI metadata on Spring Cloud Config Server • Updates to the metadata are pushed to the GIT repo and the refresh endpoint

updates all running versions without the need for a restart

30


Demo

31


Lessons Learned• Config Server

• Private/access controlled GIT repo• General security challenges• Data source configuration and encrypted credentials • Dev/Ops involvement and process changes

• Spring Boot• Environment challenges: startup and process monitoring• No JBoss infrastructure

• Data source management• Port binding

• Spring “Magic”• Gotchas: App didn’t connect to config server due to a missing dependency

• Switch to Java-based configuration (no more XML files!)• First use of Spring Profiles

32



• All Twelve Factors achieved: • Backing Services & Port Binding

• Eureka Service Registry

• Concurrency/elasticity• Less idle hardware!

• Deploy each Spring Boot app to its own space• Disposability• Admin/Process

• Built-in logging/metrics• Circuit Breaker• Hystrix Dashboard

33

2016+

AppServices

Web UI/Services


Our Future Spring Cloud Application Architecture*

34

GitRepo

AppDB

UI Microservice

AdminMicroservice

Provisioning Microservice

Firewall

F5

ConfigServer

EurekaService Registry

Zuul Router/Proxy

HystrixCircuit Breaker

Dashboard Web App

Common UI Services

Common UI Widgets

Monitoring

*This represents a “forward-looking statement”; please refer to the “Legal Disclaimer” from Slide 2 of this presentation.


Remaining Challenges

• Dev-Ops cultural changes • Process changes

• Infrastructure/system admin cultural changes• Moving to the Cloud

• Budget cycles and business priorities• Competing technology “factions”

• CF vs Docker/Kubernetes

35


Questions?

36


Learn More. Stay Connected.

No Outage Database Development with Spring Boot and LiquibaseAlan Barrington-Hughes and Pavithra Ramaswamy, Premier, Inc.

@springcentralspring.io/blog

@pivotalpivotal.io/blog

@pivotalcfhttp://engineering.pivotal.io


References

• Spring: https://spring.io/• Spring Cloud: https://cloud.spring.io• Pivotal: https://pivotal.io/• Cloud Foundry: https://www.cloudfoundry.org/• 12 Factor Apps: http://12factor.net

38


Logo/Icon References

• VMware: https://www.vmware.com• JBoss: https://jboss.org• Dojo Toolkit: https://dojofoundation.org• Hibernate: https://hibernate.org• Struts: https://struts.apache.org• Spring: https://spring.io• Spring Boot & Spring Cloud: https://pivotal.io• Spring Cloud Services, Config Server, Service Registry, Circuit Breaker and

Rabbit MQ for PCF: https://network.pivotal.io• Cloud Foundry: https://www.cloudfoundry.org• Other icons provided in Pivotal Spring One Speaker Materials:

https://springoneplatform.io/speaker-guidelines/breakout

39

moving from monolithic architecture to spring cloud and microservices

Technology