Microservices with integration, containers and APIs: what s

Transcription

1 Microservices with integration, containers and APIs: what s next?

2 Christian Posta Chief Architect, cloud application development Twitter: Blog: Slides: Author Microservices for Java developers Committer/contributor lots of open-source projects Worked with large Microservices, web-scale, unicorn company Blogger, speaker

3 Microservices: What, Why, When

4 A microservices definition 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

5 Microservices: a re-org around APIs as product 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

6 Drawbacks to microservices? System complexity Operational complexity Testing is harder across services Security Hard to get boundaries right (transactions, APIs, etc) Resource overhead Network overhead

7 Why would one implement a system as microservices?

8 Pain we may feel 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

9 Pain we may feel 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,

10 Microservices is about optimizing for speed.

11 So do we microservices all the way down?

12

13 Lean Enterprise:

14 MVP tests, experiments, small apps (co-locate if you have to write an app) Product development, initial scale (co-locate perfectly okay!! Microservices? possibly ) Starting to feel the weight of maintenance, need to shoot for efficiencies, integrate new approaches to increase revenue (microservices land)

15 DON T optimize for microservices if 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

16 Making high performance economical

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

18 High performing IT teams 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 (

19 High performing IT teams need these IT capabilities and practices Continuous Integration/Delivery Safe, reliable delivery mechanisms Low-risk deployment vs release processes Modern, scalable, resilient application architectures Self-service, on-demand infrastructure Automated testing Metrics, logs, traces, observability Feedback loops

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

21 Microservices platform Distributed configuration Service Discovery Loadbalancing Circuit Breakers Bulkheading What about non-java? Versioning/Routing Based on AWS

22 Cluster management Distributed configuration Service Discovery Loadbalancing Versioning/Routing Deployments Scaling/Autoscaling Liveness/Health checking Self healing

23

24 OpenShift is a Kubernetes distribution 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

25 Balancing speed and reliability: resilience, control, observability

26 Integration, containers, APIs == distributed systems

27

28

29

30

31

32

33 Integration sucks! Just do REST/HTTP?

34

35 Microservices patterns 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)

36

37 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

38 But I m using Vert.x! vertx-circuit-breaker vertx-service-discovery vertx-dropwizard-metrics vertx-zipkin?.....

39

40

41 Things you must solve for because distributed systems Service discovery adaptive routing Edge/DMZ routing Retries Deadlines Surgical / fine / Timeouts Back pressure Load balancing Outlier detection A/B rollout Rate limiting Health checking dark launches Thread bulk heading Traffic shaping Fault injection Circuit breaking Request shadowing per-request routing Stats, metric, collection

42 Meet Envoy Proxy

43

44

45 Meet Istio Service Mesh

46 Demo Architecture

47 Are you doing microservices? 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?

48 Focus on going fast and learning Number of features accepted % of features completed User satisfaction Feature Cycle time defects discovered after deployment 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!

49 More material The hardest part of microservices? Your data Microservices patterns: circuit breaking with Envoy Proxy t-i-circuit-breaking/ Monolith to microservices Part I Monolith to microservices Part II

50 Quick demo? Twitter: Blog: Follow up links: Slides: BTW: Hand drawn diagrams made with Paper by FiftyThree.com