Microservices are independent, encapsulated entities that produce meaningful results and business functionality in tentative collaboration. Microservices need a platform to run on and to provide generic capabilities such as data caching, an event bus, access to RDBMS and File System. This platform should handle scaling and fail over of the microservices. The Application Container Cloud runs and automatically scales applications built in various technologies such as Node, Java, PHP and Python, it provides caching and access to an event bus and database in the cloud. This session demonstrates how multiple microservices are deployed to and run on ACC, using these capabilities.

1. THE ORACLE APPLICATION
CONTAINER CLOUD
AS THE MICROSERVICES
PLATFORM
Lucas Jellema (Oracle ACE Director & Developer Champion)
APACOUC 2017 Webinar Tour – The Netherlands  APAC

2. AGENDA
• The objective of using microservices and a working definition
• Realization of microservices and requirements of microservices platform
• Introduction of Oracle Application Container Cloud Service
• Demonstration of running an application on ACCS
• Where the rubber meets the road: ACCS for microservices
• DevOps with ACCS
• Provision & deploy, scale & unscale, monitor, upgrade and more
• Demonstration with multiple microservices & multiple instances on ACCS as
the microservices runtime platform

3. MICROSERVICE OBJECTIVES
(BECAUSE OF ENTERPRISE OBJECTIVES)
• Flexible, agile (Dev)
• Functionality evolves rapidly with little effort
• Easy quick rollout
• Low impact
• Manageable Non Functionally (Ops)
• Scalable – handle flexible workload (horizontal scaleout)
• Available – deal with failing nodes
• Comprehendable
• Dependencies, Impact, Implementation, deployment, operations
• Ownership (culture, organization, process)
• One team can do functional and technical evolution and deployment continuously
and independently

4. MICROSERVICES HOW
• Extremely decoupled (from other, non owned microservices | IT
components)
• Functionally
• Non functionally – platform
• Stateless (especially session-state less)
• Stand alone
• Deployable, manageable, scalable
• Container
• DevOps team
• “You build it, you run it, you fix | evolve it”

5. STANDING ON SHOULDERS OF GIANTS
• Monolith++
• API
• Scale out
• Automated CI/CD
• SOA++
• Stateless
• HTTP native (REST)
• Multiple tiers & platform components included
• Deployable

6. MICROSERVICES HOW
• Public APIs in standardized protocols
• Deployable on enterprise standardized microservices platform
• Omnia mea porto mecum - no external dependencies…
• …except:
• Calls to public APIs (exposed for example by microservices)
• Usage of platform facilities
• Generically available via contract
• Injected via parameters
• No sharing of data or other private resources across microservices
• Stateless and Horizontally scalable
• No session state, no client stickyness
• Potentially micro-silo with multiple tiers (including UI)
• Any implementation technology
• that can run on the platform

7. MICROSERVICES PLATFORM
• Receives microservice deployment
• Handles scale out & fail over
• Start/stop microservice instances based on
non functional requirements and live observed behavior
• Supports automated DevOps
• CD, monitoring, …
• Provides Capabilities – generic facilities available to microservices
from the run time platform
• Provided through public APIs whenever possible
• Injected meta-data at run time
• implemented by generic/platform level microservices
Microservices Platform
API
deploy, inject
dependencies, start,
watch, restart, stop,
scale
API API
API Gateway
Authenticate
Logging
Cache

8. SHARED PLATFORM CAPABILITY
• Microservices are isolated
• Not aware of each other (except through public APIs)
• Not sharing private resources
• Ideally each microservice brings its own platform
• To prevent run time environment from being out of synch and creating dependency/impact between multiple
platform users
• However: At some level, sharing is inevitable Storage, Compute, power supply, building
• In practice: having full blown RDBMS or Java EE server or Kafka cluster as part of a microservice
may be unfeasible
• Even if Docker images are light weight from layering – the run time resource usage is probably not
• One approach: forbid use of heavy platforms
• Alternative approach: provide generic ‘heavy duty’ platform capabilities, available for use in any
microservice in a standardized way
• If you need it, you can make use of your own private Oracle Database 12c Schema (or PDB) with the following
features available to you … ; recovery can be performed in the following ways and under these conditions…

9. MICROSERVICES CROSS PLATFORM
CAPABILITIES
• Authentication
• Persistent Storage
• Cache
• Load balancing/API Gateway
• Discovery/Lookup
• Monitoring
• Functional/Business KPIs
• Non Functional Platform/Container & Infra
• Audit, Usage tracking, Billing
• Notifications and alerting
• Logging
• Relational Database Capability
Microservices Platform
API
API
UI
API UI
Logging
Cache
Authentication
Notification
Usage
Tracking

10. EXAMPLE SYSTEM ARCHITECTURE
Microservices Platform
API
API
Logging
Cache
API API
UI
HTML 5
Web
Component
REST/
JSON
Authentication
API UI
Java /
Spring
Boot
NodeJS &
Express &
MongoDB Redis
Widgets
REST/
JSON
Storage
Python &
MySQL
REST/
JSON
WebLogic
& Oracle
Database
Legacy
Application
API UI
Strangler
NodeJS &
Express
Notification
Usage
Tracking

11. EVENTS
Producers
Consumers

12. MICROSERVICES AND EVENTS
• Report business events [without knowing to whom and without expecting a response]
• Allowing interested microservices to respond – for example trigger serverless functions
• Provide response to stateless caller – with conversation key
• Choreograph cross-microservice workflow | process
• Inform workflow | process orchestrator | job scheduler about activity status
• Enable distributed transaction – commit and rollback/compensate
• Make data events available for event sourcing
• Allowing microservices to maintain their own [derived] data set
• Synchronize cache refresh
• Informing any microservice caching data about the need to refresh specific records
• Hand systems events & metrics to monitoring service
• Extreme decoupling – microservice choreography
• Microservice never call each other, not even through public API;
all interactions are through events

13. REQUIREMENTS FOR EVENT CAPABILITY
IN MICROSERVICES PLATFORM
• Provide decoupling between publisher and consumer
• Generally accessible for all microservices
• Across the platform
• Using standardized protocols and formats for communications and event payload (http,
JSON)
• Scalable (handle high loads)
• Available (allow speedy event publication)
• Reliable (do not lose events, at least once delivery)
• Event Ordering (deliver events in the order of publication)
• Retain Event History
• Manageable at scale
• Event Catalog – which events are published, what do they mean and what is
their payload
• Harvested from microservices

14. EXTENDED API OF MICROSERVICE
• Deployment API
• Injectable dependencies – reference to cache, logging, storage URL, …
• Configurable meta-data – run time parameters, log level, credential (key)
• Interaction API
• REST Resources & Operations – query and URL parameters, message
formats
• Events Consumed – alternative way to call | activate a microservice
• Reference to entry in Event Catalog
• May include reference to shared Cache Resource
• Events Produced – alternative output from microservice
• Event can be an asynchronous response to a stateless consumer
API

15. EVENT BRIDGE TO CONNECT CLOUD &
ON PREMISES EVENT BUS
Microservices Platform
API
EventHub CS
On premises
EventBridge
API
API
API
API
API
API
API
API
Event Bus
API
EventBridgeEventBridge

16. ORACLE APPLICATION CONTAINER CLOUD
• Cloud based run time for custom applications
• Either batch programs or HTTP based services
• Supported runtimes:
• Java SE, Node, PHP, Python, Ruby (and more on the way)
Application Container Cloud
Runtime
Container
application

17. ORACLE APPLICATION CONTAINER CLOUD
• Horizontal Scalability: Supports multiple instances
with out of the box load balancing
• Rolling (zero downtime) Upgrades
• Provides multiple channels for [automated] Ops:
• Web UI, REST API, Command Line (PSM tool)
• Configurable through environment parameters passed to application container
• Integrates with Oracle Developer Cloud
• For automated create & redeploy
• Monitoring and Logging Support
• Log files available on Oracle Storage Cloud
• Java Flight Recorder included (for Java SE run time)
• Oracle Management Cloud Agents can be included
Application Container Cloud
Runtime
Container
application

18. DEMONSTRATION OF
ORACLE APPLICATION CONTAINER CLOUD
• Create a simple Node application
• Package it up
• Upload to Application Container Cloud
• Deploy to multiple instances
• Handle http requests to a single URL
from multiple instances
Application Container Cloud
Container
application
application
Zip file
Container
application
http requests
Load
Balancer

35. Application Container Cloud
Container
application
application
Zip file
Container
application
http requests
Load
Balancer

36. MICROSERVICES WITH
APPLICATION CONTAINER CLOUD
Microservices Platform
API
API
Logging
Cache
UI
HTML 5
Web
Component
REST/
JSON
Authentication
API UI
Java /
Spring
Boot
NodeJS &
Express
Widgets
REST/
JSON
Storage
Python
REST/
JSON
Notification
Usage
Tracking &
Billing
API
Java EE
Web
Profile
APIUI
PHP
Event Bus
Relational DB
Storage
Load
Balancing
Service
Discovery
Monitoring
Automated
Deployment

37. MICROSERVICES WITH
APPLICATION CONTAINER CLOUD
Microservices Platform
API
API
Logging
Cache
UI
HTML 5
Web
Component
REST/
JSON
Authentication
API UI
Java /
Spring
Boot
NodeJS &
Express
Widgets
REST/
JSON
Storage
Python
REST/
JSON
Notification
Usage
Tracking &
Billing
API
Java EE
Web
Profile
APIUI
PHP
Event Bus
Relational DB
Storage
Load
Balancing
Service
Discovery
Monitoring
Automated
Deployment
OMC
API CS
DBaaS
MySQL CS
Event Hub
Application
Cache
OMC

38. SERVICE BINDING INTO AN APPLICATION ON
APPLICATION CONTAINER CLOUD
• Capabilities required by “microservice” can be injected at deployment
time by ACCS through Service Bindings
• Service Bindings are [ references | connections ] to Oracle Cloud
Services such as
• MySQL CS, Database Cloud Service, Event Hub, Application Cache
• The actual connection
details (URL, credentials,
connect descriptor) are
made available as
environment variables
Application Container
Cloud
application
DBaaS
MySQL CS
Event Hub

39. EXAMPLE OF SERVICE BINDING:
INJECTING DBAAS INSTANCE
• ACCS Node runtime
already contains
Oracle Node DB Driver
and OCI Client libs
• When the service
binding is configured
then all required
runtime details
regarding DBaaS instance
are available
inside the Node application
Application
Container Cloud
data-api
REST
API
DBaaS
oracledb
DB driver
MyDB
demos
SCOTT

40. DEVOPS & MICROSERVICES DEMO
• Prepare Application Cache
• Manage Node application greeting in Developer Cloud CS
• Source code control, build, deploy
• Extend application to leverage the cache (to share state)
• Deploy Node application to ACCS
• Multiple instance with shared state through cache
• Create second application that also has access to the cache
• Deploy the application to ACCS
• Demonstrate that this new application sees results from greeting

41. DEVOPS & MICROSERVICES DEMO
Developer Cloud
Service
greeting
Application Cache

42. DEVOPS & MICROSERVICES DEMO
Developer Cloud
Service
greeting
Application Cache
Application
Container Cloud:
greeting
greeting greeting
http requests
greetingCache
requestCount
Load
Balancer

92. DEVOPS & MICROSERVICES DEMO
Developer Cloud
Service
greeting
Application
Container Cloud:
greeting
greeting greeting
http requests
Load
Balancer

95. Application
Container Cloud:
greeting
greeting greeting
http requests
Load
Balancer
9 7

96. Application
Container Cloud:
greeting
greeting greeting
http requests
Load
Balancer
9 7
Application Cache
Application
Container Cloud:
greeting
greeting greeting
http requests
greetingCache
requestCount: 16
Load
Balancer

102. Application Cache

103. Application
Container Cloud:
greeting
greeting greeting
http requests
9 7
Application Cache
Application
Container Cloud:
greeting
greeting greeting

109. FAST FORWARD
• Commit sources to Git
• Push to Developer Cloud repo
• Trigger and Perform Build of application greeting
• Trigger Deployment to ACCS
• Application Greeting is redeployed with
• Application Cache reference injected into it
• REST calls to read from and write to Application Cache greetingCache
• Make multiple requests to greeting
• Restart or Redeploy greeting

111. Instance web.1
Instance web.2

112. DEVOPS & MICROSERVICES DEMO
Developer Cloud
Service
greeting
Application Cache
Application
Container Cloud:
greeting
greeting greeting
http requests
greetingCache
requestCount
Load
Balancer

113. DEVOPS & MICROSERVICES NEXT STEPS
Developer Cloud
Service
greeting
Application Cache
Application
Container Cloud:
TrafficMonitor
Application
Container Cloud:
greeting
greeting greeting
trafficmonitor
http requests
http requests
Event HubDBaaS

114. SUMMARY
• Microservices are about rapid rollout of scalable, available functionality
• (session) Stateless, Continuous deployment, horizontal scale out
• One team is owner of a microservice and can evolve and deploy independently
• Microservice is understandable (Devlopable) and manageable (Op[s]erable)
• `Microservices require a runtime platform that
• Can support Ops (deploy, scale, load balance, monitor, upgrade, log …)
• Provides generic capabilities such as Event Bus, Cache, Relational DB, NoSQL
• Application Container Cloud provides runtime plus Ops facilities for
custom applications in various technologies
• ACCS injects platform capabilities through service bindings
• Many of the microservice objectives can be realized with ACCS

115. • https://github.com/lucasjellema/greeting
• Blog: technology.amis.nl
• Email: lucas.jellema@amis.nl
• : lucasjellema
• : lucas-jellema
• : www.amis.nl, info@amis.nl
+31 306016000
Edisonbaan 15,
Nieuwegein