Upload
daniel-woods
View
764
Download
6
Tags:
Embed Size (px)
Citation preview
MicroservicesThe Right Way
GR8CONF / MINNEAPOLIS / 2015-07-30
@danveloper
A Simple Truth
There is no right way to “do” microservices.
• Microservices represent a problem domain that scales development, architecture, operations, and infrastructure
• Thinking that one-size-fits-all is naïve• Need to consider your domain and how it should
all fit together
Guidelines for Microservices
• Should perform a single function in the scope of the domain– Business/Platform/Operation function
• Should not emphasize LoC in the “micro” mindset– “Micro” should speak to a service’s function, not
its size• Should encapsulate its domain– Domain modeling, business logic, API
What Are You Building?
• Understand how your distributed infrastructure fits together
• Are you building a set of services that collaborate toward a common goal?– Then you’re building a “platform”
• Are you building services that act in a one-off or composable manner?– Then you’re building a “distributed service layer”
Building A Platform
• A Platform is composed of many different microservices that collaborate in terms of a broader “system”
• Microservices perform a very specific function in the overall processing
• A Gateway Layer should be employed to service consumers
Platform ArchitectureM
icro
serv
ice
Mic
rose
rvic
e
Mic
rose
rvic
e
Mic
rose
rvic
e
Mic
rose
rvic
e
Mic
rose
rvic
e
Mic
rose
rvic
e
Mic
rose
rvic
e
Gateway Layer
Platform Architecture
• Consumers never speak directly to the underlying microservices
• Consumers talk to the Gateway layer as though they are talking to a monolith
• Microservices never talk amongst themselves– They are clean vertical slices in the architecture
• Gateway layer is responsible for consuming and aggregating data from microservices
Platform Architecture
• In a platform, the data model is coupled because of the overall collaborative nature of the system• It is OK to share a data model between microservice and
Gateway layers through a client library• Since the Gateway will be the only consumer of a backend
microservice, coupling via a client library is OK
• Gateway can gracefully degrade service or data offerings when a backend service is not available
Distributed Service Layer Microservices
• Distributed Service Layer microservices are those services that do not cooperate within a strict “system”
• They are able to be composed by many consumers for their purposes
• Consumers are responsible for understanding the service’s data structures and domains
Distributed Service Layer
Microservice
Microservice
Microservice
MicroserviceMicroservice
MicroserviceMicroservice
Distributed Service Layer Microservices
• Interconnectivity means the dependency graph can be difficult to figure out
• Failure in the overall infrastructure can be difficult to realize and trace
• May be difficult to push data structure and model changes without breaking many consumers
• Can quickly turn in “spaghetti infrastructure”
OFFICEModern Application Architecture
DatabaseDatabaseDatabase
Database
Database
Database
Database
REST API
microservice
microservice
microservice
microservice
microservice
microservice
microservice
microservice
microservice microservice
microservice
microservice
microservice
microservice
microservice
microservice
microservice
Brent’s Desk
microservice
Courtesy of @bizzyunderscore
Distributed Service Layer Microservices Architecture
• Define two tiers of distributed service layer types: data consumers/aggregators & data producers
• Having a logical boundary between services that talk to other services and those that do not makes the infrastructure manageable
• Data producers should not inter-communicate at their level
Distributed Service Layer Microservices Architecture
Microservice Microservice Microservice Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Distributed Service Layer Microservices Architecture
• Microservices should not share a domain model– The complexity of a distributed service layer can
make dependency management very difficult• Microservices should focus on documentation
as the contract• Consumer service tier should be resilient to
failure
Distributed Service Layer Microservices Architecture
• Considerations:– What about when one or more “consuming”
service tier microservices want to collaborate?– Dependency graph can still be messy; versioning
of APIs and data models should be strictly adhered to
– Documentation is hard to get right. How can we make service structures and APIs more discoverable?
Documentation
• It’s important to document a distributed service layer microservice in a “human consumable” way– Explaining the domain and what a service is doing
is more important than showing the endpoints– Showing the endpoints is still important
• Platform architectures should expose documentation through the Gateway layer
Documentation
• Discoverability:– Documentation can be difficult to maintain and
manage, especially with an evolving API– Statically documenting the API is OK, making it
programmatically discoverable is better– Documentation + making the API discoverable
gives great coverage over what a service is doing and how to interface with it
Discoverability
• HATEOAS– Informs of what relationships exist within the data
object that is returned– Informs of how to access the data of some
relationship– Can be a great strategy for gracefully degrading
behavior in a platform
Discoverability
• Platform ArchitecturePr
oduc
t M
icro
serv
ice
Revi
ewM
icro
serv
ice
Use
rM
icro
serv
ice
Paym
ent
Mic
rose
rvic
e
Gateway Layer
/product/…
/review/…/user/…
/payment/…
Discoverability
{ “_links”: [ { “rel”: “product.list”, “href”: “/product/list” }, { “rel”: “product.search”, “href”: “/product/search” }, { “rel”: “reviews.show”, “href”: “/reviews/show{?productId}” }, ... ]}
GET /status
Discoverability
• Platform ArchitecturePr
oduc
t M
icro
serv
ice
Revi
ewM
icro
serv
ice
Use
rM
icro
serv
ice
Paym
ent
Mic
rose
rvic
e
Gateway Layer
/product/… /user/…
/payment/…
X
Discoverability{ “_links”: [ { “rel”: “product.list”, “href”: “/product/list” }, { “rel”: “product.search”, “href”: “/product/search” }, { “rel”: “reviews.show”, “href”: “/reviews/show{?productId}” }, ... ]}
Discoverability
• HATEOAS– When the review service goes offline, we can
inform consumers by removing it from the _links block in the data object
– This means that we only need to document the model and intention of the service
– Consumers will only need to know the relationship within the system to know
Discoverability
• JSON-LD– Provides a “linked data” structure for consumers– Allows you to provide a type for your API
endpoints, and can be programmatically interpreted in a number of ways
– Worth investigating: http://www.hydra-cg.com/
Project Structure
• Many questions in a microservice architecture:– Repo per microservice?– Module per microservice?– Every microservice in its own process space?
Project Structure
• In services that do not collaborate, they should not share a project structure
• It may make sense for platform microservices to exist as a module in a singular project
• Following a repo-per- approach for distributed service layer microservices keeps the concerns nicely isolated– “What about when we need to share common things
(constants, configs, etc)?” Publish a library; it’s easier than ever with things like jfrog* and jcenter*
* http://bintray.com
Project Structuremicroservice
microservice
Project Structure
Microservice’s own Main class
Project Structure
• Principles:– Generate a self-contained, lightweight artifact– Should be runnable and environment agnostic
(within the build)– Runnable JARs or a standalone distribution is the
best way to go
Project Structure
• Principles:– Generate a self-contained, lightweight artifact– Should be runnable and environment agnostic
(within the build)– Runnable JARs or a standalone distribution is the
best way to go
Project Structure
apply plugin: 'groovy’apply plugin: 'application'
mainClassName = "com.tld.microservice.Main"
repositories { jcenter()}
dependencies { compile 'org.codehaus.groovy:groovy-all:2.4.3’ ...}
How do we run this thing
Project Structure
apply plugin: 'groovy’apply plugin: 'application'
mainClassName = "com.tld.microservice.Main"
repositories { jcenter()}
dependencies { compile 'org.codehaus.groovy:groovy-all:2.4.3’ ...}
How do we build this thing
Project Structureapply plugin: 'groovy’apply plugin: 'application’
...
• Gradle Task
./gradlew installDist
Creates a distribution of the application, which pulls down all the dependencies, structures them in a directory, and produces shell scripts that can start the app in a standalone way.
Can be found in {projectDir}/build/install/{projectName}
Project Structurebuildscript { repositories { jcenter() } dependencies {
classpath 'com.github.jengelman.gradle.plugins:shadow:1.2.1’ }}
apply plugin: 'groovy’apply plugin: 'application’apply plugin: 'com.github.johnrengelman.shadow’
mainClassName = "com.tld.microservice.Main"
repositories { jcenter()}
dependencies { compile 'org.codehaus.groovy:groovy-all:2.4.3’ ...}
Project Structure
./gradlew shadowJar
• Produces a “fat jar” with all the dependencies contained• Integrates with the application plugin to make the fat jar
runnable• Excellent solution for building lightweight deployables• Can be run anywhere Java is available
Infrastructure
• Managing a microservice infrastructure is difficult
• Big benefit to microservices/distributed systems is the ability to scale a service according to its specific requirements
• Means that all microservices will run on their own instances/containers
Infrastructure
• Infrastruct principles for microservices:– Follow immutable infrastructure paradigms– Make the unit of deployment for a microservice
portable– Structure microservices such that configuration is
derived from the runtime environment
Infrastructure
• Immutable infrastructure:– Once a server is provisioned, it cannot be changed– Any detail about provisioning a server for a
microservice should come from the microservice’s build– Initialization, service starting, base configuration should
be performed only once during provisioning, never adjusted after that
– Any modifications to the server’s runtime should be in change control under the microservice project’s purview
Infrastructure
• Portable deployables:– Building just a JAR is fine, but it doesn’t inform the
server as to how to run that JAR– Unit of deployment should specify all of the
dependencies required to run your application• “My microservice depends on Java”, for example
– Unit of deployment should self-contain any configuration steps, including things like ansible/chef/puppet runs (beyond any base-image configuration)
Infrastructure
• Portable deployables:– Package your project as an os-package– Gradle plugin available from Netflix (Nebula) to
pull your project into a .deb or .rpm file• Provides a DSL for specifying pre-install/post-install
steps• Uses Gradle CopySpec to install files into the resulting
os package
buildscript { repositories { jcenter() } dependencies {
classpath 'com.netflix.nebula:gradle-ospackage-plugin:2.0.2’ }}
... [snip] ...
mainClassName = "com.tld.products.Main"
ospackage { packageName = "products" release '3' into "/opt/products" from "${project.buildDir}/install/${project.applicationName}"
from("osfiles") { into "/" }}
buildDeb { dependsOn installDist requires(“openjdk-7-jre”) preInstall file('scripts/preInstall.sh')}
buildscript { repositories { jcenter() } dependencies {
classpath 'com.netflix.nebula:gradle-ospackage-plugin:2.0.2’ }}
... [snip] ...
mainClassName = "com.tld.products.Main"
ospackage { packageName = "products" release '3' into "/opt/products" from "${project.buildDir}/install/${project.applicationName}"
from("osfiles") { into "/" }}
buildDeb { dependsOn installDist requires(“openjdk-7-jre”) preInstall file('scripts/preInstall.sh')}
Places the generated applicationproject structure into /opt/products
buildscript { repositories { jcenter() } dependencies {
classpath 'com.netflix.nebula:gradle-ospackage-plugin:2.0.2’ }}
... [snip] ...
mainClassName = "com.tld.products.Main"
ospackage { packageName = "products" release '3' into "/opt/products" from "${project.buildDir}/install/${project.applicationName}"
from("osfiles") { into "/" }}
buildDeb { dependsOn installDist requires(“openjdk-7-jre”) preInstall file('scripts/preInstall.sh')}
Puts everything in the project’s“osfiles” directory into the root of theserver’s filesystem (config, start scripts, other?)
buildscript { repositories { jcenter() } dependencies {
classpath 'com.netflix.nebula:gradle-ospackage-plugin:2.0.2’ }}
... [snip] ...
mainClassName = "com.tld.products.Main"
ospackage { packageName = "products" release '3' into "/opt/products" from "${project.buildDir}/install/${project.applicationName}"
from("osfiles") { into "/" }}
buildDeb { dependsOn installDist requires(“openjdk-7-jre”) preInstall file('scripts/preInstall.sh')}
Informs the server as to any dependenciesthat your project might have
buildscript { repositories { jcenter() } dependencies {
classpath 'com.netflix.nebula:gradle-ospackage-plugin:2.0.2’ }}
... [snip] ...
mainClassName = "com.tld.products.Main"
ospackage { packageName = "products" release '3' into "/opt/products" from "${project.buildDir}/install/${project.applicationName}"
from("osfiles") { into "/" }}
buildDeb { dependsOn installDist requires(“openjdk-7-jre”) preInstall file('scripts/preInstall.sh')}
Will execute the script before your projectis installed on the server. Allows you to provideAny additional tuning.
Infrastructure
./gradlew buildDeb
• Produces the artifact into the {project}/build/distributions/{projectName}_{version}-3.deb file
• Can be installed on any server/container and all dependencies are resolved at provisioning
• “osfiles” can include anything, but common use-cases are startup scripts, any system-level configuration needed by the microservice
• Pre/Post install can include things like Ansible/Chef/Puppet runs
Infrastructure
Infrastructure
• Docker:– An “OK” option for microservices– Can be difficult to manage– Cloud providers out there taking this on• CloudFoundry (cloudfoundry.com)• Morpheus (gomorpheus.com)• Project Atomic (projectatomic.io)
– Gradle Plugin available for packaging your microservice as a Docker container• https://github.com/bmuschko/gradle-docker-plugin
Microservice Configuration Management
• When you get into a distributed architecture, you need faculties to help manage configuration
• Builds/projects should be agnostic to the environment they are deployed in
• Environment configuration should be derived from the environment
Microservice Configuration Management
• Configuration management (K/V store, consul for example)
Consul
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice Configuration Management
• Configuration management (K/V store, consul for example)$ curl localhost:8500/v1/kv/configs/dev/mymicroservice
{ “database”: { “username”: “user”, “password”: “…”, “url”: “jdbc:mysql://db.host:3306/db” }, …}
Microservice Configuration Management
• Rules of thumb for configuration management:– Place config server in an internal DNS zone– For robust architectures, have a config server per
environment– Have microservices re-poll the configuration server
for any real-time changes– During server deployment, export the environment
key (as part of User Data, for example)
Microservice Configuration Management
• Spring Cloud OSS helps provide integration with configuration management servers for pulling properties dynamically– Gives you the ability to read from Cloud CM– Provides management endpoints for updating
microservice configurations dynamically
– https://github.com/spring-cloud/spring-cloud-config#spring-cloud-config-client– http://cloud.spring.io/spring-cloud-consul/spring-cloud-consul.html
Additional Considerations
• Metrics Reporting– Use statsd and things will be very portable
• Service Discovery– Eureka, Consul, Load Balancing
• Log publishing– Should write out application logs to a common
location (S3, for example) for inspection
QUESTIONS.