Microservices Architecture
Microservices Architecture pluralsight 
services
- services are stateless. No knowledge about previous requests is needed. All info about, customer, client type, previous interaction must be contained into the current request
- interface contracts and backward compatibility
Microservices
- small service with a single purpose
- lightweight communication mechanism, client/service to service
- technology agnostic API, open protocol (like http rest)
- has its own data storage
- independently changeable/deployable: no upgrade of a single service will affect any interaction within the system
- transactions are likely to be completed in a distributed fashion, by multiple pieces of software
- high cohesion: single responsibility principle and oop encapsulation, single thing done well.
- autonomous: a change in one microservice won’t force a change in another, loose coupling oop fulfillment.
- Honor contracts from one version to another, independently changeable & deployable.
- Async communication with events publishing, notify of completion.
- Focus on technology agnostic and not on client libraries.
- Fixed and agreed interfaces.
- Shared models, clear input and output.
- Avoid chatty services and sharing databases between services.
- versioning and ownership
- each teams owns and is reponsible to make autonomous, agree on contracts, maintain long term, communicate data and contract requirements.
- When breaking changes occur you could have concurrent versions, slowly negotiate migrations.
- Semantic versioning:
major.minor.patch. Patch increase on defect, minor increase if backward compatible, major increase if contract change.
- business domain centric: should represent a business function/domain.
- bounded context from ddd, identify boundaries or seams. Identify business domains in a coarse manner.
- responsive to business change. Review subgroups of business functions as areas, review benefits of splitting further. Fix incorrect boundaries by merging or splitting.
- resilience, embrace failure when it happens, degrading functionality or offering defaults. Many moving parts, we can’t have one bad downstream system influence the whole.
- Design must be done for known failures. Fail and recover fast, no impact for end user.
- Use timeouts for interconnected systems. Different thresholds for communication type, s2c or s2s.
- Handle network outages differently. Network errors/unavailability, internet delays.
- observable: quick deployment requires feedback. data used for planning and scaling. see system health.
- central monitoring: monitor cpu, host memory and disk usage in real time. expose some metrics: svc response times and timeouts, number of exceptions. you can expand to business data like no orders and average time from basket to timeout, collect and aggregate data, compare data across servers, trend visalisation and trigger alerts on some conditions.
Nagios/PRTG/Load balancers/New Relic. - central logging: log means info/story, monitor means collecting metrics. When to log: startup/shutdown, code path milestones. What: requests, responses and decisions, timeouts, exceptions. Structured logging: level, date and time, correlation id, service name and instance. Strongly typed model and traceable distributed transactions.
Elastic Log/Log stash/Splunk/Kibana/Graphite. Serilog pushes and raises events against the centralised monitoring tool.
- central monitoring: monitor cpu, host memory and disk usage in real time. expose some metrics: svc response times and timeouts, number of exceptions. you can expand to business data like no orders and average time from basket to timeout, collect and aggregate data, compare data across servers, trend visalisation and trigger alerts on some conditions.
- automation: manual regression testing, integration feedback on check-in. CI/CD. Each microservice with its own CI build. CD with central control panel and VS integration.
monolith
- all modules packed together, no division, tightly coupled, intertwined
- keeps growing as long as you add app functionality, no restriction in size
- scaling implies duplication of the whole
| Typical eCommerce | |
|---|---|
| monolith | |
| microservice |
Microservices technology
Sync or async? Both. RPC: distributed client server programs. vs Open protocols like REST/JSON, or Stomp? ATOM uses http to propagate events. message queuing protocol for async, decouples service and client, also publisher and subscriber since it’s event based. Queue is another point of failure.
Virtualization: PAAS with Azure/AWS/vSphere/Google Cloud. Containers: Docker/Rocker/Glassware. Do not run an entire OS, just minimal. Single service per container. Registry and discovery: host, port and version go to a svc registry db. Register on startup, deregister svc on failure, makes it self heal. Third party registration: man in he middle detects new instances and adds them to the svc registration database. Client side discovery: clients connect directly to that db or Server side discovery: a gateway or load balancer does the svc reg db queries. Scaling. How to scale up? Either create multiple instances of the same or add resources to existing. If cloud then PAAS handles automated or on demand scaling options. API gateway: single point of entry into the SOA, manages caching and load balancing. Single interface to many services, routes to dynamic locations, may handle security or delegate to some security service or have some sort of security at each service level.
Design
| Brownfield | Greenfield | |
|---|---|---|
| Meaning | Migrate existing system, likely monolithic, lacks microservices design principles | Build from scratch |
| Approach | Identify seams, separation that reflect domains. Start modularising domains and move code incrementally. Tidy up a section per release. Existing functionality needs to remain intact. Run unit/integration tests to validate change. Keep reviewing and identify bounded contexts | System boundaries will evolve. Start off with a monolith, develop areas into modules. Refine and refactor, split further when required. Promote shared libraries to a service. Review microservice principles at each stage. |
| Code Migration | Code organized into bounded contexts, Have clear interfaces between each. Code for each business domain is in one place. Start off with one, switchable, prioritize by risk/least dependency, incremental. | |
| Database migration | Avoid shared databases. Relate tables to code seams. Tables that link across seams: API calls that can fetch data for a relationship. Data referential integrity: api call instead of sql cascade. | |
| Transactions | Complex if spanning multiple microservices. Example: Orders-Promotions-Accounts-Products + TransactionManager. Fail options: try again (cache it), abort (create undo transaction) TransactionManager software: delay, two phase commit, potential bottleneck. Distributed transaction compatibility: notify monolith of completion. | |
| Reporting | No central database. Joins? Data pumps and a specialized ReportingService. Consolidation environment with a nightly job. |