Monolithic Microservice
Scaled by adding and replicating the full package/call Each micro service can be replicated into different nodes
across multiple nodes and depending on load nodes can be added
Small change needs entire monolith to be rebuilt One service can be upgraded
puts all functionality into a single process Each element of functionality into a different service
Scale by replicating monolith on multiple servers Scale by distributing services across server and replicating
the service as per need / load
Middle ware contains business logic --- smart pipes Smart End points – Dumb pipes.. All logics at End Points
dumb end points .. ESB Endpoints apply logic,, transmitted using API / RESTful
Change is done and handed over to Maintenance team Team own the product for lifetime. You build, you run it
Libraries exported and syntaxes to understand libraries Out of process call, no specified syntax , goes as a web
are used; upgrade complete library service call.
Ex : app1 on java8 and not app2. ???? Ex: app1 as service and app2 as service with 2 different
java
Customization in languages to be used, option of services
to be called, De centralization of Data, tools chosen
One query fetches from multiple tables / schemas One process for one output/one query each service will
Multiple services pulling data from one large DB not interact with another service data store except
through API
In failure : whole request will fail One of 10 service may fail and need to be handled,
monitoring is mandatory
Component / service : a unit that can be replaced / upgraded independently
Enterprise Service Bus:
Routes messages, applies logic, parses into required formats
Automated integration and deployments to environments: Continuous delivery / integration is required since services
change continuously
Cloud is all about redundancy, fault tolerance and uptime.
Best Cloud architecture where individual components can fail without affecting the availability of the entire system
Use below techniques for introducing errors / scenarios to understand the resilience of system.
Chaos Monkey / Simian Army
Chaos Monkey
random selection of instances in the production environment and deliberately put them out of service.
Chaos Gorilla
At the very top of the Simian Army hierarchy, Chaos Gorilla, drops a full Amazon Availability Zone.[9]
Latency Monkey
Introduces communication delays to simulate degradation or outages in a network.
Doctor Monkey
Performs health checks, monitoring performance metrics like CPU load to detect unhealthy instances for root-cause
analysis and eventual fixing or retirement.
Janitor Monkey
Identifies and disposes unused resources to avoid waste and clutter.
Conformity Monkey
Tool that determines whether an instance is nonconforming by applying a set of rules on it. If any of the rules
determines that the instance is not conforming, the monkey sends an email notification to the owner of the instance.
Security Monkey
Derived from Conformity Monkey, a tool that searches for and disables instances that have known vulnerabilities or
improper configurations.
10-18 Monkey
Tool that detects problems with localization (l10n-i18n) for software serving customers across different geographic
regions.