Design Microservice Architectures the Right Way

  Переглядів 701,968

InfoQ

InfoQ

День тому

InfoQ Dev Summit Boston, a two-day conference of actionable advice from senior software developers hosted by InfoQ, will take place on June 24-25, 2024 Boston, Massachusetts.
Deep-dive into 20+ talks from senior software developers over 2 days with parallel breakout sessions. Clarify your immediate dev priorities and get practical advice to make development decisions easier and less risky.
Register now: bit.ly/47tNEWv
----------------------------------------------------------------------------------------------------------------
Download the slides & audio at InfoQ: bit.ly/2ypNF04
Michael Bryzek highlights specific key decisions that very directly impact the quality and maintainability of a microservice architecture, covering infrastructure, continuous deployment, communication, event streaming, language choice and more, all to ensure that teams and systems remain productive and scale.
This presentation was recorded at QCon London 2018: bit.ly/2hxsoN1
The next QCon is in San Francisco, Nov 5-7, 2018. Check out the tracks and speakers: bit.ly/2uYyHLb. Save $100 by using the discount code “INFOQSF18”
For more awesome presentations on innovator and early adopter topics check InfoQ’s selection of talks from conferences worldwide bit.ly/2tm9loz
Interested in Software Architecture? Follow the topic on InfoQ: bit.ly/2NmIOpa
#Microservices #ContinuousDeployment # ContinuousDelivery #InfoQ #QCon #QConNewYork

КОМЕНТАРІ: 282
@dhiresh5980
@dhiresh5980 4 роки тому
One of the things I learnt in this video: Code generation can be used to set strict standards across the systems
@zhou7yuan
@zhou7yuan 3 роки тому
A personal story (change API URL) [0:13] How does this happen? [0:38] Great Architecture [1:10] Not So Great Architecture [1:55] Design Microservice Architectures the Right Way [2:29] About Me [2:45] Let's Start With a few Misconceptions [3:37] M#1 teams to choose language [3:40] (expensive) M#2 code generation is evil [4:32] (just a tech) M#3 event log must be the source of truth [4:55] (ok to record service own record) M#4
@commonsense9438
@commonsense9438 3 роки тому
holy shit
@xskrish
@xskrish 2 роки тому
you're a god
@blackerhawk1508
@blackerhawk1508 2 роки тому
This is awesome
@D13willcometoyou
@D13willcometoyou 2 роки тому
Of course it's not a UKposts comment section without heroes who put timestamp for sections
@biplobmanna
@biplobmanna 2 роки тому
I know this comment is 4 years too late, but the sheer volume of things I've learnt from this talk tops all the videos/tuts I've watched regarding microservices without debate.
@YouToYoub
@YouToYoub 5 років тому
This the best presentation I have watched my entire professional life of 22 years. And the best of the 85 videos I have watched on microservices.
@mbryzek
@mbryzek 5 років тому
Thank you! Really appreciate your note
@jonnytheponny5753
@jonnytheponny5753 4 роки тому
Thanks for your comment. I was only 3 min into the presentation and about to leave, as I already had seen so many Microservice presentations. But I thought first lets look at the comments. And you are so right, thanks very much!
@jamesmcmurtry5351
@jamesmcmurtry5351 3 роки тому
@@mbryzek I have to second eJay's comment. This answered so many decision questions on utilizing microservices along with event driven architecture in examples of real world success. There are too many talks with buzzwords and not enough practical information on implementation. A great question you answered was using individual databases per microservice that is subscribing/publishing to an event. The "source of truth" narrative has been a bit ambiguous with regards to the rules of using other DBs.
@mbryzek
@mbryzek 3 роки тому
@@jamesmcmurtry5351 Thanks James - Really appreciate your comment!
@bobchemist
@bobchemist 2 роки тому
@@mbryzek Great talk. A good followup would be on the optimal microservice network for various use cases.
@akinniyiakinyemi2737
@akinniyiakinyemi2737 3 роки тому
I've watched a lot of videos on microservices. This is by far the most sensible, brilliant and cohesive explanation of all! Should be made into a textbook tbh
@jaikantchandrakumaran3423
@jaikantchandrakumaran3423 3 роки тому
I loved this talk, not because it is the gold standard but because Michael knows what he is speaking and has taken the efforts to setup the standardisation in every step of the process.
@devrkd
@devrkd 3 роки тому
In the entire presentation most of time, it not slides with some block diagrams but real code examples. I really enjoy that. Creating/ investing into such discipline to standardise stuff, you got my respect man.And indeed the code was really beautiful.
@attilaviniczai7215
@attilaviniczai7215 4 роки тому
Great software design material! It not only covers microservices, but also the devops operations associated to deliver quality software.
@KelvinMeeks
@KelvinMeeks 5 років тому
Excellent talk - in particular, note the advice @24:25 - adopting a microservices strategy requires Continuous Deployment
@KAUSHIKAKALI
@KAUSHIKAKALI 3 роки тому
This is the most practical presentation on the quote "Talk is cheap. Show me the code". Finally found something practical otherwise those theoretical rhetoric.
@GamerMinecraftivity
@GamerMinecraftivity Рік тому
It's funny, I keep coming back to this video after studying up on microservices and understanding more and more of why these are good design principles. Great video
@garygreen8699
@garygreen8699 2 роки тому
Amazing architecture story. One of the best tech presentations I've ever seen.
@peterbodifee
@peterbodifee 3 роки тому
This was an excellent talk (thank you Michael) and he is the living example of how to execute on the principle "if you need to do something more than once, you need to automate." Automation is so much more predictable then humans ;-)
@wenhoujx
@wenhoujx 5 місяців тому
i watch this video again every year, and every time i learn something new. such a treasure trove. Would love to work with Michael someday, he seems an awesome engineer and an emphatic learder.
@musicandoutdoors
@musicandoutdoors 5 років тому
The way I view this talk is as a representation of the “perfect workflow” for microservices. In my small startup, most of it is “good to know” but I can see adopting things more and more as we grow. Particularly helpful for me was understanding the journaling event publishing aspect. The code generation stuff is mind blowing - I would not have thought to automate that much. I wonder how long it took to set that stuff up before they even shipped any product. Yes, now they probably develop lightning fast, but this would be a huge distraction from finding product market fit.
@mbryzek
@mbryzek 5 років тому
most of our code gen started with a 2-4 hour "hack" that was sufficient to solve the use case at hand; then we built on that to add features over time. We did this as a startup - definitely doable!
@volshebnikozz
@volshebnikozz 5 років тому
I haven't used it, but you can take a look into Atomist: docs.atomist.com/ they're doing something similar
@Hex72
@Hex72 4 роки тому
@Robin Chan I was thinking the same. What if the generated code needs to change? Are all your manual changes and implementations lost?
@hibas1235
@hibas1235 4 роки тому
@@Hex72 I would say there should be no manual editing in the generated code. When I build a code generator it always produces interfaces or abstract classes where actual manual work is required. Everything else like Parsers etc. Should not be touched by anyone except the code generator itself.
@Hex72
@Hex72 4 роки тому
@@hibas1235 That would make the most sense, yeah.
@dmoscrop
@dmoscrop 4 роки тому
Wow, we've basically built this exact thing over the last few years. It's nice to see this kind of validation.
@dhanyajayachandra8645
@dhanyajayachandra8645 3 роки тому
I could like this a million times over. The best presentation on Microservices.
@giulioambrogi5413
@giulioambrogi5413 3 роки тому
So much content in such a short time, great presentation.
@anandbgrowthcoach
@anandbgrowthcoach 3 роки тому
One of the most amazing talks about Microservices Architecture - You guys are geniuses and thanks for sharing all that knowledge!
@1173mrwan
@1173mrwan 4 роки тому
Their DevOps game is on point
@blarvinius
@blarvinius 4 роки тому
Rewatching for 4th time. Will continue. 👍👍👍
@danaadalaide5648
@danaadalaide5648 5 років тому
Lots of useful information here, i've always been into defining metadata around data structures - i had written the same kind of thing about 7 years ago where classes were automatically generated from the schema, which was defined in the database with standard types for text, email, textareas etc. but what i find most interesting in your talk is grpc; its able to not only generate data structure templates but also has client and server libraries for creating a service out of the box.
@danielzaretsky1440
@danielzaretsky1440 3 роки тому
this guy either was really prepared or a savant with his incredible train of thought
@nsisodiya
@nsisodiya 4 роки тому
One of the greatest presentation I saw in the tech world. Really a lot to learn from Michael. I have hugely invested my decade in frontend world and now when I am digging in backend worlds, I see, I can invest next decade in it.
@darglo
@darglo 4 роки тому
I am blown away! Great video! Thank you!
@ChidambaramVelayudham
@ChidambaramVelayudham 5 років тому
Really a great presentation. Michael is talking what he has done in his real life. I was surprised he is not using Kafka for streaming and adopted a different approach. Thank you a lot!
@bobchemist
@bobchemist 2 роки тому
Kafka is way more efficient and fast, but can be fussy in production. Kinesis is easier to manage on a global scale because it is so well supported by AWS.
@positivetech
@positivetech Рік тому
really amazed by - "6 lines of yaml" great effort by folks who automated the default setup.
@benwho1549
@benwho1549 2 роки тому
Realworld Microservice example, amazing!
@MrNorthCat
@MrNorthCat 5 років тому
Great presentation! Must to view for all practitioners!
@thesobercoder
@thesobercoder 4 роки тому
My life feels like a lie now when I think about the fact that I know how to write microservices. Absolute gold standard!
@santoshdl
@santoshdl 3 роки тому
absolutely love this. thank your for posting this. Keep doing good work and keep sharing.
@sanjaig
@sanjaig Рік тому
Fantastic!!! Packed with info and best practices! Thank you!
@vishalsharma-bp9zu
@vishalsharma-bp9zu 3 роки тому
This talk was absolute best and absolute gold. Thank you.
@hansteam
@hansteam 4 роки тому
Wow! Thank you so much. This talk is going to drive a lot of decisions in my upcoming microservice architecture.
@BarZiony
@BarZiony 4 роки тому
Awesome talk! Thanks Michael. Can you perhaps elaborate a bit on the different main microservices that you have? What does the users microservice is in charge of for example? How do you ensure data consistency between multiple services that each save their own local copy of the same data (a user for example)?
@KaranPratapSingh
@KaranPratapSingh 2 роки тому
This is one of the best talks on microservices
@Alij47
@Alij47 3 роки тому
Great presentation. Very informative and great design lessons. It also represents great team collaborations and good culture at Flow. I wish more companies could adopt such innovative ways of working.
@foxford4981
@foxford4981 2 роки тому
Great presentation, but i have to admit, reading your comment that its great, i started to think its a very good guideline to quite specific practices when developing a microservice system. Not as an microservice architecture as a whole. Not complaining for sure, i learnt a lot from it, but it seemed like it focues on the micro elements of it XD Not the whole.
@andrew5222
@andrew5222 2 роки тому
I hope everyone understands how brilliant this is
@bahadiryagan
@bahadiryagan 5 років тому
Great talk. Most tech talks nowadays are passing time with things like "show me your hands, who is using kafka". But on this one, I actually had to pause a few times to digest what's been said.
@y.5107
@y.5107 5 років тому
Same for me. He seems to be a clever guy. Especially when he corrected the guy asking a question about feature development. CDeployment vs CDelivery are two different things. This little examples shows that he knows what he is talking about.
@awright18
@awright18 5 років тому
I think I'm going to have to have to borrow heavily from these ideas. This information is pure gold. Thank you so much! Just what I was looking for.
@mbryzek
@mbryzek 5 років тому
thanks!
@SatyanarayanaBolenedi
@SatyanarayanaBolenedi 4 роки тому
I would say, these are Gold Standards of MicroService Architecture From code generation till deployment. Every stage is well designed!! Thanks a lot Michael Bryzek, you made my day!!
@mbryzek
@mbryzek 4 роки тому
Thanks!
@driziiD
@driziiD 4 роки тому
i'm really impressed by that rds dev cli i want one
@cas1652
@cas1652 2 роки тому
I love the way this guy approaches developing: schema first, strong types, end to end tests, strong tooling, expressive language (scala). All of it together creates a virtuos cycle where each iteration carries you upward. I do wonder about schema changes and the event bus though. What happens when Service A puts a changed User onto the queue when the consumers haven't been yet updated. I also wonder about transactionality because at my job we sure seem spend a lot of time trying to tack on stuff that looks a lot like commit / rollback to the event bus.
@fakeapplestore4710
@fakeapplestore4710 4 роки тому
Great speaker and even better content.
@geoffreyhibon2651
@geoffreyhibon2651 Рік тому
Great moment to watch this presentation :)
@go_better
@go_better 2 роки тому
Very cool presentation! Lots of practical tips to use.
@bastiengerard433
@bastiengerard433 3 роки тому
Fantastic video, really inspiring!
@williamvankeulen1307
@williamvankeulen1307 Рік тому
I love this talk. So useful and so practical.
@khatuntsovmikhail6223
@khatuntsovmikhail6223 4 роки тому
How you deal with states and stubs in integration tests: you create user and you validate that user been created? web stub should be simple but state make it complex...
@rahulgoti3864
@rahulgoti3864 5 років тому
Thank You
@vishalsh1624
@vishalsh1624 3 роки тому
Love this talk! Loads of insights
@olubodunagbalaya8765
@olubodunagbalaya8765 2 роки тому
I'd probably watch this several times over
@giovannimarazzi8737
@giovannimarazzi8737 4 роки тому
what are the best resources for learning software architecture?
@NastyaSmirnova
@NastyaSmirnova 5 років тому
Great talk! thanks
@granand
@granand Рік тому
Hey experts, Please advise where to start and what software are needed to practice some projects from start to end with intention to know to design APIs, Test APIs please. Can I accomplish this with single laptop I have ?
@damejelyas
@damejelyas 5 років тому
these people can rebuild the internet if it goes down
@antonlogunov1936
@antonlogunov1936 4 роки тому
Agree, The Right Way. Isn't that much and difficult. Microservices rule!
@JoaoKunha
@JoaoKunha Рік тому
impressively simple, well done
@relhaibe
@relhaibe 2 роки тому
What do you think about to establish a microservices initiative to migrate a SOA centralized plaftform? Is this recomandble or not?
@joaopedrobourbon7483
@joaopedrobourbon7483 3 роки тому
Brilliant talk, very informative
@sushantnp
@sushantnp 3 роки тому
I came here to learn microservices. He is teaching me how to code, and I never felt dumber.
@I_dont_want_an_id
@I_dont_want_an_id 3 роки тому
May this encourage your faith facebook.com/esther.chester77/videos/1029971633787995/ ukposts.info/have/v-deo/pXmpf6Jwgo-or4k.html m.facebook.com/story.php?story_fbid=2582272895211292&id=490097534428849 m.ukposts.info/have/v-deo/fXVjp4Bkjn-X1ac.html ukposts.info/have/v-deo/iadjnK2appmH14E.html m.facebook.com/story.php?story_fbid=777934336005747&id=100013675634259
@atulverma7783
@atulverma7783 2 роки тому
very well presented especially focus on tooling
@hommeoursporc5874
@hommeoursporc5874 5 років тому
This is SO interesting !
@vekzdran
@vekzdran 3 роки тому
So... onboarding a new developer to all of that custom built stuff takes time to pick up and is very specific for their build / devops case. Its a fun talk and I like his delivery style and self-confidence in it. I am amazed they built stuff on their own and did not use existing stuff. Also those services are super thin from what I got the idea but then yet they have databases. Being unexperienced in this much code gen I can not say it is that worth it but again, hey they deliver and auto gen those e2e tests. Cool talk especially as I never did java or play professionally.
@kappaj01
@kappaj01 5 років тому
Awesome presentation sir! Well done.
@mbryzek
@mbryzek 5 років тому
thanks!
@yahorsinkevich4451
@yahorsinkevich4451 5 років тому
omg dev cli is an AWSOME idea, thanks for that :)
@Euquila
@Euquila 5 років тому
agreed
@mbryzek
@mbryzek 5 років тому
thanks!
@WayneMunro
@WayneMunro 2 роки тому
Code must be generated from a well defined model of the in context of the service. Almost anything can be derived from the model especially SOLID code. The question is how best to define a validated conceptual model up front in a data platform and language agnostic way that conforms to some first order predicate logic that proves the correctness of the facts expressed in the domain.
@smakarevich
@smakarevich 4 роки тому
Cool guy. Great speech!
@nicololino
@nicololino 3 роки тому
Nice talk, thanks! Even if it's old, I have a question: how do you/they automatically create git tags. I guess they are following semantic versioning or something similar. How do you/they know automatically the version to increment?
@barefeg
@barefeg 2 роки тому
It could be done by standardized commits. Given that most things are standardized I wouldn’t be surprised if that’s the case.
@sjogzor
@sjogzor 3 роки тому
45:08 Haha! Love this part. How much time, you ask? A lot! And a lot of anxiety too :D
@rajeshkishore7171
@rajeshkishore7171 3 роки тому
Excellent
@chessmaster856
@chessmaster856 Рік тому
How are complex queries implemented in microservices?
@ajitkulkarni7020
@ajitkulkarni7020 11 місяців тому
Brilliant one @mbryzek. Absolutely loved watching it. Lot to learn from this. BTW, anyone here knows a similar implementation already available for Golang/java?
@raarky
@raarky 5 років тому
great presentation. Thank you
@mbryzek
@mbryzek 5 років тому
thanks!
@guibirow
@guibirow 3 роки тому
First of all, Nice presentation, thanks for sharing. IMHO, The services he described are plain CRUD operations, this is why this approach works well. I've done similar solution in the past where I would design the database schema first and generate the rest of the service, it worked like a charm for CRUD services. DDD systems on the other hand are much more complex, will be much more complex to write business logic just using DSL or schemas like he demoed. The code generation would help a lot though.
@gonkula
@gonkula 3 роки тому
Thanks, perhaps would you mind nudging us in the direction of what to look for when solving similar issues in DDD systems?
@guibirow
@guibirow 3 роки тому
@@gonkula DDD systems are designed around business rules, which most of the times are checks and validations happening before an operation is applied to an entity, these are generally designed as workflows with multiple stages that are updated gradually on each user/system interaction. I've seen solutions in the past trying to auto generate code based on business rules, but the amount of code generates and the complexity for maintenance doesn't worth the investment.
@guibirow
@guibirow 3 роки тому
If you are just planning to do DDD, a good example I can share is this: docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/net-core-microservice-domain-model
@0xccd
@0xccd 2 роки тому
What a great talk!!
@aloussase
@aloussase 8 місяців тому
What is the API documentation standard that he is using?
@andreylebedenko1260
@andreylebedenko1260 2 роки тому
Microservices are required to extend the DB business logic in some way that can not be easily implemented in the DB language.
@OwenWilliamsRobotics
@OwenWilliamsRobotics 5 років тому
What are you using for your schema definitions? Your format looks similar to Apache Avro but it's not identical. Also what code generating/templating engine are you using?
@Bryanerayner
@Bryanerayner 5 років тому
@Chris ter Beke You can host apibuilder in AWS it seems....
@tomwright9904
@tomwright9904 3 роки тому
Are there any open source tools to work with these APIs?
@nisimjoseph
@nisimjoseph 5 років тому
WOW! Amazing talk.
@mbryzek
@mbryzek 5 років тому
thanks!
@DitaASubrata
@DitaASubrata 3 роки тому
wrote tests for production and ran in cron job. omg never thought of that.
@gravisan
@gravisan 2 роки тому
What is the fastest way to deploy 'Galactic the all knowing user service provider'?
@kennethcarvalho3684
@kennethcarvalho3684 5 років тому
Regarding Misconception No 3...are you saying that to create a resource in database you set up an event via a microservice and then that event was processed by another microservice and you were waiting for the response, which naturally you found not feasible. After that you got the solution that you directly saved the resource in your database via your microserver and also put in an event stating that this resource got saved via your microservice. Is my understanding right?
@zHqqrdz
@zHqqrdz 4 роки тому
Yes
@djkim24601
@djkim24601 Рік тому
Man, this guy is a monster.
@fyrofux
@fyrofux 4 роки тому
I might be wrong (and also a bit inexperienced) but this talk seems highly focused on Designing a Microservice Architecture **for the cloud**. Most of it seems to be great advice but still requires some deep though on "how do I adapt this to my own environments?" for example their Delta project would not work without a cloud environment (unless?).
@sagechris4742
@sagechris4742 4 роки тому
crack is wack
@RaMz00z
@RaMz00z Рік тому
Cloud is just a deployment detail. It could work *exactly* the same with private cloud or even Virtual Machines. Especially since he mentioned docker images. It is after all a standardized way of starting an app. So deploying it to the cloud, private cloud, VM, or your desktop is just a matter of wich command to run, that's all.
@VishalGupta9
@VishalGupta9 4 роки тому
I did not understand his point about creating indexes at 22:54 . He mentions that they would catch the developer from trying to create an index before they do, but what is the advantage and why should we appreciate whatever he is trying to say. If someone can clarify, please?
@VictorMartinez-zf6dt
@VictorMartinez-zf6dt 4 роки тому
What he means is that the developer shouldn't have to think about something like an index on a column, when they could have just worked on better tools so that the dev can focus on more important things, mainly the application itself. His point is that developers shouldn't have to waste time on trivial tasks or tasks that could have been solved with proper automation and code generation.
@sagechris4742
@sagechris4742 4 роки тому
Gupta, plz shut up and go cold call ppl. GUPTA!
@mbryzek
@mbryzek 3 роки тому
Great question and thanks for asking. What I have seen happen all too often is a situation where the "application becomes slow" and then is "fixed" by creating an index. This ideally should never happen and be instead part of the development process. By using code generation that provides methods or parameters based on the fields that are indexed, you can significantly reduce the probability of this error occurring because the indexes will be there from the start.
@AlinNemet
@AlinNemet 5 років тому
how does one make sure automatic dependancy upgrade doesn't bring breaking changes!?
@ExTex23
@ExTex23 5 років тому
You write tests, to verify if everything still works
@bugsthecat
@bugsthecat 5 років тому
Somewhere around @45:10 he talks about testing and how much they rely on it.. Apparently they have a lot of tests which guarantee such an action to be truthful. And such they deploy with confidence.
@mbryzek
@mbryzek 5 років тому
check out app.apibuilder.io/history?org=apicollective - you can see explicitly every API change that might be breaking
@sagechris4742
@sagechris4742 4 роки тому
Did he not just mention that every change to master is automatically tagged and tested before deploying into production?
@Alperic27
@Alperic27 5 років тому
... but maybe the developers themselves are generated clones...
@spagon
@spagon Рік тому
bravo
@dexterbt1
@dexterbt1 5 років тому
no mention of versioning api models/operations and events
@mbryzek
@mbryzek 5 років тому
every event stream has a "union" type describing the events that run on that stream. If you make a breaking change, add a new "type" to the union type - services should publish v1 and v2. Eventually update all consumers and remove v1.
@mbryzek
@mbryzek 5 років тому
We don't support breaking changes of APIs that are used (rest or event). Events are modeled as union types. If we need to introduce a breaking change - we define a new type as part of that union type. Versioning tracked automatically by api builder at app.apibuilder.io/history?org=apicollective
@chmaheshkrishna
@chmaheshkrishna 4 роки тому
Does any one know on what is the tool used to generate code automatically from templates ?
@sagechris4742
@sagechris4742 4 роки тому
Swagger(he says is poopie) , Thrift (RPC with Code/Documentation generationi) or gRPC
@Laggie74
@Laggie74 4 роки тому
Excellent. But I think this just highlights why you shouldn't build a microservice architecture if you don't need it. Especially if you are doing a small to medium size project, with few developer resources. Until the day when you have some standardized tools that allows you to pump out services/components in your tech stack, that just works out of the box.
@zHqqrdz
@zHqqrdz 4 роки тому
This is 100% true. Please, to all devs scrolling through comments trying to find reviews of smaller companies who tried using microservices : don't. Just build a monolith, make it clean, make it work. Have tests. Have a clean workflow. Once you're there and you start to feel the need to extract a part of your app into another project, extract just that part, nothing more, nothing less. It takes a crazy amount of work to succeed with microservices on the long term, and it also requires a great deal of skill. Let's face it, all developers aren't equally competent, and most have more experience working with monoliths (for now). So just write good monolith code, ship on time, and you'll still be doing better than most.
@RichardBuckerCodes
@RichardBuckerCodes 3 роки тому
There are several things wrong with the second half of the presentation: - how did they decompose the GRPC messages to be analogous to the API with it's personal DBs? - what happens when one microservice is dependent on data in a different API or event? - if there is some reporting that needs all the DBs then how is that performed? - if a transaction requires more than one API and there is an upgrade/deploy mid transaction how is repeatability supported (see monkey patching and erlang live code replacement) ... good enough for now.
@elnur0047
@elnur0047 Рік тому
have you found answers to those questions? those are exact things I was wondering
@RaMz00z
@RaMz00z Рік тому
- Not sure I understand, but if I do, everything is described in the API schemas, even the form of the objects used in the APIs - Local copies. The rule of thumb if I've understood is that *all* the data you need is in your own db. If you need to add new data for a new service, and you don't own that data, then you subscribe to the events from the owner, and you duplicate that data into your own db. - Events. If every single service emits upsert events, then you can have a reporting system that consume them all and aggregate them in a big db (at least I'd do it that way) - There is no transaction in micro services. First, the probability of that happening is (and needs) to be extremly low, with parallel and hot deployment. Then if it does there is two situations for me : - The event that failed can be replayed because no break in interface was made : he talked about that, you can just replay it, automatically or not I didn't understand that part. I'd say automatically. - The event that failed *cannot* be replayed because of a breaking change in the interface : then you'll need some way to create the new version of all the failed events in the system, and then I don't really have an answer because he didn"t... Note that breaking changes in event is the biggest challenge (by far) of an Event Driven System, so I guess it must be tough for them as well :/ I hope I helped and that my anwers were correct :)
@johnboy14
@johnboy14 3 роки тому
Great presentation but doing this in established companies with layers of beaucracy is incredibly hard. If your building a platform from scratch, then this is a nice way to go about it. The big takeaways here is the power of code generation and schema management. The way its described here makes so much sense. Continous delivery on the other hand only pays off if your testing is exceptional, else its just a quicker way to break things and lose money. The idea of pushing code to production on a Tuesday afternoon before you leave for the day would give me the jitters. That PR can definetely wait 😁
@AjayKumar-fd9mv
@AjayKumar-fd9mv 3 роки тому
Great
@tobiowolawi5044
@tobiowolawi5044 2 роки тому
i'm sure they use caching somewhere at some point.... but he never mentioned it
@crogersdev
@crogersdev Рік тому
If we have the API, why favor the events? He must be talking about internal clients and not public ones, right?
@rckd5903
@rckd5903 5 років тому
why not simply deliver both? /latest AND /1.5.3 🙈
@thomaskoppensteiner5557
@thomaskoppensteiner5557 5 років тому
rckd maybe “latest” wasn’t any longer equal to “1.5.3”.
@rckd5903
@rckd5903 5 років тому
Thomas Koppensteiner and?
@thomaskoppensteiner5557
@thomaskoppensteiner5557 5 років тому
@@rckd5903 yes the server can provide `/latest` and `/1.5.3`. The problem is, that it is not easy to change the definition of `/latest` as long as many clients use it. The clients need to change their impl. first and use `/1.5.3` (old `/latest`) before `/latest` can point to `/2.0.0`.
@rckd5903
@rckd5903 5 років тому
Thomas Koppensteiner That's the case anyways. You can still serve /1.5.3 additionally. Nothing prevents you from it.
@JGB_Wentworth
@JGB_Wentworth 2 роки тому
Wow, who ever would have guessed that Topher Grace would have gone on to be so successful in the software industry after That 70s Show?!
Scaling Push Messaging for Millions of Devices @Netflix
49:10
Mastering Chaos - A Netflix Guide to Microservices
53:14
InfoQ
Переглядів 2,2 млн
Lipstick 💄 crazy lifehack 😘 #lifehacks #beauty #makeup #hack
00:20
Типичная ситуация с МАМОЙ
00:16
Double Bubble
Переглядів 1,4 млн
MICHIEL VS JUVENTUS WOMEN 🙈📏
00:26
Celine Dept
Переглядів 51 млн
YOU WILL GET 100 STARR DROPS! #100StarrDrops
01:43
Brawl Stars
Переглядів 21 млн
Reliable Architectures through Observability
49:00
InfoQ
Переглядів 1,7 тис.
Authentication as a Microservice
50:26
Oracle Developers
Переглядів 212 тис.
The Problem With Microservices
17:47
Continuous Delivery
Переглядів 424 тис.
Managing Data in Microservices
52:07
InfoQ
Переглядів 141 тис.
How Slack Works
49:54
InfoQ
Переглядів 149 тис.
The Thing No One Tells You About Microservices
13:40
Continuous Delivery
Переглядів 52 тис.
The Evolution of Reddit.com's Architecture
33:11
InfoQ
Переглядів 87 тис.
Microservices explained - the What, Why and How?
18:30
TechWorld with Nana
Переглядів 748 тис.
Neuralink full send... Elon's brain chips actually work on humans
4:26
Сварочник SWM-10 Полезный обзор
42:37
Дмитрий Коржевский
Переглядів 50 тис.
Technicians are testing this LED module. #leddisplay #ledwall #ledmodule #ledscreen #eagerled
0:18
Пилю 🪚 телефон 📱 😵
0:28
Багз Банни
Переглядів 33 тис.
Старый и новый Redmi Book Pro #xiaomi #redmibookpro
0:53
Не шарю!
Переглядів 136 тис.