Download presentation
Presentation is loading. Please wait.
1
Java Microservices in the cloud
Doug Harvey CapTech Consulting
2
“a crummy commercial?” CapTech is a national consulting firm with offices in Philadelphia, Washington, Richmond, Charlotte, Atlanta, Denver, Orlando… CapTech has a Java practice that goes back to 1998 CapTech specializes in System Integration and development
3
Fad or Trend? Applets Spring EJB’s REST Swing Google Glass Javascript
Microservices?
4
Not a fad imho Synergy the design pattern itself
open-source contributors containers cloud
5
Why Microservices?
6
Problems with the monolith
Granular Tuning Regression Testing Developer Interaction Database dependencies
7
Advantages of the monolith
Reporting Batch processing Transaction Management Logging
8
Microservices? Not the use of service objects, e.g. Domain-Driven Design One Operating System Process “Smart endpoints / dumb pipes” (therefore NOT ESB) Decentralized data management (purpose-specific persistence, usually per-component) Replaceable Component Architecture Change of mindset - services are the app
9
Characteristics of a Microservice
10
Persistence
11
Definitions Component - a self-contained, separately- deployable OS process Library - code that is shared among components (does not run on its own) API-gateway - a component whose main purpose is to orchestrate & aggregate by calling other components
12
Framework vs Component
Framework – library (jar) Component – executable Choice is sometimes not so obvious Rules engine? I8N? Configuration?
13
Anatomy of a Microservice
14
The 12-Factor App I. Codebase - One codebase tracked in revision control, many deploys II. Dependencies - Explicitly declare and isolate dependencies III. Config - Store config in the environment IV. Backing Services -Treat backing services as attached resources V. Build, release, run - Strictly separate build and run stages VI. Processes - Execute the app as one or more stateless processes VII. Port binding - Export services via port binding VIII. Concurrency - Scale out via the process model IX. Disposability - Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity - Keep development, staging, and production as similar as possible XI. Logs - Treat logs as event streams XII. Admin processes - Run admin/management tasks as one-off processes
15
Contracts Contracts are sacred Backward compatibility is paramount
Different versions must be able to co-exist Contract testing separate from other testing Tools available: Pact, Pacto
16
Containers What is a container? Why use containers?
Which containers to use? Docker, Rocket, Drawbridge, LXD, other
17
Why use containers? Isolation file system ports support software
dependencies Scalability Developer productivity (run dependencies locally)
18
Caching Microservices = increased network traffic
Caching avoids redundant calls Distributed caching Products: Redis, Hazlecast, etc. Building with Caching transparency
19
What about those monolith advantages?
Reporting/Batch Processing - Elastic Search (or other shadow database) Logging - Logstash & Kibana Transactions…
20
Transactions What if a “transaction” spans service calls?
This is not unique to micro services Design directions: Keep db transactions at individual service level Use alternate methods to restore consistency (CQRS, Event Sourcing, Eventual Consistency, Delayed Rollback )
21
What about security? Options: shared session (is he kidding?)
client certs custom token (signed, self-contained) Oath2 (most likely - supports SSO)
22
What is needed? API Gateway Service Discovery Load balancing
Integrated REST client Circuit Breaker
23
How do we do all this in Java?
Roll-your-own? Container or container-less? Open-source frameworks? Spring? boot, cloud (netflix) Dropwizard? Vertx
24
Why Spring Boot? Momentum no more container dependencies
less Mockito-style mocking provides robust, extensible monitoring memory is cheap Spring Cloud - powerful annotations
25
Netflix offers (via Spring Cloud)
Eureka - service registry Ribbon - load balancer (client side) Feign - rest client via configuration Zuul - reverse proxy/ API gateway Hystrix - circuit-breaker
26
Eureka DNS for components Contributes to load-balancing
Does proactive monitoring (health checks) Not java-specific Spring supports via annotations
27
Ribbon Client-side load balancing Integration with Eureka
Circuit-breaker integration
28
Feign Abstracts calling to REST endpoints
Uses Ribbon for load blanking Spring annotations Example:
29
Daring Code Demo
30
Zuul Allows for one “front door” for consumers
Consumers don’t need to find services Allows for one authentication endpoint
31
Hystrix Implements circuit-breaker pattern: once failures for a component instance reach a threshold, breaker trips - preventing further calls to that instance Integrates with other tools to allow declarative fallback when services fail or are not available (Feign, Ribbon, RxJava) Includes monitoring dashboard for view of health of components
32
RxJava What is it? Java implementation of Reactive Pattern
Use with other Netflix frameworks provides synergy Very useful in orchestrating several interdependent simultaneous or sequential REST service calls
33
Gradle vs Maven Gradle has some advantages in microservices world:
Groovy-based DSL instead of XML Supports Convention over Configuration like Maven, but allows for procedural “tasks” Excellent with sub-projects (like “client”) leveragable in deployment as well as build/dependency management
34
Anatomy - Java Detail
35
What about testing? Less need for mocking
Contract testing is important Component testing is important Unit testing need is still the same
36
What about the cloud? Most cloud providers now directly support Docker
A Docker container with one spring boot microservice can be a deployable asset stored in a repository (like Artifactory)
37
Cloud Principle #1 Write no code that depends upon a particular cloud provider
38
Cloud Principle #2 Do take advantage of the monitoring and deployment facilities of your cloud provider
39
Example: Amazon EC2 Container Service (ECS)
Cluster – logical group of containers Container instance – EC2 with ECS agent registered into a cluster Task Definitions – app description with one or more containers Task – an instantiation of a task definition running on a container instance Services – run and maintain a specified number of instances of a task definition simultaneously
40
ServiceDiscovery on ECS
41
Conclusion Think differently: “the services are the application”
Leverage open-source containers are your friend
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.