"People Get Microservices Wrong All The Time!" | Dave, Simon Brown & Hannes Lowette On Microservices
Вставка
- Опубліковано 15 жов 2022
- Why do people often get microservices wrong, what does good software architecture really look like and a software team's need for truly competent architects. This is a clip taken from Dave Farley, Simon Brown & Hannes Lowette's talk at GoTo Copenhagen 2021.
You can watch the full discussion HERE ➡️ • Architectural Models &...
-------------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content! If you join this month you will be entered into a book giveaway to get a free copy of Dave's latest book "Modern Software Engineering", or even a signed copy of one of Dave's books.
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
_____________________________________________________
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available here ➡️ amzn.to/3DwdwT3
📖 "Continuous Delivery Pipelines" by Dave Farley paperback ➡️
amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
NOTE: If you click on one of these Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-----------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses ➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribepage.com/organis... - Наука та технологія
If you cannot make a clean, modular monolith, what makes you believe you can do proper distributed systems?
:D
Many developers advocating microservices do so just to add it their skill set. They already plan on leaving the battle field once there is blood. Hence it is important to make sure your Architect has vast experience and stays long enough to facilitate the right decisions.
@@anandpowar82 I agree, but they're not really learning how to do microservices, just a distributed monolith.
I'll print it with credit!
Hiring people that know how to do it.
1:40 "Start with an idea, and assume it's wrong" 💡👍
When I was younger, I had terrible impostor syndrome because whenever I tried to use Waterfall, like I was taught at school and college, my big-design-up-front™ always deviated from what the customers actually wanted and their needs and the holes in my design slowly became obvious as the development went on. When I first heard about Agile, what I was actually being shown was Scrum and all the nonsense that Scrum puts on top of Agile obscures what it's actually about. It's only in recent years that I've learned what Agile actually is, and it's the process that I wanted to employ back all those years ago when I had that impostor syndrome because my Waterfall was crap... Turns out, it's actually Waterfall itself that was being the impostor. It's a great pity that I spent 40 years chasing after it and it's only now that, as an aged old got, I can finally get around to doing things the way I wanted to back when I was a pongy little teenager.
The point about assuming you are wrong - would prefer to say, assume certain things may not be quite right, once we settle on a model - then think about modularising it or moving to microservices/single units of responsibility.
I would argue that it is not the developers who shouldn't attempt microservices because they are hard, but rather their managers. I think most developers understand the trade-off of decoupling (e.g. no integration testing in exchange for independent releases) but at the same time most managers would find the same unpalatable. So what ends up happening is that they start doing nominally microservices but end up enforcing integration testing, lock-step releases etc. essentially creating a monolith. And thus tomorrow's legacy systems are created.
Yep. I've lived this hell, before.
Why is this technical decision a "manager's" call? I recognise that is often is, but why - it shouldn't be.
Dev's need to take responsibility for the technical decision making.
I don’t think that managers are usually the ones pushing for microservices in most cases. And I also doubt that most developers/architects pushing for microsservices understand the trades-off before hand.
@@ContinuousDelivery Because developers like any other normal employee does not really have or want the responsibility for such decisions. Most developers' life span in a company was always less than the software life span anyway, but in latest years, more and more devs being freelancers, this becomes even more acute. And what IS "responsibility" anyway? Paying for bad decisions? Not possible, morally and legally. Enduring the effects of bad design - why do that, when they can just change the company in a matter of days? :) A teacher of mine once said: "you can recognise a bad student by the fact that he is always writing on a fresh notebook"
@@ContinuousDelivery It usually does not start that way. It is the consequence of the first production bug due to incompatible microservices. The quick (and disastrous) decision to "test the services together before release next time" is made. In my experience engineers do rarely stand up to the management (who may not even know this is a bad idea) even when engineers themselves do know it. I agree that this should not be a managerial decision at all but sadly it often is as managers try to seize control when something went wrong not understanding what exactly and jumping to incorrect solutions. I don't know how to fix this though. Sounds like an idea for a new video. :-)
Nice, glad to see some nuanced discussion around microservices.
At my previous company we made a large rearchictecture towards them, and while it was a great learning experience, I've often wondered how using the monolith may have been better and in many ways "simpler" if we kept it modular.
That said, microservices have the promise of being quite scalable if we can do them well
I'm on a microservices team and I agree with a lot of this.
Microservices are by far easier to develop since the context is smaller and the codebase is smaller.
However. Knowing the right context and boundary beforehand is very hard if not impossible. You also have to take into account the work around CI/CD, syncing contract changes, debugging etc.
Doing microservices the right way is damn hard but rewarding.
In a properly designed modules within monolith, the context is smaller as well.
i have *never*, i repeat, *never* seen microservices really deliver what "they promised". there is always a messy/tedious configuration step before you have one running, making me think "i just spent a day what would have taken minutes in a monolithic architecture"
I don't think microservices have any promised, when the time is come you will know that you need to break your system into smaller loose coupling part. If not, just stay with monolith, as best practices microservice should start with domain driven modular monolith.
It gets that way without internal developer platforms/infra to automate the tedium out.
Same here. You can have a 'monolith' that isn't overly coupled to itself, it just takes discipline vs a physical boundary.
This is why hexagonal architecture is much better. Smaller hexagons inside can later be changed into separate deployable hexagons.
To anyone who hasn't seen this entire talk, it's one of the best ones on Dave's channel. There isn't a moment in the full talk that isn't educational.
I highly recommend checking out the full length talk.
link please lol
@@benevbright ua-cam.com/video/YSw80X4w7hI/v-deo.html
@@TheMrFlipp ♥
its always fun to watch your videos, I get to learn a lot from these discussions, thank you for sharing, God has sent you
Loved the presentation, as usual.. We're switching from a large monolith to microservices.. crazy times but this is good input (together with other ones). Thank you!
Btw. Dave, off topic - what watch is that you're wearing?
My watch is a Bulova - it is the model worn by the later Apollo Lunar Module pilots, and was a birthday present.
@@ContinuousDelivery That's a nice piece! Congrats! and thank you for your letting me know.
A very enriching talk
Just like OOP there's 99% chance you don't have a problem that warrants microservices but it'll be the defacto solution anyway.
When you have 12-16 developers but >60 micro-services!
I once worked in a team with such a legacy application and I was very concerned about changing something that was recommended by colleges who have been need to the team. But now I'm sitting on the other side of the table and I make suggestions about what can be done better. That how a programmers life changes when project come toa sudden end.
You can't change direction effectively if you haven't set a destination up front.
I find that microservices in small start up companies doesn't work due to the overhead. However making a monolith with well defined schema's in the database to be able to decouple down the track is what I think makes more sense.
I also found microservices is hard. I love working in k8s. But being too modular doesn't work either. More complexity for no reason. I never seen a company strike the balance. It's either too much microservicing to the point where it becomes extremely hard to manage everything and then requiring extra tools to manage making it more expensive. Or they do microservice but its as you said monolith microservice!
I'm wondering what is the process to start helping teams steer to the right direction?
Our organisation wants to use microservices because it sounds fancy and right for these times but don't want to get into the architecture details. Its cloud natuve design but their is no cloud strategy. I feel like i have hit a wall as no one wants to talk about it. They think we can use FastApi and prefect to orchestre the workflow and each service in a separate docker container and we are good. Not to mention they think we don't need to version our services. Of we ever need to run 2 versions of microservices we spin it in 2 containerz which hosts different versions...
The architecture and elicitation skills here have to be good to pull off micro-services correctly. It’s nice to hear someone say coupling services via http is so bad. As Dave said, we should be focusing on being able to rely that other services are independently deployable.
Great talk! Would like see more of these!
how do you solve issue when some business logic already implemented at some endpoint, did you replicate that or just reuse that? Think is, it's hard to define business boundary context in design phase, especially when the project had tight dead line.
is that the Bulova Lunar Pilot Chronograph?
Yes 😊
Having been a developer, and having been in Operations, I am of the firm and unwavering opinion that DevOps is the insane idea of people who have never written code that *MUST WORK* so that 100,000 customers (and their credit cards) who rely on your product to get to work and back *every day* don't grind to a halt, and so millions of dollars keep flowing from where they are to where they should be.
Then I am afraid that you are wrong. DevOps comes from people with way more that 100,000 customers and sometime spending money at much higher rates that normally done with credit cards.
There is a lot of nonsense talked about DevOps, like everything else, but at its heart it is simply saying that we need to align the goals of dev and ops. Not sure how this can be controversial.
If you mean, as many people do, "Continuous Delivery" when you say "DevOps" then again, I would disagree. CD is the process at the roots of some of the biggest, most successful companies in the world, and is applied very effectively, in nearly every industry that you can think of. Tesla is a CD company, so is Amazon, so is Ericsson for example.
At 10:10 everything is said. You cannot do microservices right if you do not understnd the domain your implement them for.
Otherwise a team (or whatever organisation) will endup with a monolith with some characteristics of microservices.
Something about the audio quality is off. Too much treble and high pitch scratchy sound to voices
🔥💯✨
I dislike these ex-catedra statements. Almost all patterns, rules etc. are subject to certain pros and cons and so is microservices. Instead of condemning the pattern it would give more insight discussing the disadvantages and advantages. Dave's rule (Don't separate if you can not deploy without testing against the other modules) is a start but seems to strict for me. In my industry (banking) this is impossible - few systems are deployed without integration testing (e.g. together with a ledger) - the whole bank would end up in one repo
...therefore microservices is a poor choice.
Service orientation on the other hand is a great choice. Design the same way, design the same services, use the same distributed comms mechanisms if you want, but put them all together in version control and test them all together continuously, and then release them all together. It is WAY more efficient than microservices. If you don't need the teams-scalability that microservices delivers, don't pay the costs of it.
This is not a message from the cathedral, read the definitions of microservices (microservices.io), and think about their implications. Now read the definitions of Continuous Integration and Continuous Delivery (en.wikipedia.org/wiki/Continuous_integration), use these rather than "folk impressions" of what they mean, and I think that you will come to the same conclusion as me.
The more I hear, the more I believe Dijkstra and Mills were right and how little they were understood.
Childish attitude towards engineering turns everything into a toy. Big money only freezes that to very negative degree (extent).
"That requires some really competent Architects"
NO! You forget the initial premise of Dave: you have to assume that your initial design is WRONG.
So, in order to develop micro-services, you have to start developing the system in a single repo, without all the IPC and other complexity, until the interfaces between the embryonic "services" have stabilised. Then you can put in the IPC, and after that has crystalised, you can split off the individual services.
I am mildly disappointed that both gentlemen so whole-heartedly agreed that if you have competent Architects, the micro-services approach will work, after all that was said.
if you slice your service contexts so that they do not depend on other services, you avoid the vast majority of "issues" involved. your servce should have the data it needs in order to service the request. I think Farley misses this point all of the time.
So then, they are "independently deployable" - right?
Not sure what I am missing?
I don't care why you need me but I'll do what I'm asked
I don't care how you do it, just do as your told
i shouldn't be watching this