The cuss words are sensible because they express the importance of a particular point, and it also serves as a grabber for those who are disconnected and swayed into their phone. Nice talk overall. Thumbs up.
It is a good presentation about Microservices Anti-Patterns: I would like to highlight about one of the Solution described in this presentation is that Correlation ID should be tracked for each service request. It is really awesome solution design pattern which shall be implemented not only in Microservices and also other Web Services- Such as REST/SOAP etc. Especially to investigate the production issue , where your server log is huge and to go through server log and trace the issue based on timings or other customer identity parameters are really painful job. During such kind of scenarios, if the (Microservices/REST/SOAP/any services) has been implemented with Correlation ID then it would be easy to find root cause of the issue by Application support team based on file grep approach.
Pretty good talk... but there's a pretty big anti-pattern in this talk of anti-patterns: If you're building microservices, you shouldn't be sharing your database.. Each service should have their own database. I have seen at least three companies make this mistake, and it always leads to versioning hell (just as is mentioned in the presentation), and it has a fairly simple solution. Just give them their own instance. Better separation of concerns, and keeps service containment. Want to move just one microservice to Digital Ocean, and keep the rest on AWS? No big deal. Just move that database and service, and set up your pipes. No crazy cross-datacenter DB calls. Et al.
Service A - Handles/process containers with a schema that stores lists of elements with only a schema indentifier. Service A than can indentifie that a list of elements should be processed by "Service B". And thus can be handled by the "Service B" part of the code that is from a different repostitory/project.
Erlang people have been doing microservices for ages so they have many tricks up their sleeve. I suggest people take a look at distributed patterns like the circuit breaker pattern and the safety valve pattern. What saddens me is that you guys haven't looked at the idea of a protocol contract like in UBF (fsm + types).
reinventing the wheel with soa and a service bus analogous to service bus throttling and jms queue or rabbit mq. I think the industry just want cheaper stuff. I like the idea of using what tool gives best value
Tammer, how does a database gateway work when you have different Microservices that might use foreign keys (for example, a user id) and how does a gateway scale when you keep adding more and more Microservices with their own data requirements? Thanks in advance.
Microservices are simple. Think of how the internet works. Think of how your application might integrate with facebook ( via a public api ). There is no concern of the underlying datastore because REST over http is the perfect abstraction layer. Simply build you services as if you were building a bunch of mini sites. i.e. If you need a users service. Think about how you would build a startup that provides simple OAuth to the world, or any other auth mechanism. If you want search functionality, think about how you would build a simple search page to search for that data, and for user loggins, just think of that happening magically thanks to the OAuth service ( which would be similar to the way you would have integrated with facebook, or youtube, or anything ). Just think like the internet.
One thing I can't really understand is; starting from the point that microservices should be independent and keep working normally even if one of its mate is offline, why would I create someone in the middle like the Circuit Breaker and every call go through it? I mean, what if the circuit breaker or even the Discovery Service's server go offline? Than my whole application is dommed. Is that really it?
The circuit breaker and the service discovery providers should be highly available and fault tolerant as well. He didn't mention it but usually the circuit breaker will follow a policy like: ping the service, if no response wait 100ms and ping again, if still no response report the service as down for any other requests, restart the service and repeat the process.
The circuit breaker could sit in your application itself ( like using Netflix Hystrix, resilience4j ). netflixtechblog.com/making-the-netflix-api-more-resilient-a8ec62159c2d But the Discovery service should be high available in any case.
Opeartions people are probably gonna quit xD One deployment hell is to maintain multiple set of technologies. I had one time someone explain me to they wrote a NodeJS Service because "Why not" :|
Let me just talk faster because I only have 3 minutes left. Because if people didn't understand WTF I was talking about they're definitely going to be lost with this. LaMeR
I was hoping for some kind Principles and Laws those are something like SOLID, but it is all like, Don't Eat Bananas it will disturb your Stomach but it could improve your Potassium Deficiency.
The presentation here is informative but I feel the coarse language used is off-putting for a professional presentation. I hope the presenter will realize this distracts from his valuable message.
![30 ชั่วโมงคนเดียว บนรถไฟชั้น 3 โซเวียต [Around The World Ep. 2]](http://i.ytimg.com/vi/MlE9boAVqDA/mqdefault.jpg)
The cuss words are sensible because they express the importance of a particular point, and it also serves as a grabber for those who are disconnected and swayed into their phone. Nice talk overall. Thumbs up.
It is a good presentation about Microservices Anti-Patterns:
I would like to highlight about one of the Solution described in this presentation is that Correlation ID should be tracked for each service request. It is really awesome solution design pattern which shall be implemented not only in Microservices and also other Web Services- Such as REST/SOAP etc.
Especially to investigate the production issue , where your server log is huge and to go through server log and trace the issue based on timings or other customer identity parameters are really painful job. During such kind of scenarios, if the (Microservices/REST/SOAP/any services) has been implemented with Correlation ID then it would be easy to find root cause of the issue by Application support team based on file grep approach.
And there should be some log aggregator in place.
Pretty good talk... but there's a pretty big anti-pattern in this talk of anti-patterns: If you're building microservices, you shouldn't be sharing your database.. Each service should have their own database. I have seen at least three companies make this mistake, and it always leads to versioning hell (just as is mentioned in the presentation), and it has a fairly simple solution. Just give them their own instance. Better separation of concerns, and keeps service containment. Want to move just one microservice to Digital Ocean, and keep the rest on AWS? No big deal. Just move that database and service, and set up your pipes. No crazy cross-datacenter DB calls. Et al.
Service A - Handles/process containers with a schema that stores lists of elements with only a schema indentifier. Service A than can indentifie that a list of elements should be processed by "Service B". And thus can be handled by the "Service B" part of the code that is from a different repostitory/project.
Watched on 6th October, 2021 - Thanks for the video.
Erlang people have been doing microservices for ages so they have many tricks up their sleeve. I suggest people take a look at distributed patterns like the circuit breaker pattern and the safety valve pattern.
What saddens me is that you guys haven't looked at the idea of a protocol contract like in UBF (fsm + types).
reinventing the wheel with soa and a service bus analogous to service bus throttling and jms queue or rabbit mq. I think the industry just want cheaper stuff.
I like the idea of using what tool gives best value
Tammer, how does a database gateway work when you have different Microservices that might use foreign keys (for example, a user id) and how does a gateway scale when you keep adding more and more Microservices with their own data requirements? Thanks in advance.
Microservices are simple. Think of how the internet works. Think of how your application might integrate with facebook ( via a public api ). There is no concern of the underlying datastore because REST over http is the perfect abstraction layer. Simply build you services as if you were building a bunch of mini sites. i.e. If you need a users service. Think about how you would build a startup that provides simple OAuth to the world, or any other auth mechanism.
If you want search functionality, think about how you would build a simple search page to search for that data, and for user loggins, just think of that happening magically thanks to the OAuth service ( which would be similar to the way you would have integrated with facebook, or youtube, or anything ).
Just think like the internet.
Nice way to put it, thanks
where to find the instagram article paper about grow?
Googled it.. found nothing. Help me too if you find the link.
I think this is that article
engineering.instagram.com/handling-growth-with-postgres-5-tips-from-instagram-d5d7e7ffdfcb
One thing I can't really understand is; starting from the point that microservices should be independent and keep working normally even if one of its mate is offline, why would I create someone in the middle like the Circuit Breaker and every call go through it? I mean, what if the circuit breaker or even the Discovery Service's server go offline? Than my whole application is dommed.
Is that really it?
The circuit breaker and the service discovery providers should be highly available and fault tolerant as well. He didn't mention it but usually the circuit breaker will follow a policy like: ping the service, if no response wait 100ms and ping again, if still no response report the service as down for any other requests, restart the service and repeat the process.
The circuit breaker could sit in your application itself ( like using Netflix Hystrix, resilience4j ). netflixtechblog.com/making-the-netflix-api-more-resilient-a8ec62159c2d
But the Discovery service should be high available in any case.
There must be something that would survive all the others, for the whole system to work.
안녕하세요
나와 관련있는지 확인부탁드립니다.그리고 관련이 있다면 어떻게 해결해야 하나요?
Erlang + OTP is the solution to most of these problems.
Can you elaborate more on what those are? Still learning and would love to know
Good content, Although your intro sound is not HeadPhone friendly :(
Good talk, but the guy reminds me of a technical Russ Hanneman
What was the bashing of Twitter at the beginning about?
I think he actually bashed himself for not being smart enough to identify Twitter as the incredibly successful idea it proved to be.
Twitter fucking still sucks
very nice presentation
Opeartions people are probably gonna quit xD
One deployment hell is to maintain multiple set of technologies.
I had one time someone explain me to they wrote a NodeJS Service because "Why not" :|
As long as all are packed in containers, DevOps just care about how to keep track and move them around, not much bother for their content.
Let me just talk faster because I only have 3 minutes left. Because if people didn't understand WTF I was talking about they're definitely going to be lost with this. LaMeR
I was hoping for some kind Principles and Laws those are something like SOLID, but it is all like, Don't Eat Bananas it will disturb your Stomach but it could improve your Potassium Deficiency.
Most are the act of balancing. Should know your rope.
Oh no he reads the slides
The presentation here is informative but I feel the coarse language used is off-putting for a professional presentation. I hope the presenter will realize this distracts from his valuable message.
+ketchup1001 Yes really. Keep public talks G+ so we can show these things in schools.
Where's GOOG AutoBleep when you need it? :-/
You are right, this just sounds unprofessional.
Lmao grow a fucking pair you pussy
shit goes on fire, babies die :)
Wrong as your presentation ?
(y) msilva