2
Herzlich willkommen
DevDay Zürich 2016
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Building Cloud Native Applications
Andreas Postl Principal Sales Consultant MiddlewarePaaS Ambassador
June 22th 2016
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Software Is Overtaking the World
Time-to-market is key to success
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Better Segment SoftwareDifferent software has different needs
Find the Next Business
Run the Current Business
Run the Back Office
New IT
Old IT
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Different Types of Software Requires Different PracticesA payroll system should be treated very different from a customer-facing .com
Innovation Software - Find the Next Business
Differentiation Software - Run Current Business
Core Software - Keep the Lights On
Release Hourly
Fail Early
Agile
Business-centric
Top Line Growth
Bespoke Software
Product-based
Release Quarterly
Fail Late
Waterfall
IT-centric
Bottom Line Savings
Packaged Software
Project-based
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Change How Your Customers Procure SoftwareFocus is on bringing new features to market very quickly
Co
mp
etit
ive
Dif
fere
nti
atio
n
Buy as SaaS Build
Innovation Software
Differentiation Software
Develo
per-led
Pro
curem
ent
Core Software
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Innovation and Differentiation Systems are Different!Stop treating them like systems of record
IT-centric
Focus on Saving Money
Release Quarterly
Waterfall
Traditional Infrastructure
Dev/Ops Separated
Project-based
One Large, Monolithic ApplicationSoftware Manually Installed
Manual Scaling
Heavy Weight Governance
Tight Coupling
Stateful Middle Tiers
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Introducing Cloud Native ArchitectureUsed to build Cloud Native applications
10
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Microservices• Minimal Function• Service Discovery• API-first
3 • Polyglot• Choreography• Loose Coupling
DevOps• Automated Provisioning• Automated Setup• Continuous Integration
1 • Continuous Delivery• Automated Testing• Agile• Culture Change
* as a Service• Consume Infrastructure and
Software as a Service• Fault Tolerant by Definition
2 • Auto-scaling• Infinite Elasticity
What is Cloud Native?A new style of architecture
Distributed Computing• Multi-master• Many Data Centers• Many Fault Domains
4 • Many Regions• Global Server Load Balancing• Replication
Co
mp
eten
cy
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Prerequisite #1 - DevOpsRequires changes throughout your entire organization
Culture Technology
Respect
Discuss
Avoid Blaming
“Done” Means Released
Infra as Code
Shared Version Control
One Step Build/Deploy
Don’t Fix Anything
• Dev respect for ops• Ops respect for dev
• Ops should be in dev discussions• Dev should be in ops discussions• Shared runbooks
• No fingerpointing!• Everyone should have some
culpability
• Dev’s responsibility shouldn’t ever end – production support required
• “Throwing it over the wall” is dead
• Don’t build envs by hand• Scripts checked in and
managed as src
• Single system• Ship trunk• Enable features through flags
• One button build/deploy• If verification fails, stop and
alert or take action
• If something breaks, re-deploy. Don’t fix
• Fix environment setup scripts
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Start Using ContainersHelpful to microservices but not a requirement
Hardware
Hypervisor
VM 1
OS
App
VM 2
OS
App
Hardware Virtualization
Hardware
Operating System
Hypervisor
VM 1
OS
App
VM 2
OS
App
Para-virtualization
Hardware
Operating System
Container 1
App
Container 2
App
Containers
• #1 value – app packaging
• Microservices doesn't rely on containers but they do help:– Higher density
– Easy to start/stop
– Portability
• Containers are lightweight, just like microservices themselves
• Containers can run in VMs too
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Containers Are Now the StandardFour main use cases
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Application Packaging
Continuous Integration DIY PaaS
Infrastructure Consolidation
Neatly package applications and supporting environment in immutable, portable containers
All changes to an app are contained in one immutable container image. Container is tested and deployed as one atomic unit
Get infrastructure utilization up to 100% (vs 5-10% with VMs) due to over-subscription of resources and near bare metal performance.
Build a simple PaaS by wiring up containers to a load balancer. New code, patches, etc pushed as new immutable containers.
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Artifacts Are Now Immutable Containers – Not EARs, WARsContainers can have anything in them and are highly portable
Hardware
Operating System
Hypervisor
VM 1 VM 2
Legacy
Hardware
Operating System
Container 1 Container 2
Cloud Native
• No more installing a JVM, app server, and then deploying the artifacts to them
• Build the container once, deploy it anywhere. Can include complex environment variables, scripts, etc
• Containers should be free of state and configuration
• Containers should not assume they are able to write to a persistent local file system
OS
App Server
EAR/WAR
OS
App Server
EAR/WAR The Artifact You Deploy
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Strict Requirement: One Instance Per Container
• Run ONE instance (unique host/port combination) per container
• Running multiple instances of the same application or different applications will make scheduling very difficult
• Expose one port per containerPhysical Host
Operating System
Container
App
Container
App
Just One Per Container
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
How Do You Deploy Containers to Physical Hosts?The emerging space of container orchestration
What Do Container Orchestration Solutions Do?• Map containers back to physical
hosts, taking into account user-defined placement rules, the utilization of each host, and the needs of each container. Can be very complex
• Set up overlay networking, firewalls, ensure network QoS, etc
• Auto-scaling
• Local and external load balancers
• Service registry / discovery
HostHost
HostHost
HostHost
HostHost
HostHost
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
App
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
• Inventory Microservice
• AcmeCo• v1.2
Container
App
Many Containers
HostHost
HostHost
HostHost
HostHost
HostHost
Many Hosts
Docker Swarm
Emerging space. Solutions are very early and lack any real notion of an application. Still very much infrastructure-focused
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Best to Declaratively Build Containers Using DockerfilesFROM centos:centos6
# Enable Extra Packages for Enterprise Linux (EPEL) for CentOS
RUN yum install -y epel-release
# Install Node.js and npm
RUN yum install -y nodejs npm
# Install app dependencies
COPY package.json /src/package.json
RUN cd /src; npm install
# Bundle app source
COPY . /src
EXPOSE 8080
CMD ["node", "/src/index.js"]
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Everyone Should Be Able to Build Anything At Any Time
• Manual one button build/deploy
• Scheduled builds - every day, every week, etc
• Builds triggered by code checkins
• If post-build validation fails, report it
Set it and forget it
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Ongoing Operations is Now a Shared ResponsibilityIn perpetuity. No more “throwing it over the wall”
New GoalAdd new features and keep the system stable, fast and available
DevelopersPaid to add new features
that may break things
OperationsPaid to keep system
available, stable, and fast
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Stop Manually Fixing ProblemsIn no case should an administrator fix issues by hand. Should be 100% automated
Auto-scaling will automatically launch a new container on new hardware as load dictates
Hardware FailureExample: motherboard failed
Auto-scaling will automatically launch new containers as load dictates
Network FailureExample: switch failed
Health checking should fail and the container will be culled. Auto-scaling will automatically launch a new container as load dictates
System Software FailureExample: kernel panic
Application Software FailureExample: bad file permissions
Fix the source (your application, your container, your Dockerfile, etc) and re-deploy your entire application
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Prerequisite #2 - * as a ServiceRequires fundamental shift in how applications are built
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Your CodeHighly innovative, differentiated, etc
Configuration
Caching
Load Balancing Eventing
Logging
Monitoring
Database
NoSQLState
Messaging
3rd Party Cloud – On or Off Premise
Building Block
Building Block
Building Block
Building Block
Building Block
Building Block
Building Block
Building Block
Building Block
Building Block
Building Block
Building Block
Where you’re not differentiating, consume building blocks from 3rd party cloud vendor
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Everything is Now SoftwareProvision a new server just like you would provision a new object in Java
Person p = new Person();
$ docker run -v /host:/container example/myapp
curl -X POST "name=MyFirstApp" "runtime=java” "archiveURL=/binaries/myapp.zip"
$ puppet module install puppetlabs-java
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Today, Everything is 100% Code.
Automation at scale is standard
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Remove All Hard-coded IPs, Host Names, etc
24
Use service discovery, DNS, etc instead. Everything should be dynamic
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Make Your Middle Tier Stateless
25
Push all state and configuration down to highly available cloud services
Application Server
File System
Application Server
File System
Application Server
File System
Application Server
File System
Application Instance
File System
Load BalancerSticky to an Individual Instance
Application InstanceApplication
InstanceApplication InstanceApplication
Instance
Load BalancerNOT Sticky to an Individual Instance
StateService
ConfigurationService
Application Instance
Key to Cloud Native
Session StateShopping cart contents, page view data, personalization, etc
Application ConfigurationPort numbers, file system paths, host names, etc
Legacy Cloud Native
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Remember That Latency is EverywhereAsynchronously make calls to all remote systems
High latency within a single cloud. Can no longer assume 2ms between
application and data tiers
Application is now comprised of many different microservices, each
with its own datastore/database
Application is now deployed to multiple data centers, in multiple
availability zones, in multiple regions
26
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Empower Developers to Make Procurement Decisions
Core Software Differentiation Software Innovation Software
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
• #1 focus of cloud native: time to market. Long-term maintenance should not be a big consideration
• Let developers who are innovating pick the absolute best technology for their own use
• Each small team supports their own microservice in perpetuity. No need to have large maintenance teams
• Standardization is best for system of record-style applications
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Emit Logs as Event Streams
28
Can’t do anything with log files sitting on a container’s local storage volume
Log Entry Log EntryLog Entry
Log Entry
Log Entry
Log Entry
Log EntryLog Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log EntryLog Entry
Log Entry Log Entry
Container
Instance of Application
Log Entry Log EntryLog Entry
Log Entry
Log Entry
Log Entry
Log EntryLog Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log EntryLog Entry
Log Entry Log Entry
Container
Instance of Application
Log Entry Log EntryLog Entry
Log Entry
Log Entry
Log Entry
Log EntryLog Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log EntryLog Entry
Log Entry Log Entry
Container
Instance of Application
Capture, Aggregate, Search, Troubleshoot, etc
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Prerequisite #3 – Microservices
• Single monolithic application -> small, independently deployable microservices
• Each microservice:– Has its own team that designs, builds,
deploys and maintains it
– Exposes an API, which can be consumed elsewhere
– Has its own datastore/database
• Microservices are loosely coupled, with most communication over REST and async messaging
29
Break up your application into many small pieces to get features to market quickly
User Interface
Application
Datastore
Infrastructure
Status Quo
One Application
Microservices
Many Small Microservices
API
Application
Datastore
Infrastructure
InventoryMicroservice
API
Application
Datastore
Infrastructure
PaymentMicroservice
API
Application
Datastore
Infrastructure
ProfileMicroservice
API
Application
Datastore
Infrastructure
Product CatalogMicroservice
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Monolithic ApplicationsSingle, Monolithic App
Must Deploy Entire App
One Database for Entire App
Organized Around Technology Layers
State In Each Runtime Instance
One Technology Stack for Entire App
In-process Calls Locally, SOAP Externally
MicroservicesMany, Smaller Minimal Function Microservices
Can Deploy Each Microservice Independently
Each Microservice Has Its Own Datastore
Organized Around Business Capabilities
State is Externalized
Choice of Technology for Each Microservice
REST Calls Over HTTP, Messaging, or Binary
What Are Microservices?Minimal function services that are deployed separately but can interact together to achieve a broader use-case
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Three Key Rules to Microservices
Don’t share a datasource across microservices
Can release each microservice independently
Can build a microservice independently
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Horizontally Tiered Enterprises == Horizontally Tiered AppsConway’s Law: Software reflects the structure of the organization that produced it
User Interface
Application
Datastore
Infrastructure
Resulting SoftwareTypical Enterprise Organization Structure
Head of IT
Head of Operations
Head of DBAsHead of
InfrastructureHead of App
DevHead of UI
Head of Development
An Enormous Monolith
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Re-structure Your Organization – Put Conway’s Law to Work
33
Build small product-focused teams – strict one team to one microservice mapping
Resulting SoftwareMicroservices Organization Structure
Many Small Microservices
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
Product Lead
Project Manager
Sys Admin DBAJavaScript Developer
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Product Lead
Project Manager
Sys Admin DBAJavaScript Developer
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Product Lead
Project Manager
Sys Admin DBAJavaScript Developer
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Product Lead
Project Manager
Sys Admin DBAJavaScript Developer
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Even Simple Changes Are Hard to Implement With Monoliths
34
Organizational boundaries introduce the need to extensively coordinate
User Interface
Application
Datastore
Infrastructure
New requirement: Add a birthdate property to the customer’s profile. How does this get implemented?
Application developer tickets DBAs to have them add that property as a column in the database
1.
Application developer tickets UI team to have them add that property to the profile screens
3.
Application developer adds the new property to the application-level code
2. Different TeamsDifferent TimelinesDifferent PrioritiesDifferent Ticketing
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Much Faster Turnaround With Microservices
The profile microservice team – three people total, all sitting together
Turn around changes in hours vs. months
Hey Jim, can you add that column to the
database before lunch?
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Low latency, high bandwidth communication
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Do One Thing and Do It Well
Focus on Business Capabilities
Avoid Inter-dependencies
Start Managing Small, Vertical TeamsCan have hundreds of microservices for a larger application
Large
Medium
Small
11-15 PeopleExample: Order Microservice
4-10 PeopleExample: Inventory Microservice
1-3 PeopleExample: Order Status Microservice
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Owners Support in Production
Everythingis Owned by a Small Team
Owners Implement
Owners Architect
OwnersCare
Owners Can Fix Things
Ownership is Key to the Success ofCloud NativeIn traditional enterprises, any one individual has very low ownership of anything. It’s classic tragedy of the commons
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Teams Do Not Have 100% FreedomStandardize where it makes sense. Be pragmatic
Custom Code
Communication Protocol
Data Format
Infrastructure
Datastore
Sou
rce
Co
ntr
ol
Co
nfi
gura
tio
n M
anag
emen
t
Dev
elo
pm
ent
Too
ling
Alerting
Monitoring
Standardize on One
Offer a Menu of 2-3 Options
Team Has Complete Choice
Programming Language
Messaging
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Developers Want Choice in Programming Language
• Different languages for different specialized microservices
• Remember – the goal of cloud native is time to market. It is NOT about long-term maintainability
• If maintenance becomes an issue, rewrite the microservice over a weekend
Use the language that works best
API
Application
Datastore
Infrastructure
InventoryMicroservice
API
Application
Datastore
Infrastructure
ChatMicroservice
API
Application
Datastore
Infrastructure
Product RecommendationMicroservice
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Run Many Versions of the Same Microservice Concurrently
Monolithic Application
v1.1
Microservice AMicroservice A
Microservice AMicroservice A
Microservice AMicroservice Bv1.1
Microservice AMicroservice A
Microservice AMicroservice A
Microservice A
Microservice AMicroservice A
Microservice AMicroservice A
Microservice AMicroservice Bv1.2
Microservice AMicroservice A
Microservice AMicroservice A
Microservice A
Run only one version of the same application in the same environment
Run many versions of each microservice in the same environment
Microservice Av1.2
Microservice Av1.1
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Use Blue/Green Deployments When One Version Can Be LiveBlue is current. Deploy new code to green. Switch load balancer from blue to green
ApplicationLive in production - v1.1
ApplicationIn production but no
traffic from load balancer
v1.2
“Blue” Environment “Green” Environment
Identical EnvironmentsEach capable of handling 100% of production traffic
“Blue” can be shut down after code deployment is successful.
New CodeCurrent Code
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.42
Orchestration vs. Choreography
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
4
Scenario: eCommerce user returns a widget through web-facing .com
Example of Orchestration
Centralized Workflow
Self Service Help
Initiate Return
Workflow
Increment Inventory
Done
Inventory
Record Refund
Done
Customer Profile
Done
Payment
Refund Money
Brittle | Centralized | Tightly Coupled
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Scenario: Inventory microservice
Example of Choreography
Inventory Microservice
All asynchronous
Event Bus
New Inventory
Events This Microservice Cares About Events This Microservice Emits
Product Returned
Product Sold
Product Recalled
Inventory Incremented
Inventory Created
Inventory Decremented
Inventory Deleted
For Anyone Who Cares...
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Avoid Synchronous Calls for Read-only Data By Copying
Product PricingInventory
Promotions
Product PricingInventory
Promotions
Product PricingInventory
Promotions
Product Catalog• Synchronous in-memory calls• Data is 100% consistent• No data is duplicated
Request for Category Page
Product Catalog
Product
Pricing
Inventory
Promotions
• Synchronous calls to product catalog microservice• Product, pricing, inventory and promotions
microservices are systems of record; they publish asynchronously to Product Catalog microservice when updated
• Product Catalog microservice is not always consistent• Data is duplicated – two or more microservices may
contain the same data
TraditionalMonoliths
New Microservices
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Prerequisite #4 – Distributed ComputingRun your applications across multiple data centers, fault domains, regions, etc
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Cloud
Region
Fault Domain
Data Center
Host
Container
Microservice
Microservice
Microservice
Microservice
Hundreds of milliseconds
of latency
Everything is now distributedEven within the same data center
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Everything Is Now Distributed. Get Used To It
Applications Infrastructure Teams
Applications are now broken up into small microservices, with separate frontends and backends
Different data centers, fault domains, regions, etc. Even within the same data center, latency may be unacceptably high
Many small teams, each responsible for their own microservice. Each team is often geographically distributed
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Microservices Forces Move To Distributed ComputingIntroduces enormous complexity – monoliths don’t suffer from this
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
Microservice A Microservice B Microservice C Microservice D
• Distributed computing is a natural consequence of microservices because each microservice has its own datastore
• Sharing datastores across microservices introduces coupling – very bad!
• There will always be latency between microservices
• Latency = eventual consistency
• All data exchange between microservices must be through API layer or messaging – no accessing datastores cross-microservices
• Must implement high-speed messaging for synchronous calls between microservices. REST + HTTP probably isn’t fast enough
• May end up duplicating data across datastores –e.g. a customer’s profile
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Eliminate SingletonsSingletons are an evil necessity. They do not have to be “fixed”
DynamicAvailable at well known service
name. Instances are dynamically elected at runtime. If instance
goes down, another will take over
FixedAvailable at IP/ports. Instances are long-lived, though IP/ports change. If instance goes down,
people will know
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Top Related