Presentation from our talk at Oracle Code Sydney covering Microservices, containers and DevOps.

1. Make your Microservices sing!
The important role of Containers and DevOps

2. About the Authors
Arun is an architect and subject matter expert with a
decade of experience helping commercial,
government, military, and not for profit customers in
a number of complex BPM, SOA and PaaS projects. A
recognized though leader and a loudmouth on
DevOps and PaaS.
@arrunpareek
beatechnologies.wordpress.com
linkedin.com/in/arunpareek
Craig Barr is a Software Engineer with a decade of
experience empowering Enterprises in Banking,
Logistics, Manufacturing and in the three levels of
Australian Government with Service-Oriented
Architecture, Microservices and Cloud Computing.
Arun PareekCraig Barr
@craigbarrau
blog.rubiconred.com/author/craig-barr
blog.rubiconred.com/author/arun-pareek
github.com/craigbarrau

3. What to expect from this session
• Introduce MedRec use case and example monolith
• Containerise our monolith in place
• Create a CI/CD pipeline for our monolith as a foundation for the
future move to Microservices
• Introduce API-first microservices for Physicians and Patients to move
away from our monolithic architecture
• A look at Container Orchestration
• Health wearables demo

4. Microservices. DevOps. Containers.
Problems of yesteryear... Addressed in part by… Leading to…
Long Cycles between
Releases
Domain Driven Design
Small Autonomous Teams
Infrastructure Automation
Complex and Manual
Delivery
Microservices
ContainersSystems at Scale
Large upfront planning and
analysis
Monoliths
DevOps
Continuous Delivery
On-Demand Virtualization

5. The “Monolithic” MedRec Solution
MedRec (Patient/Admin) Application Shared Physician Application
Security
WLDiagnosticFramework
XML
Beans
JSTL
Java Server Pages
Structs
Spring Web
Spring Beans
Web Services
MedRec
Spring Reporting
JSTL
Java Server Pages
Structs
Spring Web
Web
Services
Spring / WLS Java Transaction
Message-
Driven
Enterprise
Java Beans
Java
Management
Extensions
Spring Beans
Spring Reporting
Spring JBDC
Spring
Messaging
Spring
Java
Mail
MySQL

6. Pain points for our
MedRec organisation
 Operations and developers use inconsistent processes
 Releases are often delayed just to late integration issues
 Releases are a “big ceremony” where everyone has to come together
 Refactoring is painful and thus avoided
 Ramping up new team members is challenging
 A failure in one part of the system leads to degradation of everything
 Use of cloud without re-architecture leads to higher operational costs

7. The Twelve-Factor Application
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes 12factor.net

8. i. Codebase
“One codebase
tracked in
revision control,
many deploys”

9. Violation of the “One Codebase Principal”
SQL
Deploy
Scripts
Manual
Steps
?
?

10. Liquibase for Database Changes
Database
Version Control
System
Application
Liquibase
Change Sets Java EAR
Build
process
Application
Startup

11. Introducing Liquibase into MedRec
<!– Spring Context-->
<bean id="com.oracle.medrec.liquibase" class="liquibase.integration.spring.SpringLiquibase">
<property name="dataSource" ref="com.oracle.medrec.datasource" />
<property name="changeLog" value="classpath:medrec-changelog.xml" />
</bean>
<databaseChangeLog>
<include file="liquibase/initial-ddl.xml" />
<include file="liquibase/MEDREC-1298.xml" />
<include file="liquibase/MEDREC-1344.xml" />
<include file="liquibase/MEDREC-1432.xml" />
<include file="liquibase/MEDREC-1432.xml" />
</databaseChangeLog>
<databaseChangeLog>
<changeSet author=”craig.barr" id="medrec-ddl-1">
<createTable tableName="physicians">
<column autoIncrement="true" name="id" type="BIGINT">
<constraints primaryKey="true"/>
</column> <column name="version" type="INT"/>
<column name="username" type="VARCHAR(255)"/>
<column name="firstName" type="VARCHAR(255)"/>
<column name="lastName" type="VARCHAR(255)"/>
…

12. ii. Dependencies
“Explicitly declare and isolate
dependencies”

13. Violation of the “Explicit Dependencies”
MedRec Application
Operating System Packages
Implicit WebLogic Application Server
Custom Classpath

14. Packaging System Container Build System
Maven Dockerfile
FROM container-registry.oracle.com/middleware/weblogic:12.2.1.2
# Operating System packages
RUN yum update && yum install -y graphviz
# Custom classpath
COPY custom.jar $DOMAIN_HOME/lib
# MedRec deployables
COPY medrec.ear physician.ear $DOMAIN_HOME/autodeploy/
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>4.1.6.RELEASE</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>wlserver</groupId>
<artifactId>wlfullclient</artifactId>
<version>10.3</version>
<scope>provided</scope>
</dependency>
…

15. MedRec Container
MedRec Application
Operating System Packages
WebLogic Application Server
Custom Classpath

16. 
Build +
Unit Test
Integration
Test
Acceptance
Test
Release
Candidate
Triggered on
every code change
    

    

Deploy
Staging
Deploy
Production
Load balancer
Switchover
2311f9
e3dd780
5f517c
Let’s create a Delivery Pipeline for MedRec…

17. box: maven
dev:
steps:
- internal/watch:
code: mvn clean install
reload: true
# Build definition
build:
# The steps that will be executed on build
steps:
- script:
name: build
code: mvn clean package
- script:
name: test
code: mvn clean test
push:
steps:
- internal/docker-push:
username: $DOCKERHUB_USERNAME
password: $DOCKERHUB_PASSWORD
repository: craigbarrau/medrec
Wercker for Continuous Delivery
wercker.yml

18. iii. Config
“Strict separation of
config* from code”
*config meaning environment-specific configuration

19. Wercker – Application Environment Variables

20. iv. Backing Services
“Treat backing services as
attached resources”

21. Docker Compose
version: '2'
services:
web:
image: craigbarrau/medrec-monolith:1.0
depends_on:
- db
ports:
- 7001:7001
db:
image: mysql:5.7.17
environment:
- MYSQL_DATABASE=medrec
- MYSQL_USER=medrec
expose:
- 3306

22. Recap: Containerising our Monolith
1. Put everything in Version Control including MedRec
database changes
2. Used Liquibase so the application can manage any
required data changes on boot
3. Put our MedRec monolith into a Docker image without
any changes to the architecture
4. Automated our build, test and deploy processes and
pushed our container to a Docker Registry
5. Laid the foundation for Continuous Delivery

23. • Increasingly difficult to ship features to the Physicians without
having to disrupt the Patients user base and vice versa
• The teams are under pressure to increase the value of their
offering through the interoperability of health wearables and the
establishment of Public APIs
• As a move to address challenges the development team will be
split into two Agile teams
• Physician Services
• Patient Care
Revisiting our
MedRec organisation

26. Microservices
• Small services that do one thing well
• Deliver features independently
• Each service owns its own data
"Gather together those things that
change for the same reason, and
separate those things that change
for different reasons." - Robert C.
Martin
Physician Services
NodeJS + MongoDb Patient Care
Java Spring + MySQL

27. Transitioning MedRec
to Microservices
Physicians API
NodeJS + MongoDb
Patient Care API
Java Spring + MySQL
MedRec UI
+ Monolith Legacy
Other Clients
Next Generation
User Experiencet
Future Services?

28. RESTful API Modeling
• GET /physicians to list all Physicians
• POST /physicians to add a new Physician and return their ID.
• GET /physicians/{id} to get a specific Physician record
• PUT /physicians/{id} to update a specific Physician record
• DELETE /physicians/{id} to delete a specific Physician record
• Related resources
• /appointments to manage physician schedules
• /observations to record medical observations
• /drugs to issue to patients as needed
• /prescriptions to write for patients
• GET /patients to list all Patients
• POST /patients to add a new Patients and return their ID.
• GET /patients/{id} to get a specific Patients record
• PUT /patients/{id} to update a specific Patients record
• DELETE /patients/{id} to delete a specific Patients record
Related Resources
• /appointments to manage patient scheduled
• /conditions for recording patient medical conditions

29. Code Generation
• NodeJS
swagger-codegen generate -i swagger.yaml -l
nodejs-server -o physicians
• Java
swagger-codegen generate -i swagger.yaml -l
jaxrs-cxf -o patients
Available languages: [android, aspnet5, aspnetcore, async-scala, bash, cwiki, csharp, cpprest, dart, elixir, flash, python-flask, go, groovy, java,
jaxrs, jaxrs-cxf-client, jaxrs-cxf, jaxrs-resteasy, jaxrs-resteasy-eap, jaxrs-spec, jaxrs-cxf-cdi, inflector, javascript, javascript-closure-angular, jmeter,
nancyfx, nodejs-server, objc, perl, php, python, qt5cpp, ruby, scala, scalatra, finch, silex-PHP, sinatra, rails5, slim, spring, dynamic-html, html,
html2, swagger, swagger-yaml, swift, swift3, tizen, typescript-angular2, typescript-angular, typescript-node, typescript-fetch, akka-scala,
CsharpDotNet2, clojure, haskell, lumen, go-server, erlang-server, undertow, msf4j, ze-ph]

30. Docker Compose
version: '2'
services:
web:
image: craigbarrau/medrec-patients
depends_on:
- db
ports:
- 10011:8080
db:
image: mysql
environment:
- MYSQL_DATABASE=medrec
- MYSQL_USER=medrec
expose:
- 3306
version: '2'
services:
web:
image: craigbarrau/medrec-physicians
depends_on:
- db
ports:
- 10010:10010
db:
image: mongo
expose:
- 27017
Try it out!
$ git clone https://github.com/craigbarrau/medrec-physicians
$ cd medrec-physicians && docker-compose up –d
$ curl http://localhost:10010/physicians
Try it out!
$ git clone https://github.com/craigbarrau/medrec-patients
$ cd medrec-patients && docker-compose up –d
$ curl http://localhost:10011/medrec/patients

31. Continuous Delivery for our Microservices

Build +
Unit Test
Integration
Test
Acceptance
Test
Release
Candidate
Triggered on
every code change
    

    

Deploy
Non-Prod
Deploy
Production
Load balancer
Switchover
2311f9
e3dd780
5f517c

Build +
Unit Test
Integration
Test
Acceptance
Test
Release
Candidate
    

    

Deploy
Non-Prod
Deploy
Production
Load balancer
Switchover
c23c86
a5d8c1
dfA1cA

32. Recap #2: Microservices for MedRec
1. Created a Minimal Viable API for Physicians and
Patients using OpenAPI specification
2. Shared generated API documentation with
stakeholders using Swagger
3. Generated code stubs and coded basic
implementation for
• NodeJS - Physicians
• JAX-RS – Patients
4. Wired our implementations to Backing Services
• MongoDb
• MySQL
5. Automated our build, test and deploy processes
and pushed our containers to Docker Registry

33. Let’s review against 12 factor
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes

34. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
“Strictly separate build and run stages.”
Docker Registry
Code Environment
Packaged +
pushed
Pulled +
run

35. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
“Execute the app as one or more
stateless processes”
“Any data that needs to persist must be
stored in a stateful backing service,
typically a database.”

36. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
Stateless NodeJS Stateless Java Spring
Stateful MongoDB Stateful MySQL
Web Clients

37. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
“Export services via
port binding”

38. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
Option 1: HTTP export by Application
var port = process.env.PORT || 10010;
app.listen(port);
FROM tomcat:8.0
COPY context.xml $CATALINA_HOME/conf/context.xml
# Add MedRec WAR
ADD target/medrec-*.war $CATALINA_HOME/webapps/medrec.war
EXPOSE 8080
Option 2: HTTP export by Docker

39. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes

40. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
“Maximize robustness
with fast startup and
graceful shutdown”

41. Container Orchestration
• Horizonal scaling
• Service discovery and load balancing
• Automated Rollouts and Rollback
• Secret and Configuration Management
• Self-healing

42. Kubernetes
Kubernetes Concepts
• Pods
• Labels and Selectors
• Controllers
• Service
High level abstractions to
support robust deployments
for example:
• Blue / Green
• Rolling Updates

43. What about a
Managed Container Cloud Service?

44. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
Quick to scale up
Seconds per container
Resilient to failure
Killed processes restarted
Graceful to shutdown
Seconds per container

45. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
“Keep development,
staging, and production as
similar as possible”

46. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
“Treat logs as event
streams”

47. MedRec Twelve-Factor Assessment
i. Codebase
ii. Dependencies
iii. Config
iv. Backing Services
v. Build, release, run
vi. Processes
vii. Port binding
viii. Concurrency
ix. Disposability
x. Dev/prod parity
xi. Logs
xii. Admin processes
“Run admin/management
tasks as one-off
processes”

48. What we have shown
• Introduce MedRec use case and example monolith
• Containerise our monolith in place
• Create a CI/CD pipeline for our monolith as a foundation for the
future move to Microservices
• Introduce API-first microservices for Physicians and Patients to move
away from our monolithic architecture
• A look at Container Orchestration
• Health wearables demo

49. Leading Innovation through Microservices
Remote Patient Monitoring System
levering Oracle Cloud and MedRec
APIs:
1. Remotely manage a person’s health
and well being (e.g. blood pressure
and oxygen level)
2. Integrate devices and raise an alert
on an anomalous reading
3. Connect patients with pharmacists
and medical practitioners
4. Prescriptions and appointments
management.
Role Background/Job Function Important Needs
Patient
(Bruce Wayne)
Works under stressful circumstances
Has a family history of heart related
disorders
Suffers from Hypertension
(High Blood Pressure)
Wishes to be proactive consulted
and advised from his health
practitioner and pharmacist when
there is a problem.
Pharmacist
(Jenny
Andrews)
Prepares and controls medications by
monitoring blood pressure and advising
interventions
Automatically detects and manages
information when any of her
community patients have a critical
blood pressure reading and
proactive action.
Physician
(Lisa Brown)
Diagnosis, monitoring and treatment of
patients
Analyses patients well being records
over a period of time so that she can
detect patterns, anomalies and
exceptions.
Health
Departments
General Well being of the demography.
Provide and Plan emergency medical aid
to people who have a sudden stroke or
heart attack.
Analytics and correlation of blood
pressure to geographic region,
weather conditions ortime of year

50. MedRec Microservices (APICS)
Container
Node.js + MongoDB
Container
SpringBean+ MySQL
Container
Java + Hibernate
Remote
Patient
BLOOD PRESSURE MEASUREMENT
Container
Node.js
Observations
Alerts
Engage a Physician
IOT CS
REALTIME
EXPLORATIONiHealthDevice
IOT CS
proximityBeacons
WellBeingStream
ProximityStream
Remove Duplicate
Reading
Detect Missing
Reading
AnomalyAlert ProximityBreachAlertCriticalHealthAlert
IOT CS
Real Time Stream
PCS
Remote Patient Health Monitoring using Microservices, Containers and Oracle PaaS

51. Live Demo

52. Closing remarks
• You can put a monolithic application in a container
• …but make sure the benefit outweighs the effort
• Pick you container use cases sensibly. Microservices is a good use case.
• There is no place for Microservices without Continuous Delivery
• Agile teams + API-driven microservices. Winning formula!
DevOps or

53. https://rubiconred.github.io/oracle-code
• The presentation
• The code
• MedRec Monolithic Application:
WebLogic application on Docker
• Physicians Microservice: Simple
NodeJS API on Docker
• Patients Microservice: Simple Java
API example with Liquibase on
Docker

54. Thank you!