There are some important Principles of microservices(defining microservices).
https://www.youtube.com/watch?v=wgdBVIX9ifA – Martin Fowler
Whom to call a microservice –
Component Design – Libraries and Services.
Organised around the BUSINESS Capabilities and not the technologies. These teams should be directly responsible right upto the end user experience.
Having their own DATA boundaries. Every service should have their own database.Even SOA had different services but the same DB source. Doing this will separate schema and make them free to choose the data source they see correct.
They should have smart endpoints, unlike the ESB.
Monitoring is a must in order to cope up with service failures.
Infrastructure Automation is needed since there can be multiple types of systems that the services can interact with or created with. Continuous Devlivery etc are mandatory.
Build for failure. The remote service will fail. Similar to Netflix which makes it resilient.
Multiple versions acceptable. Self – monitoring. Loosely Coupled
Team size: Pizza sized teams.
– When to use & what are the advantages.
The microservices preserve modularity but make refactoring difficult.
Partial Deployment can be easily achieved in Microservices unlike monolith applications.
They are highly available but lack consistency.
They are platform independent.
– Must have if you are adopting microservices.
Rapid Provisioning of resources
Have DevOps Culture
Challenges in Implementing Microservices:
The need of microservices – To Go Faster.
The organizations and startups want to move faster and with so many tools available today, like Docker, Cassandra, NoSql and terminologies and culture shift like MVP, Cloud, DevOps, these contribute in creating a pattern of development that helps move things faster and increase the rate of development.
There are different types of problems and there is a lot of competition in the market.
Challenge 1.Deconstructing the database.
-Fortune 100 eg- Entity oriented, consistency essential.
As per Microservices: Event Buses to be used to replace operational databases.
DB per microservice if persistence is required. Multiple options for FBs
Few, writeable or transactional.
Rapids, Rivers and Ponds:
Rapids – Every Event. (Every message at every place – even the logs) in the same stream of information. Traffic stats, Service Stats.
Rivers – Themed Events : Reports etc.
Ponds – State/History, Events or Entities
This requires a high performance event bus. KAFKA. bus behind LinkedIn
250000 msgs per sec. It is a dumb bus. Also matters how many things we attach in the bus, which will decrease the number of events required.
We can attach certain message and then other messages for the rivers and use RabbitMQ.
We then attach the services to these events.
Handing Of messages to services based on corresponding traits.
We listen to a river but we always publish it to the rapids.
People might not see it if we push it to Rivers.
This helps us to build incremental applications.
a) There are event publishers and Solution Collectors. These communicate the event and get the response or solution of the event. Redis will serve as the db and cache it.
Challenge 2: Synchronous vs Asynchronous
Sync service – Turning module into services and calling them restfully.
Async – gives robustness, A/B testing can be done
Need Async Pattern : Need and Solution and working with the event bus.
Multiple Service Taxonomy depending on the client – timeout, web sockets, batch jobs. The processes can be of type – Soltion services, solution blockers, Client Biases, Enrichment Services.
And above all, everything is getting logged along with monitoring and KPIs
Chalenge 3 – Microservices or Clojure (Functional Programming)-
Microservices are like OO. Has its own persistence.
Closures – They love shared data and can only make new data can change old one. Eg. The UI of DailyMail from 130000 lines of Java to 4000 lines of closure. They have a big json structure of the page and it creates the html structure of the page. These are not reqd to make as a services.
a) Ruby – frontend, Node for monitoring, Closure – heavy lifting and monitoring. Analysis with R.
Coupling – DB, Rest, Kafka
b) DailyMail :
Clojure – 3 services.
Node.js – dozens of node js(with avg size of 14 lines of code)
c) Outpace : Clojure – 25
Solution : Elixir – Functional programming languages built on Erlanf VM.
Challenge 4- Choosing Architectures and Frameworks: Too early to tell
Netflix frameworks. Pigato (based on ZeroMQ),
Challenge 5 – No Design Patterns yet.
Challenge 6 – Corequisite Technology, Processes, Organization structure. Dev Ops concepts, Mangerless processes.
Microservices – Implementations
Scale to millions of users.
Complex business rules.
Innovate fast and respond to competitions.
How they do it – Autonomous full-stack teams.
spotify.github.io/apollo/ – writing services that focus on composability, simplicity, High performance, modern Java Idioms and features.
Pain Points of microservices – documentation. Harder to monitor.
Create increased latency since all the services are calling other services – View Aggregation services to solve that. (Idea from Netflix)
Next generation monitoring platform – atlas architecture and need.
protobuf – binary serialization formats. Image sizes, prefetch requests. close tcp connections (keep-alive is kept on) https://www.youtube.com/watch?v=ucK4FL0KKB4
UI Engineering – https://plus.google.com/+NetflixUIEngineering