Mastering Microservices | VOL. 1: Getting Started, Good Design & The PROBLEM With Microservices

[@sinner6]

I really like this as a way to rewatch some of your content, Having a cohesive theme really makes it easy to keep watching.

[@qj0n]

Interesting idea to publish such compilations. I believe they will be a good reference videos for future viewers to learn from past content and could be used as podcasts as well. And now I can send someone link to just one video on how to handle microservices with CD If I could add just one thing, it would be nice to have chapters - I've seen many of those videos and I would love to jump between them to those I haven't watched or I don't remember

[@ContinuousDelivery]

Good idea. I've added the chapters now. Thank you for the suggestion.

[@hcubill]

Loved the idea keep them coming Dave!

[@stephendgreen1502]

Great news that it is now recognised that the language of communication, whether JSON messages or XML document schema (old school, sorry) or API design is a separate bounded context. That was the piece missing from the microservices concept. A light at the end of a dark tunnel maybe.

[@ddanielsandberg]

First rule of microservices - Don't do microservices. Second rule of microservices - See first rule. Third rule of microservices - Since you're going to do it anyway, please learn DDD, networking, distributed computing and observability first. Fourth rule of microservices - If you name your services "-service" you're probably on the wrong track and are just building a distributed monolith. Fifth rule of microservices - If you have 1000 microservices and 50 engineers, you're just making shit up to add K8S to your resume and get paid to do your hobby.

[@zharkopetrovski2431]

@@ddanielsandberg Perfect advise and very painful lesson learned of mine 🙏

[@jeffreyhymas6803]

I'm on a team at work developing a proof of concept for a potential software service we want to provide. Started nice and simple. Couple of components in a few different repos, a library or two, nothing all that complicated. Fast forward a year and we have 6 micro services managed by a single 5 person team, spread across 20 repos, all containerized and hypothetically deployed in Kubernetes. All for a small R&D project with literally no users.

[@frankkelly1916]

1000% true. Microservices are a mistake unless you are a FAANG company or experiencing exponential growth. Better to start with a monolith with great interfaces and only break things off as you need. If you can't build a monolith correctly you'll certainly not be able to build a distributed architecture correctly either.

[@Post-Agile]

Microservice is not only scoped by Bounded Context. Yes, Bounded Context can be a Microservice, but a Microservice can also be the aggregate root. There is no hard and fast rule here. Worth noting that if Microservice is Bounded Context, it will be quite frankly a big service, and not very micro.

[@ContinuousDelivery]

The definition doesn't say "scoped by Bounded Context" its says "Aligned with a Bounded Context" nearly, but not quite the same thing, and not the same in a way that tackles your second point. It can sensibly be a part of a BC, it doesn't have to cover all of it, but it should be clear which BC it is part of.

[@vicaya]

Independently deployable is not sufficient. Independently usable and testable is required. Using nebulous abstract phrase like "bounded context" is architecture astronaut speak and doesn't help at all.

[@MrTbirkett]

The savant developers I work with are creating a car crash. Their hubris drowns out my actual experience.

[@pompiuses]

Agree, and why would you store all services in the same repository when they’re fully independent?

[@Fjonan]

I found the term adequately explained. He is not just dropping it but making clear what it means with examples.

[@ContinuousDelivery]

I would argue that "independently deployable" and "independently testable" are synonymous and "independently useable" isn't really required. I am fine with services that provide utility in combination with others, but they should still be independently deployable/testable.

[@chakala2149]

Hello Trisha, Hello Dave, Can you please make a video to discuss the fact that 'a micro-service app is meant to be developed by several independent teams' and not by one?

[@ContinuousDelivery]

This one does discuss that topic already.

[@LucTaylor]

I feel personally attacked by "one message to rule them all"

[@marcbotnope1728]

Step 1: Don't Step 2: See step 1

[@seNick7]

Are you proposing that 300+ developers should be still working on the same monolith/system and deploy once in a month?

[@marcbotnope1728]

No need to have "microservices" to enable large development teams. Outside "web development" no one is releasing more the once a month. And what are you working on that need 300 developers?

[@ContinuousDelivery]

Well at Google 25,000 developers work in the same mono-repo and deploy a lot more frequently than once per month. At Tesla several hundred people, over 400 last time I looked, work in the same repo, and that includes all the code for all the cars and the factory. So I am not only suggesting this, I am stating it as a fact. I recognise that this may sound surprising if it is not what you are used to, but it works very well indeed, and it provides a lot less overhead than keeping tightly coupled, dependent services in separate repos.

[@ContinuousDelivery]

That's not true. I worked on Trading systems, and we released between once per day and once per week. Tesla release on demand they upgraded the max charge rate of the Model 3 from 200 to 250kW, which included a physical hardware change, all under software control, within 3 hours of the commit that defined the changes. (Their factory is under software control too!) SpaceX are updating the software on their space rockets up to 40 minutes before a launch. There are examples of orgs working this way in EVERY industry, this is not just for web-pages!

[@frankkelly1916]

@@seNick7 Are you proposing that 300+ developers building a distributed system will be easy?

[@dinov5347]

Unfortunately, from my experience your initial system that is implemented will never really evolve since management will never allow you to revisit. There is always something else to implement. Unless you get a buy in from senior leadership that implementations evolve, you are forever maintaining what you initially developed.

[@ContinuousDelivery]

Find better management?

[@dinov5347]

​@@ContinuousDelivery as if one has a choice here.

[@fjzapatap]

@@ContinuousDelivery I suggested that, actually. I got fired, instead.