1. SOA: Service Oriented Architecture
1.1. Services
1.1.1. are programs that run independently
1.1.2. communicate over a network
1.1.3. achieves some business logic
1.2. SOA
1.2.1. is designing your application to function as a collection of services
2. Solutions / Mitigations of Drawbacks
2.1. FOR (1) -- Combine microservices that constantly communicate
2.1.1. if they are too "chatty", combine them
2.2. FOR (1) -- HTTP can be replaced by messaging queues where appropriate (using Publisher/Subscriber pattern)
2.2.1. Rabbit
2.2.2. Kafka MQ's
2.3. FOR (2) -- Many ways to mitigate
2.3.1. shard
2.3.2. dbs
2.3.3. use stored caches (Redis)
2.3.4. etc.
2.4. FOR (3) -- Distributed logging and tracing tools
2.4.1. Spring Cloud Sleuth
2.4.2. Zipkin
2.5. FOR (4)
2.5.1. Docker for containerization
2.5.2. Kubernetes for "container orchestration"
2.5.3. Cloud providers for hardware
3. Netflix OSS MSA Tools
3.1. Eureka Server
3.1.1. Service Registry
3.2. Eureka Client
3.2.1. Discovery Client
3.2.1.1. registers with Eureka Server
3.3. Ribbon
3.3.1. Load Balancer
3.4. Zuul
3.4.1. Gateway
3.5. Feign
3.5.1. HTTP Client
3.5.1.1. Sends HTTP requests
4. MSA: MicroServices Architecture
4.1. is a subset of SOA,
4.2. where services must satisfy more condition: Microservices
4.2.1. MUST follow the Single Responsibility Principle
4.2.2. CANNOT be composed of other services
4.2.3. must achieve SCALABILITY and RESILIENCE through independence
5. "Typical" Enterprise SOA vs. MSA
5.1. Larger Services
5.1.1. Communicates with SOAP
5.1.1.1. Simple Object Access Protocol
5.1.1.1.1. Oracle Reference
5.1.1.1.2. Wikipedia Reference
5.1.1.2. communicates with rigid rules
5.1.1.3. each service's API follows a contract (the WSDL file)
5.1.1.3.1. W3C Reference
5.1.1.3.2. guru99 Reference
5.2. Smaller Services
5.2.1. Communicates with RESTful HTTP
5.2.1.1. RESTful APIs act on verbs
5.2.1.2. respond with Status codes
5.2.1.3. JSON in body of request / response
5.2.1.4. "Smart endpoints", "dumb pipes" (we'll come back here)
5.2.1.5. Typically uses Service registry and discovery to enable direct communication
5.2.1.5.1. Service Registry
6. Benefits of MSA
6.1. Loosely coupled Services
6.2. (Enforced) modularity
6.3. Fault-tolerant
6.3.1. no Single Point of Failure
6.4. Scalable
6.4.1. Independent services scale independently
6.5. Implementation agnostic
6.5.1. services can use different techs / languages
6.6. Testable
6.7. Organizational benefit
6.7.1. small teams working independently, managing separate services
7. Drawbacks of MSA
7.1. (1) NETWORK LATENCY!!!
7.1.1. "Chatty" microservices communicating too often
7.2. (2) Distributed data storage
7.2.1. we make tradeoffs and settle for eventual consistency
7.3. (3) Monitoring and logging
7.3.1. are more difficult over a network
7.4. (4) Deploying 100s of services
7.4.1. can be difficult
7.5. (5) Complexity / Refactoring
7.5.1. changes in few services are easier
7.5.2. changes across many are harder
8. Web Services
8.1. SOA – Service Oriented Architecture
8.1.1. Open Group: Intro to SOA
8.1.2. Service Oriented Ambiguity
8.1.3. Services are programs that run independently, achieve some business logic, and communicate over a network
8.1.4. Service Oriented Architecture involves designing your app as a collection of these services working together
8.2. MSA - MicroServices Architecture
8.2.1. Open Group's chapter on MSA
8.2.2. MSA is also a contentious subject, with multiple interpretations.
8.2.3. Microservice Architecture is a subset of SOA, satisfying a few more conditions:
8.2.3.1. Microservices MUST satisfy the Single Responsiibility Principle (SRP) -- they do only one thing and do it well
8.2.3.2. Microservices cannot be composed of multiple other services
8.2.3.3. Microservices achieve scalability and resilience through independence (we can easily take down or spin up instances of each service)
8.3. Comparison of typical enterprise SOA and typical MSA
8.3.1. Enterprise SOA has larger services that may have more than one responsibility
8.3.2. MSA has smaller services that satisfy SRP
8.3.3. Enterprise SOA communicates using SOAP, so each service has a WSDL for communicating with each other. Secure and rigid communication rules.
8.3.4. MSA communicates with HTTP and consists of RESTful services. "Smart endpoints, dumb pipes"
8.3.5. Enterprise SOA routes communication through a central bus
8.3.6. MSA uses service registries and discovery clients to allow communcation without centralized routing
9. MSA
9.1. Benefits of MSA (vs. Monolith)
9.1.1. Loosely coupled services
9.1.2. Modular
9.1.3. Fault tolerant (no Single Point of Failure)
9.1.4. Scalable : independent services easily horizontally scale, and we only scale the parts we need
9.1.5. Implementation agnostic : MS written in different languages and paradigms
9.1.6. Testable : test each service independently
9.1.7. Good for development in a large org : many small autonomous (agile, devops-y) teams maintain RESTful microservices
9.1.7.1. This is how FANG (Facebook, Amazon, Netflix, Google) does most development
9.2. Drawbacks of MSA
9.2.1. Network latency and the "chattiness" of microservices
9.2.2. Distributed data storage means we make tradeoffs and settle for "eventual" consistent data
9.2.3. Monitoring and tracing errors is more difficult across a network
9.2.4. Deploying 100s of services can be difficult
9.2.5. Complexity/Refactoring
9.2.5.1. changes that touch one or two microservices are easier
9.2.5.2. Changes that touch many microservices are much harder
9.3. Solutions/Mitigations of drawbacks
9.3.1. Chattiness reduced by following SRP and separation of concerns
9.3.1.1. If 2 microservices are constantly talking, refactor them to follow SRP
9.3.1.2. HTTP traffic can be reducing by replacing it with messaging queues (Rabbit, Kafka) when appropriate
9.3.2. Sharding databases, using shared caches, and other solutions exist for distributed storage, but they always involve tradeoffs
9.3.3. Spring Cloud Sleuth and Zipkin enable distributed logging and tracing
9.3.4. Docker, Kubernetes/Docker Swarm, and cloud platforms enable easier MSA deployment
9.3.5. Complexity mitigated by good design (a constant goal)
9.4. Netflix OSS for Microservices
9.4.1. Eureka Server
9.4.1.1. What it is
9.4.1.1.1. Service Registry
9.4.1.1.2. Microservices register their URI and status with Eureka
9.4.1.1.3. Provides failover
9.4.1.2. What it does
9.4.1.2.1. Enable by putting it on the classpath and using
9.4.1.2.2. By default hosts on port 8761 and has self-preservation behavior
9.4.2. Eureka Client
9.4.2.1. What it is
9.4.2.1.1. Discovery Client
9.4.2.1.2. Retrieves the registry from Eureka Server to locate multiple instances of any other service
9.4.2.2. What it does
9.4.2.2.1. Enable by putting it on the classpath and using
9.4.2.2.2. By default both registers with Eureka Server and retrieves the registry of other registered services
9.4.3. Ribbon
9.4.3.1. What it is
9.4.3.1.1. Load balancer
9.4.3.1.2. Any service running Ribbon will balance its outgoing traffic between instances of other services
9.4.3.2. What it does
9.4.3.2.1. Default is round-robin
9.4.3.2.2. Built into Eureka Client, no need to separately include
9.4.4. Zuul
9.4.4.1. What it is
9.4.4.1.1. Gateway
9.4.4.1.2. Allows external entities to access resources within the MS network, and filters traffic coming from outside.
9.4.4.2. What it does
9.4.4.2.1. Enable by putting it on the classpath and using
9.4.4.2.2. Configure routing in application.properties or application.yml
9.4.5. Hystrix
9.4.5.1. What it is
9.4.5.1.1. Circuit breaker
9.4.5.1.2. Provides immediate fallback response from failing microservices
9.4.5.1.3. used to prevent cascading failures
9.4.6. Feign
9.4.6.1. What it is
9.4.6.1.1. Http Client
9.4.6.1.2. Allows microservices to easily send HTTP requests to other microservices
9.4.6.2. What it does
9.4.6.2.1. Enable by putting OpenFeign on the classpath and using
9.4.6.2.2. To actually create a Feign Client (something that sends HTTP reqs)
9.5. Spring Cloud MSA tools
9.5.1. What it is
9.5.1.1. Config server
9.5.1.2. provides centralized and version controlled configuration for microservices
9.5.2. What it does
9.5.2.1. Enable by putting it on the classpath
9.5.2.1.1. using @EnableConfigServer
9.5.2.2. adding a git uri in application.properties
9.5.2.3. Spring REST and Spring Data
9.5.2.3.1. easily build a RESTful API
9.5.2.4. RabbitMQ
9.5.2.4.1. Messaging Queue
9.5.2.4.2. broadcast information to all listening microservices instead of sending many HTTP requests
10. SOA
10.1. SOAP w/HTTP
10.2. SOAP Message
10.3. WSDL
10.4. Jax-WS – Java API for XML Web Services
11. REST
11.1. 6 traits of REST
11.2. Rest Services
12. Virtual Machines
13. Docker
14. SOAP
14.1. “Expose” and “Consume” Web Services
14.2. Simple Object Access Protocol
14.3. Protocol for XML based communication across the Internet
14.4. Platform and language-independent
14.5. Similar
14.5.1. Corba
14.5.2. Dcom
14.5.3. Java RMI