Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: ruclips.net/channel/UCs_tLP3AiwYKwdUHpltJPuAjoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
Things I learned from this talk: - microservice ops requires a lot of good quality tooling - adoption of microservices requires big/gradual change towards teams fully responsible for their own services - must do destructive testing in production env to really understand resilience of system
Your second point has been there since the beginning of the DevOps trend started. "You build it, you run it." was a quote from Werner Vogels of Amazon, and Jezz Humble has repeated it often. For some reason, the world focused on CI/CD pipelines as the most important idea, but arguably the most important idea of DevOps is "you build it, you run it."
Very useful insights and lessons learned, too often case studies show just how quick and easy it is which makes you think you're taking too long. Very honest and reassuring! Thank you.
I like their way of learning from nature and putting it to software development cycle. Great Stuff and Great evolutionary thought. It's sure nothing work for ever , it evolves and as per need , the architecture need to evolve, to do business.
Great video. One thing that confused my mind is that he stated that RDBMS in the previous infrastructure was single point of failure. Imo, as long as you don't replicate the data somewhere else (and sometimes even that's not enough) or cache the entire data storage, the data storage will always will be single point of failure. What did change in new architecture so that it's not single point of failure now?? If it's about each and every microservices can use it's own data storage principle, lets assume that's true. As long as you didn't abstract the environment these microservices work on, they most probably will use the same DB Servers, DB Engines etc. What then? As long as your db server is not lightweight (and I mean VERY lightweight), you cannot install a new db engine for each microservices (can you imagine installing 100 SQLServer instances..) What I mean is solving single point of failure in data storage aspect does not seem very suitable for me in real world. Theoretically possible though..
Hi, They now use Cassandra (a noSQL DB engine), instead of a RDMBS... From my understanding, Casandra is, by design, a massively distributed and replicated database : docs.datastax.com/en/cassandra/2.1/cassandra/architecture/architectureDataDistributeAbout_c.html => For instance, in the following 2014 blog post, they talk about 285 cluster nodes : techblog.netflix.com/2014/07/revisiting-1-million-writes-per-second.html Regarding single point of failure, that's the main différence with a traditionnal RDBMS. Cheers.
As soon as you allow yourself to adopt BASE principles rather than ACID principles, *lots* of things become possible for availability purposes in the back end.
Looking for books & other references mentioned in this video?
Check out the video description for all the links!
Want early access to videos & exclusive perks?
Join our channel membership today: ruclips.net/channel/UCs_tLP3AiwYKwdUHpltJPuAjoin
Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
Things I learned from this talk:
- microservice ops requires a lot of good quality tooling
- adoption of microservices requires big/gradual change towards teams fully responsible for their own services
- must do destructive testing in production env to really understand resilience of system
Your second point has been there since the beginning of the DevOps trend started. "You build it, you run it." was a quote from Werner Vogels of Amazon, and Jezz Humble has repeated it often. For some reason, the world focused on CI/CD pipelines as the most important idea, but arguably the most important idea of DevOps is "you build it, you run it."
Very useful insights and lessons learned, too often case studies show just how quick and easy it is which makes you think you're taking too long. Very honest and reassuring! Thank you.
Excellent presentation!
I like their way of learning from nature and putting it to software development cycle. Great Stuff and Great evolutionary thought. It's sure nothing work for ever , it evolves and as per need , the architecture need to evolve, to do business.
Nice video, but a small correction at the time 30:41 / 48:33: (0.99^500) * 100 = 0.657% (not 0.0657% as shown)
Practical insights - thanks!
Best talk !
Sweet visualizations
Great talk. Thank you
Loved it a-z!
This was quite informative. Very useful insights for implementing microservices
Great talk. Very insightful...
I saw a talk with the CTO of Deutsche Bank regarding microservices and I really cannot find, was it on GOTO or is my memory mistaken?
Great talk, very informative.
Very insightful!!
excellent stuff
Learned.. Thank You.. Awesome
Very insightful, thanks for posting!
Very informative! +1 for the Frank Underwood sticker on the speaker's laptop.
Hi, what is the software used to mix video and slides in this way that they are using on goto;?
We have an external video producer creating the videos for us. They are called GotFat: gotfat.dk
Great talk.
Mesmerizing in awesomeness. :)
From monolith to micro scervices, org change is the hardest part. Prove my intuition.
Great video. One thing that confused my mind is that he stated that RDBMS in the previous infrastructure was single point of failure. Imo, as long as you don't replicate the data somewhere else (and sometimes even that's not enough) or cache the entire data storage, the data storage will always will be single point of failure. What did change in new architecture so that it's not single point of failure now?? If it's about each and every microservices can use it's own data storage principle, lets assume that's true. As long as you didn't abstract the environment these microservices work on, they most probably will use the same DB Servers, DB Engines etc. What then? As long as your db server is not lightweight (and I mean VERY lightweight), you cannot install a new db engine for each microservices (can you imagine installing 100 SQLServer instances..)
What I mean is solving single point of failure in data storage aspect does not seem very suitable for me in real world. Theoretically possible though..
Hi,
They now use Cassandra (a noSQL DB engine), instead of a RDMBS...
From my understanding, Casandra is, by design, a massively distributed and replicated database :
docs.datastax.com/en/cassandra/2.1/cassandra/architecture/architectureDataDistributeAbout_c.html
=> For instance, in the following 2014 blog post, they talk about 285 cluster nodes : techblog.netflix.com/2014/07/revisiting-1-million-writes-per-second.html
Regarding single point of failure, that's the main différence with a traditionnal RDBMS.
Cheers.
As soon as you allow yourself to adopt BASE principles rather than ACID principles, *lots* of things become possible for availability purposes in the back end.
How do you make each team independent of other teams? often one team needs to use other team's service
Good stuff.
Sensacional!!!
I need that t-shirt aha
Ha yeah me too!
James Carr me too
19:20 is key
Very insightful. Thanks for sharing your experience. especially the parts about org changes.
I like this
Why is the video so dark?
Very true, most of failures happened during weekends. Lol
Hi there, if i multiple services that they work independently ( will they still be called microservice)?
43:22 architecting is not a single-person function. its a culture.
Triggering failures. Like fire drills with real fire. IT beating its old analogy of construction/building ...
2:31 over 500? pff come back to the talk when its over 9000 =P
Microservices are crazy, but if the salary good, you just dont give a dam.