This document discusses microservice design for a public health data system. It proposes breaking up the monolithic system into independent microservices for different domains like data collection, processing, and export. This would make the system more flexible, fault-tolerant, and scalable. For example, if a province changes its data format, only the relevant microservice needs to be updated instead of the whole system. The document also cautions that microservice architectures require robust orchestration tools like Kubernetes and DevOps practices to manage deployment, monitoring, and maintenance at scale.

1. From Project To Product Transformation
Microservice Design
Canada DevOps Community of Practice Meetup (16 April 2020 )

3. This was last week’s
Covid-19 report.
Let's start from here

4. The data is published
by PHAC - Public
Health Agency of
Canada.
Now suppose you are
the technical architect
of PHAC.

5. Data flow diagrams in the following slides are for
illustration purposes only.
This simulation is used to clarify the Microservices.​
Anyone working in Public Health and willing to comment the data flow is welcome to contact m

6. PHAC
WHO
B.C
(PPHIS)
Ontario
(iPHIS)
... …
Ottawa
(OPH)
10 Provinces
3 Territories
Hospitals
Laboratory
34 Public Health Units
… …
WHO
Canadian
Government
Websites
3rd Party
Websites
OPH: Ottawa Public Health​
iPHIS: Integrated Public Health Information System​
PPHIS: Provincial Public Health Information System​
PHAC: Public Health Agency of Canada​
WHO: World Health Organization​
Api
DB
CSV
CSV
Api
HTML, PDF
Different security policies
IOT Devices

7. PHAC
Features
1. Data collection
1. From 10 Provinces & 3 Territories
2. Support API, DB, CSV, etc. f
2. Data clean and correction
3. Data Aggregation
4. Data Loading
5. Data Export
1. Support for API, PDF, HTML, CSV etc.

8. Monolithic
Design
Microservice
Design
1 Package
1. Data collection (Support API, DB, CSV,
etc. from 10 Provinces & 3 Territories)
2. Data clean and correction
3. Data Aggregation
4. Data Loading
5. Data Export (API, PDF, HTML, CSV)
Server 3Server 2Server 1
Deploy 1 package to multiple servers
Deploy 19+ packages with 19*2 instances to Cloud
Domain 1:
Data Collection
Ontario
Data Collection MS
… …
10 + 3
B.C
Data Collection MS
Domain 2:
Data Process
Cleansing
and Correction MS​
Aggregation MS
Loading MS
Domain 3:
Data Export
API Export MS
PDF Export MS
CSV Export MS

9. Microservice
Design
Monolithic
Design
1. A province changes its data format
2. PHAC adds a new index
e.g. Asymptomatic infection
3. The PDF requests from 3rd Party cause the
service to slow down
1. Change the “XX Province MS”, test and deploy
2. Modify “Aggregation MS”, test and Deploy
(Keep the legacy version in the production
environment, so that 3-parties have the
window to update their platform)
3. Deploy more “PDF export MS”
1. Modify the package, test EVERYTHING and deploy
2. Modify the package, test EVERYTHING and deploy the legacy
version in new servers (VMs), notify all 3-parties, update the API to
new address before adding new index to their platform
3. More servers(VMs), deploy more packages

10. When change happens:
 MS has more flexibility to tune each part
of the system

12. • Monolithic:
• One system with everything.
when loading, load everything
when unloading, unload everything
• Fragile:
• If one instrument is broken, the whole system
will fail
• Scalable
• Can this musician hold 2x the instruments?

13. Microservice = Orchestra
The Stage -> Cloud or
Kubernetes Container
“Violin”
Microservice
Deployed in 16
Docker instance
“Cello” Microservice
Deployed in 8
Docker instances
Conductor -> DevOps
Melody -> DevOps
Principle and Tools

14. Problems of Microservice: Orchestration, as:
• 3 instances of 1 package vs 38 instances of 19+ packages;
By 2017, Netflix architecture consisted of over 700 loosely coupled microservices and it
continues to grow
• Functional calling in one platform vs API calling in multiple platforms which cause
performance and security issues
Keep away from Microservice without implementing DevOps! The following cannot be done
manually:
• Deployment (load and unload MS without shutting down the service)
• Monitoring to identify and restart unhealthy instances

16. From Project To Product Transformation
Thank You
Steve Zheng (steve.zheng@gmail.com)