Java Microservices in the cloud Doug Harvey Cap

Java Microservices in the cloud Doug Harvey Cap. Tech Consulting

“a crummy commercial? ” Cap. Tech is a national consulting firm with offices in Philadelphia, Washington, Richmond, Charlotte, Atlanta, Denver, Orlando… Cap. Tech has a Java practice that goes back to 1998 Cap. Tech specializes in System Integration and development

Fad or Trend? Applets Spring EJB’s REST Swing Google Glass Javascript Microservices?

Not a fad imho Synergy the design pattern itself open-source contributors containers cloud

Why Microservices?

Problems with the monolith Granular Tuning Regression Testing Developer Interaction Database dependencies

Advantages of the monolith Reporting Batch processing Transaction Management Logging

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

Characteristics of a Microservice

Persistence

Definitions Component - a self-contained, separatelydeployable 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

Framework vs Component Framework – library (jar) Component – executable Choice is sometimes not so obvious Rules engine? I 8 N? Configuration?

Anatomy of a Microservice

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

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

Containers What is a container? Why use containers? Which containers to use? Docker, Rocket, Drawbridge, LXD, other

Why use containers? Isolation file system ports support software dependencies Scalability Developer productivity (run dependencies locally)

Caching Microservices = increased network traffic Caching avoids redundant calls Distributed caching Products: Redis, Hazlecast, etc. Building with Caching transparency

What about those monolith advantages? Reporting/Batch Processing - Elastic Search (or other shadow database) Logging - Logstash & Kibana Transactions…

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 )

What about security? Options: shared session (is he kidding? ) client certs custom token (signed, self-contained) Oath 2 (most likely - supports SSO)

What is needed? API Gateway Service Discovery Load balancing Integrated REST client Circuit Breaker

How do we do all this in Java? Roll-your-own? Container or container-less? Open-source frameworks? Spring? boot, cloud (netflix) Dropwizard? Vertx

Why Spring Boot? Momentum no more container dependencies less Mockito-style mocking provides robust, extensible monitoring memory is cheap Spring Cloud - powerful annotations

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

Eureka DNS for components Contributes to load-balancing Does proactive monitoring (health checks) Not java-specific Spring supports via annotations

Ribbon Client-side load balancing Integration with Eureka Circuit-breaker integration

Feign Abstracts calling to REST endpoints Uses Ribbon for load blanking Spring annotations Example:

Daring Code Demo

Zuul Allows for one “front door” for consumers Consumers don’t need to find services Allows for one authentication endpoint

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, Rx. Java) Includes monitoring dashboard for view of health of components

Rx. Java 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

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

Anatomy - Java Detail

What about testing? Less need for mocking Contract testing is important Component testing is important Unit testing need is still the same

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)

Cloud Principle #1 Write no code that depends upon a particular cloud provider

Cloud Principle #2 Do take advantage of the monitoring and deployment facilities of your cloud provider

Example: Amazon EC 2 Container Service (ECS) Cluster – logical group of containers Container instance – EC 2 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

Service. Discovery on ECS

Conclusion Think differently: “the services are the application” Leverage open-source containers are your friend