Microservices: key factor in integration, containers and APIs · • You’re building a Minimum Viable Product (MVP), testing a hypothesis ... "Cloud native” describes applications,

Microservices: key factor in integration, containers and APIs

@christianposta

Christian Posta Chief Architect, cloud application development

Twitter: @christianposta

Blog: http://blog.christianposta.com

Email: [email protected]

Slides: http://slideshare.net/ceposta

•  Author “Microservices for Java developers” •  Committer/contributor lots of open-source

projects •  Worked with large Microservices, web-scale,

unicorn company •  Blogger, speaker about DevOps, integration,

and microservices

Microserivces: What, Why, When

@christianposta

“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.”

A microservices definition

•  Single, self-contained, autonomous •  Isolated and Resilient to faults •  Faster software delivery •  Own their own data •  Easier to understand individually •  Scalability •  Right technology for the problem •  Test individual services •  Individual deployments

Microservices: a re-org around APIs as product

@christianposta

•  System complexity •  Operational complexity •  Testing is harder across services •  Security •  Hard to get boundaries right (transactions,

APIs, etc) •  Resource overhead •  Network overhead •  Lack of tooling

Drawbacks to microservices?

@christianposta

Why would one implement a system as microservices?

@christianposta

Pain we may feel…

@christianposta

•  Making changes in one place negatively affects unrelated areas

•  Low confidence making changes that don’t break things •  Spend lots of time trying to coordinate work between

team members •  Structure in the application has eroded or is non-

existant •  We have no way to quantify how long code merges will

take

@christianposta

•  Development time is slow simply because the project is so big (IDE bogs down, running tests is slow, slow bootstrap time, etc)

•  Changes to one module force changes across other modules

•  Difficult to sunset outdated technology •  We’ve built our new applications around old premises

like batch processing •  Application steps on itself at runtime managing

resources, allocations, computations

Pain we may feel…

Microservices is about optimizing for speed.

@christianposta

So do we microservices all the way down?

@christianposta

@christianposta http://blog.gardeviance.org/2012/06/pioneers-settlers-and-town-planners.html

@christianposta

Lean Enterprise: http://shop.oreilly.com/product/0636920030355.do

@christianposta

MVP tests, experiments, small apps (co-locate if you have to write an app)

Product development, initial scale (co-locate perfectly okay!! Microserices? possibly…)

Starting to feel the weight of maintenance, need to shoot for efficiencies, integrate new approaches to increase revenue (microservices land)

http://blog.gardeviance.org/2012/06/pioneers-settlers-and-town-planners.html

DON’T optimize for microservices if…

@christianposta

•  You’re building a Minimum Viable Product (MVP), testing a hypothesis

•  You’re building a CRUD application •  Your application is simple •  Your system doesn’t have > 10 people all trying to coordinate to

work on it •  Your application doesn’t need to scale •  You deliver packaged software •  You’re building HPC systems

Making “high performance” economical

@christianposta

We can now assert with confidence that high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share.

@christianposta

https://puppet.com/resources/whitepaper/2014-state-devops-report

High performing IT teams

@christianposta

•  …are encouraged to experiment •  …learn from failure •  …work in small batches •  …deliver to production many times a week •  ...have a lower change failure rate •  …focus on getting continuous feedback •  …are held to outcomes, not output •  …continuously prioritize and reprioritize based on cost

of delay (http://blackswanfarming.com/cost-of-delay/)

High performing IT teams need these IT capabilities and practices

@christianposta

•  Continuous Integration (build from master) •  Continuous Delivery (automated pipelines) •  Safe, reliable delivery mechanisms •  Modern, scalable, resilient application architectures •  Self-service, on-demand infrastructure •  Automated testing •  Metrics, logs, traces, observability •  Feedback loops •  Security as part of the pipeline

@christianposta

https://www.infoq.com/articles/cloud-native-panel

"Cloud native” describes applications, architectures, platforms/infrastructure, and processes, that together make it economical to work in small batches to learn and reduce uncertainty.

•  Distributed configuration

•  Service Discovery

•  Loadbalancing

•  Circuit Breakers

•  Bulkheading

•  Versioning/Routing

•  Based on AWS

“Microservices” platform

What about non-java?

@christianposta

Cluster management

•  Distributed configuration

•  Service Discovery

•  Loadbalancing

•  Versioning/Routing

•  Deployments

•  Scaling/Autoscaling

•  Liveness/Health checking

•  Self healing

•  Logging, Metrics, Tracing

@christianposta

@christianposta

•  Team self service application deployment •  Developer workflow •  Enterprise focused (LDAP, RBAC, Oauth, etc) •  Integrated Docker registry •  Jenkins Pipeline (CI/CD) out of the box •  Build/deployment triggers •  Software Defined Networking (SDN) •  Docker native format/packaging •  CLI/IDE/Web based tooling

OpenShift is a Kubernetes distribution

@christianposta

Balancing speed and reliability: resilience, control, observability

@christianposta

@christianposta

Integration, containers, APIs == distributed systems

@christianposta

@christianposta http://bit.ly/application-networking






•  Netflix Hystrix (circuit breaking / bulk heading)

•  Netflix Zuul (edge router)

•  Netflix Ribbon (client-side service discovery / load balance)

•  Netflix Eureka (service discovery registry)

•  Brave / Zipkin (tracing)

•  Netflix spectator / atlas (metrics)

“Microservices” patterns

@christianposta


But I’m using Spring!

•  spring-cloud-netflix-hystrix

•  spring-cloud-netflix-zuul

•  spring-cloud-netflix-eureka-client

•  spring-cloud-netflix-ribbon

•  spring-cloud-netflix-atlas

•  spring-cloud-netflix-spectator

•  spring-cloud-netflix-hystrix-stream

•  …..

•  ......

•  @Enable....150differentThings

But I’m using Vert.x!

•  vertx-circuit-breaker

•  vertx-service-discovery

•  vertx-dropwizard-metrics

•  vertx-zipkin?

•  …..

•  ......

ButI’musingNodeJS!

ButI’musingGo!

ButI’musingPython!

Getthepoint?

Things you must solve for because… distributed systems

•  Service discovery

•  Retries

•  Timeouts

•  Load balancing

•  Rate limiting

•  Thread bulk heading

•  Circuit breaking

•  adaptive routing

•  Deadlines

•  Back pressure

•  Outlier detection

•  Health checking

•  Traffic shaping

•  Request shadowing

•  Edge/DMZ routing

•  Surgical / fine / per-

request routing

•  A/B rollout

•  Internal releases / dark

launches

•  Fault injection

•  Stats, metric, collection

•  Observability

@christianposta https://lyft.github.io/envoy/

Meet Envoy Proxy

Sidecarpattern

Meet Istio Service Mesh

https://istio.io

Demo Architecture

https://istio.io/docs/samples/bookinfo.html

•  Have self-service infrastructure automation?

•  Have self-service application automation?

•  Have working CI/CD?

•  Have health checking, monitoring, instrumentation?

•  Have logging, distributed tracing?

•  Able to release services independently?

•  Honoring backward and forward compatibility?

Are you doing microservices?

@christianposta

•  Number of features accepted •  % of features completed •  User satisfaction •  Feature Cycle time •  defects discovered after deployment •  customer lifetime value (future profit as a result of relationship with the

customer) https://en.wikipedia.org/wiki/Customer_lifetime_value •  revenue per feature •  mean time to recovery •  % improvement in SLA •  number of changes •  number of user complaints, recommendations, suggestions •  % favorable rating in surveys •  % of users using which features •  % reduction in error rates •  avg number of tx / user •  MANY MORE!

Focus on going fast and learning

•  The hardest part of microservices? Your data https://developers.redhat.com/blog/2016/08/02/the-hardest-part-about-microservices-your-data/

•  Microservices patterns: circuit breaking with Envoy Proxy https://developers.redhat.com/blog/2017/05/31/microservices-patterns-with-envoy-sidecar-proxy-

part-i-circuit-breaking/

•  Monolith to microservices Part I https://developers.redhat.com/blog/2017/09/26/low-risk-monolith-microservice-evolution-part/

•  Monolith to microservices Part II https://developers.redhat.com/blog/2017/10/23/low-risk-monolith-microservice-evolution-part-ii/

More material

@christianposta

Quick demo?

BTW: Hand drawn diagrams made with Paper by FiftyThree.com J @christianposta

Twitter: @christianposta

Blog: http://blog.christianposta.com

Email: [email protected]

Slides: http://slideshare.net/ceposta

Follow up links:

•  http://openshift.io •  http://launch.openshift.io •  http://blog.openshift.com •  http://developers.redhat.com/blog •  https://www.redhat.com/en/open-innovation-labs •  https://www.redhat.com/en/technologies/jboss-middleware/3scale •  https://www.redhat.com/en/technologies/jboss-middleware/fuse

Documents

Microservices: key factor in integration, containers and APIs · • You’re building a Minimum Viable Product (MVP), testing a hypothesis ... "Cloud native” describes applications,