tech talks microservices
TRANSCRIPT
Microservices & Spring RESTBuilding applications for the cloud Tech Talks
Agenda
• What are Microservices?
• What are not Microservices?
• REST Services
• Build REST Services with Spring
• Questions and Answers
215 May 2015
What is for you Microservices?
What is Microservices?
• It 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
• Fine-grained domain capability• Independently deployable • Independently releasable• Language, data storage and technologies agnostic• Designed for the Cloud
415 May 2015
What is not for you microservices?
What is not Microservices?
• Monolithic• Layered Cross-Functional• Intelligently integrated• Centrally integrated
615 May 2015
Monolithic -> SOA -> Microservices
• SOA is too coarse-grained, Microservices is fine-grained and practical SOA.
715 May 2015
Monolith vs Microservices
Monolith Microservice
Simplicity Partial deployment
Consistency Availability
Inter-modular refactoring Real Modular
Technology constraints Multiple platforms
815 May 2015
Microservice Benefits
• Autonomy of the team• Ownership• Speed of change• Scalability• Elasticity• Innovation• Tech diversification• Less code, more value
915 May 2015
Microservices Hidden Costs
• Network latency• Network reliability• Packet lost• Bandwidth• Security• Testing is more complicated• DevOps
1015 May 2015
Microservices Complexity
• Communication– Better documentation– Fan customer empathy
• Execution– Continuous deployment and delivery
• Resilience– Stateless Docker Containers
• Maintenance– Backward compatibility
• Operational– Easy usability
1115 May 2015
MicroservicesStructural principles• Resilient to failure – Resiliency is designed into the application, rather than wrapped around it
after the fact. Failures in cloud infrastructure are handled fluidly without interruption of service.
• Resilient to latency – Applications adapt gracefully to latency rather than timing out/failing. High
• Secure – Applications are based on secure lifecycle standards and include built-in
security– Data at rest and in transit is encrypted. APIs are protected by authentication
and authorization.
1215 May 2015
• Location independent – Applications discover services dynamically rather than relying on hard-coded
dependencies
• Elastically scalable– Applications respond to demand levels, growing and shrinking as required, in
and among clouds
• SOA/Compose-ability– Applications consume and expose web services with APIs discoverable at
runtime. The structure incorporates small, stateless components designed to scale out
MicroservicesStructural principles
1315 May 2015
• Designed for manageability – Applications are instrumented and expose metrics and management
interfaces
• Infrastructure independent – Applications make no assumptions about the underlying infrastructure, using
abstractions in relation to the operating system, file system, database, and so on
• Defined tenancy – Each application should have a deliberate, defined single tenancy or
multitenancy model
MicroservicesStructural principles
1415 May 2015
MicroservicesStructural principles• Available end-user self-service – Users should be able to register themselves to use the app through a self-
service registration interface, without entering an IT service request
• Bandwidth aware – APIs and application protocols are designed to minimize bandwidth
consumption
• Cost and resource consumption aware – Application architecture is designed to minimize costs due to bandwidth,
CPU, storage consumption, and I/O requests
1515 May 2015
MicroservicesOperational strategies• Ensure redundancy – Applications are designed to be resilent to failure though the use of
redundancy. High
• Utilize caching – Caching is used to improve performance, increase resiliency, and reduce
bandwidth costs. High
• Secure access to APIs – API end points are protected via API Management gateways. High
• Stage deployments – The risk of failure due to deployment is reduced by staging the introduction
of updates to components of an application. Medium
1615 May 2015
MicroservicesOperational strategies• 5 Plan for zone/ region failures– Applications are deployed in a way that is resilient to disasters, such as entire
geographic zone or region failures
• Minimize inter-zone/ region latency– Applications are deployed geographically to minimize network latency
• Locate high-bandwidth consumers externally– High bandwidth consumers are hosted outside the cloud to reduce cloud
bandwidth utilization costs
• Abstract dependencies – API abstractions are used to prevent lock-in with proprietary cloud services
1715 May 2015
Microservices Patterns• Very, very small• Loosely coupled ( including flow)• Versioning• Backward compatibility• Blue/Green deployments• Toggle features• Continuous delivery• Convention over Configuration• Service Discovery Service• Monitoring• Correlation IDs
1815 May 2015
Microservices Patterns• Fault tolerant, design for failure • Abstraction layer• One service at a time• Health Check• Stateless
1915 May 2015
Anti-Patterns
• Complex configuration• Complicated dependencies• Managed shared state
2015 May 2015
MicroservicesThings to remember• Prepare for failure– Fail fast and cheap
• Every integration point will eventually fail in some way, and you need to be prepared for that failure.
• Do defensive programming– Defend with timeouts– Defend from thread deadlocks– Defend from resources bottleneck
• Be lazy for programming,• Do not rely in others code• Communicate – Commits and early integration is the best way to communicate
• Stress interfaces• Slow responses are not an option
2115 May 2015
• Keep in mind the SLAs and strict performance requirements• Use data replication and sharding• Put limits– Pagination, timeouts, big request, etc
• Use queues and asynchronous for those flows that allow it• Verify integration point early• Use health checks• Avoid mocks• Learn, learn and learn
MicroservicesThings to remember
2215 May 2015
MicroservicesThings to remember
2315 May 2015
Componentization via REST Services
REST Services
• REST has no hard and fast rules• REST is an architectural style, not a standard• REST uses Headers to describe requests & responses • REST embraces HTTP verbs
2515 May 2015
Status codes
• 1xx: informational • 2xx: success • 3xx: redirection • 4xx: client error • 5xx: server error
2615 May 2015
REST Practices*
• Good HTTP Headers• Idempotent• Link and navigational• JSON
• *For VCS poject
2715 May 2015
How to build a REST service
1
2
3
4
• Create REST Controller
• Annotate with Request Mapping
• Build the response
• Deploy REST Service
2815 May 2015
Demo
• Hello REST Service• Monitoring Services• Unit Test for REST Services
2915 May 2015
Resources
• OPEN DATA CENTER ALLIANCE Best Practices: Architecting Cloud-Aware Applications Rev. 1.0
• http://www.infoq.com/presentations/Netflix-Architecture• http://martinfowler.com/articles/microservices.html• Release It!: Design and Deploy Production-Ready Software Book• https://spring.io/guides/gs/rest-service/• https://www.youtube.com/watch?v=wgdBVIX9ifA
3015 May 2015
Questions?Thank you!