What is microservices architecture?
ฝัง
- เผยแพร่เมื่อ 4 มิ.ย. 2024
- What are microservices architecture? Why do we use microservices? How do microservices talk to each other? How do we test microservices? What are the problems with microservices?
#microservices
▬▬▬▬▬▬ Timecodes ⏱ ▬▬▬▬▬▬
00:00 Intro
00:25 What are microservices?
05:09 Why do we use microservices?
07:17 How do microservices talk to each other?
09:07 How to test microservices?
11:38 What are the problems with microservices?
14:40 Are you really having microservices?
▬▬▬▬▬▬ 🚀 Courses, books, and podcasts 🚀 ▬▬▬▬▬▬
📚 DevOps Catalog, Patterns, And Blueprints: www.devopstoolkitseries.com/p...
📚 Books and courses: www.devopstoolkitseries.com
🎤 Podcast: www.devopsparadox.com/
💬 Live streams: / devopsparadox
▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
➡ Twitter: / vfarcic
➡ LinkedIn: / viktorfarcic - วิทยาศาสตร์และเทคโนโลยี
How do your microservices look like? How different is what you're doing from what I explained?
I have never tried using a microservice, mostly because our team isn't that large, so we never had the need to. We just use a monolith.
But I do want to try it out. Maybe I will.
@@sauravadhikari8645 Do not think that one is necessarily better than the other. Depending on a use-case and experience, monoliths can be a better (or a worse) choice. The important part is to have experience with both so that you can make an educated decision which route to take.
I wouldn't call them micro, in the sense that a service may have multiple responsibilities that could easily be done by a different independent service. However, they can all be deployed independently, the can be communicated with via api and queue system.
Worked in two companies where microservice approach have been an option. Both have implemented distributed monolith in the end in so far, but it went also under the label ''microservices...''. Had a hard time arguing for real microservice, since there were strong opinions due to lack of real experiences in those companies and I was only a team member with equal votes like the other menbers. But your post confirms, that I see the real microservice approach is beautiful and a really good fit for mid to large scale projects. Again, thanks a lot!
Viktor, I think I love you.
I’ve spent so long arguing fruitlessly with dev teams of clients trying to explain this.
It has been terribly lonely and dejecting.
Please keep these videos coming!! They are the best cases I can send to my clients to answer their questions and issues in under twenty minutes!
These are knowledge sharing gold, my friend. And the rest of the devops community should be celebrating this material.
Unfortunately, in all organization where I worked, microservices is distributed monolith. Devs think that if they use Kubernetes that it is a silver bullet. But in reality, every release may break another app.
That is a (sad) reality. That is sometimes avoidable, and sometimes it isn't or it doesn't make sense to avoid. My point is that we need to be honest and call things by their names. By being realistic about what we have, we can do our work much better.
I'm dealing with this at my current company. Trying to get them to understand the value in decoupling each service and having clearly defined interfaces. They are currently in the process of changing from more of an R&D PoC thing to a Production level set of services.
Very concise! I also found that 98% of the time when people say they hate microservices and they don't make sense, they in fact dealt with a distributed monolith and lost the challenge of synchronizing deployments to fit the coupling. The other 2% they failed to tackle the operational overhead inherent to adoption - usually because the adoption was done under some kind of pressure and was haphazardly put together.
Straight to the point, explained in a concise, but warm way. You are incredible! Thank you.
Thanks for another entertaining and enlightening video Viktor! So, as I now see this, before you start creating a microservice, you should think and plan out the interactions of the complete system, divide into domain entities that can be said to have a single responsibility, and sketch out the required inputs and outputs. Next up, define the data model. With the data model in hand,you may now engage in the microservices journey. The data model should be tailored for the communication layer, internally each service may use different models.
You cannot simply start to create a microservice. You have to plan the interactions of the system first.
Exactly.
Awesome video! I fully understand that you can't stay calm with this topic, I gave up on arguing about it. :/
There are great resources out there to share info about what micro service architectures are and with your video there is one more!
I know one thing: I wouldn't want to argue with you about it! 😀 Great video.... and a reflection of reality (sadly)...
Very recognizable, thanks again for this fun video! Cool t-shirt btw...
Thanks!
Great Video, thanks Viktor,
I would like to know more about testing using mock data. For example how to set up mock data from an API using its openAPI.
Adding it to my TODO list...
Great video, again. It's a bit sad how the entire industry jumps into a tendency most people don't understand. Devs are not to blame... Their bosses are, forcing them to do microservices just cause the others are, without understanding the benefits, the risks or the complexity.
Even though I tend to blame managers more often than other roles, there's a bit of blame to be split among everyone. Managers should be better at understanding what they're managing, and devs should be a bit better at saying "no".
The hard part with microservices for me was testing. Like what to test without going outside of the context boundaries of a microservice. But with practice its achievable. Question for your regarding microservice code base organisation:
will you suggest:
- microservice per repository
- monorepo with all microservices + some monorepo management tools (like Bazel)
I prefer one repo per service. Monorepos are much harder to manage and tend to foster coupling.
@@DevOpsToolkit AMEN!
All devs should watch this video and also listen. I truly don't understand their thought process when they are splitting their stuff where they have like 5 services per developer and basically just replacing local function calls with network rpc.
But hey, if they just had like 2 services they wouldn't need kubernetes and I wouldn't have a job so I'm not complaining 😂
Exactly!
There are cases when microservices are the best choice, and those when they are not. In practice, however, there is a significant number of cases when they are a solution to a non-existing problem promoted mostly for people to be able to say "I'm doing it!"
This is wonderful, Thanks for sharing. If we have decided to move the existing monolithic application to a microservice model, and then how do we test the first few microservice before we do the full migration as a continuous process? Do you think canary testing with Contract is the right candidate? And during the migration, do we need to integrate both mono and micro model ? Also, will the service mesh in k8s can be of any help during this process? Any insight on this will be helpful.
> If we have decided to move the existing monolithic application to a microservice model, and then how do we test the first few microservice before we do the full migration as a continuous process?
You test it in the same way you're testing monoliths. Since it's a migration and not a new set of services, you are effectively doing refactoring. That means that the system as a whole should behave the same. You'll choose which part of the monolith you want to move out, run tests to confirm that it is currently working correctly, move a part of it into a microservice, test again.
Do not take the "big bang" approach. Go small. Pick one feature, move it into a microservice, confirm that it works correctly, repeat.
> Do you think canary testing with Contract is the right candidate?
If by canaries you mean that the older release is 100% monolith and the new one is monolith plus 1 microservice (to begin with), then I'm not sure you can do canary deployments easily, at least not with the existing tools. I think that you have a better use case for blue-green deployments.
> And during the migration, do we need to integrate both mono and micro model ?
I'm not sure I understood that question.
> Also, will the service mesh in k8s can be of any help during this process? Any insight on this will be helpful.
Service mesh essentially allows you to do advanced networking. You get TLS, network splitting (e.g., canaries, blue-green, etc.), retries, etc. Now, I cannot say whether that would be helpful for you or not since I do not know your system not your experience level. What I can say is that you should NOT start using service mesh from day 1. You must, as a minimum, have enough Kubernetes experience in production first. Otherwise, you're risking on doing too much too soon.
Those are interesting questions and we can probably talk further on that subject. You might want to join the next AMA (ask me anything) session. Both public and members-only will probably be held sometime next week.
Awesome explanation. Thank you.
Could you explain how to write functions as service (function as code) using openfaas & explain difference between FaaS and Microservices, please
Will do. Adding it to my TODO list...
You are amazing!
What are the security challenges in creating a microservice in line with the principal of devsecops?
Can we have a separate video on it
Great suggestion. Adding it to my TODO list...
Dear Victor what an amazing content you provide us with in your channel! Thank you!
Thanks Vugar.
Any suggestions for a topic I should explore in one of the upcoming videos?
@@DevOpsToolkit It will be nice to hear your thoughts on ECS Fargate and maybe see a comparison with Google Cloud Run or maybe hear your thoughts on how and when it could be a better option than cloud managed kubernetes. Especially so in terms of automation of deployments and rollbacks... Thank you!
@@vugardzhamalov8479 You mean something like th-cam.com/video/Jq8MY1ZGjno/w-d-xo.html
@@DevOpsToolkit This is awesome! Thank you! Here is another request if I may please: can you please cover some approach and/or tooling to queue git PRs? Say when multiple devs raising multiple PRs - these must end up merged to master and get deployed afte
It's a nice passionate speech! =)
Invariably though, a feature request will come through which will require changes to 2 or more of the micro services. How should this be coordinated? Or is it more evidence that the micro services weren’t segregated properly?
It that happens once in a while, it should not be a big deal. That, however, does not mean that each of those services need to be finished and deployed at the same time, as long as APIs are versioned.
Now, if the need to change 2 or more services is not an exception but something that happens relatively often, it is a sign that they were not segregated properly.
Thanks, Victor!
Question: Do you have any recommendations for splitting the data layer of a traditional monolith being transformed into a microservices architecture. From my experience, it seems that's often the most difficult part of migrating a large monolith to a microservice architecture, or do you consider an architecture with a single shared database and multiple application services a complete microservices architecture.
Shared DB is sometimes a necessity and might be an intermediary solution. On the long run, each service should have it's own DB.
... and yes, you're right that data is often the most difficult part of the "transformation". I don't have a magic bullet for that. It's all about figuring out which data should be owned by which services, and rewriting the rest of the systems/services to speak to that service's API instead of going directly to the DB they do not own.
@@DevOpsToolkit Makes sense. Thanks!
I wouldn't really consider it a microservices architecture if the DB is shared. This doesn't mean that it's a bad thing to have a shared DB, just that it is tightly coupled by nature, the models become very interdependent basically instantly as you write the code. There are distributed SQL databases like cockroachdb, google spanner, mongodb I think supports distributed transactions across shards, so having a huge shared DB I think is the best choice for most applications right now.
The most important consideration when splitting microservices I would say are the transaction boundaries or "boubded contexts" as I heard them being called. You want to maintain the database consistency and database transactions are the easiest way of doing this. The problem with trying to find these bounded contexts is that in the future the business logic might change and you will need to make transactions across microservices. If you want transaction consistency across microservices you will need to use 2 phase commit. Some people advocate using sagas, as they are "faster than 2pc", but ofc they are faster, as they are eventually consistent, while 2pc is always consistent, so they are not really the same thing.
Maybe you decide to go with eventual consistency pattern like sagas or no transaction consistency, depending on the application it could be just fine, but I think that people are lying to themselves if they think they understand the implications of eventual consistency on what arbitrary business logic might be getting written in the future.
@@gigiduru125 I would see a shared DB as more of an intermediary step. After that, create an API for the shared DB, and migrate all other services to using the API. Once everything is using the API, via message queues, the DB is no longer shared and becomes its own Microservice. I see it as part of the iterative process for converting a monolithic application to more manageable units
Splitting the data layer into separate data stores is essential. It's also incredibly difficult. It's foolish to say, let's use Mongo, or whatever new thing is cool at the moment. That just kicks the can down the road. Understand what data is shared across services, and implement the rules for how it is shared, what service can do writes. What each service needs to be able to read, and creating access to shared data sparingly. Utilize Redis or in memory caches when needed. Don't use a monolithic data store with micro services. It's a recipe for frustration, as it will become a bottleneck. NoSQL is not a magic bullet.
Question... Where should i study practical microservices implementation (nodejs) + communication + docker launch + auto scale of certain component
I might not be the best person to give an advice on NodeJS (not the main prog. language I use).
For communication, try Darp (th-cam.com/video/-4sHUvfk2Eg/w-d-xo.html).
For Docker launch... Do not use Docker. Even Docker company gave up on the idea of using Docker in production. It's usage is limited mainly to laptops (and even that might not be the best idea). Focus on either Kubernetes or managed services (e.g., Google Cloud Run, Azure Container Apps, etc.).
Autoscaling depends on whether you're self-managing or using managed services. If it's the former, use Kubernetes HPA for autoscaling. If it's the latter, managed service tend to come with autoscaling baked in.
P.S. I'm working on a video about autoscaling. Coming up soon...
Hi Victor,
Really great explanation. Thanks for putting it all together.
I am confused in between API Gateway and service mesh. I would like to ask you Where exactly service mesh fits into microservices architecture?
API gateway is also handling cross-cutting concern and service mesh also does that by implementing sidecars for individual microservices. If we introduce sidecars, Wouldn't it increase extra operational complexity ?
And which component companies using in production for handling common concerns ?
What is your opinion on above points ?
Service meshes and API gateway are very similar. I prefer service meshes simply because they are becoming a norm in k8s (and most of my work now is in k8s).
Sidecars do not necessarily increase operational complexity (when compared with API gateways). You can configure your service mesh to inject them automatically. Now, that assumes that one is equally experienced with service mesh as with API gateways.
I'm just finishing the CI pipelines for multiple microservices that aren't really microservices like you've said in the video. Really it's a layered architecture - private ethereum chain (in dev/staging, mainnet in prod), 'processor' that crawls the blockchain and populates a mongodb database, API and frontend. I've been hoping to use argoCD but is this going to be a bad fit given that blockchain needs to be deployed, then smart contracts, then processor, then api, then frontend (ugghhhh). Is an argo workflow more appropriate in this situation?
I would use Argo CD in that situation and combine it with Workflows for things like building images, running tests, etc. Argo CD allows you to specify the order of preference for different resources, if that's what might be causing issues.
That being said, I would suggest starting with one of those first, and then transition a part of the workflow into Argo CD. It's almost always better to go step by step and, in that case, Argo Workflows is a good candidate to start with since it can do deployments as well.
@@DevOpsToolkit literally don't know how you find the time for everything you do including replying - thank you very much for your reply and suggestions. I didn't know you could set order of preference, so I will give that a go and fallback to AW if A CD ruins my Sunday.
There's a term called Bounded Context, if you understand it, i am sure you will have easy time making decisions regarding microservices.
Exactly! The only problem is that if you try to understand it by reading the "Domain-Driven Design" book, you are likely going to have suicidal tendencies. I started reading it and gave up at least four times, until I finally managed to force myself to read it entirely.
@@DevOpsToolkit haha yes same happened with me when i started to learn, it is a total different world to think in. But once you get the concept clear you will have less numbers of microservices :-D
Instantly subscibed
Thanks!
My dude!
For the business/client why do you think investing in microservices comes with business values (rather than software production), what will the client get as VAS from microservices
Responsive, highly available, and scalable applications with releases delivered much faster alone should be a valid business reason. Would you agree? Nevertheless, whether it should be microservices, monolith, distributed monolith, or something else is not a business decision. It's a technical decision.
@@DevOpsToolkit I need to proof a valid business opportunity at business field or industry rather than the tech side. I guess the magic answer might be,,"synchronicity within asynchronicity" like real-time UI/UX apps
I'm not sure why would you look for a proof on the business side. What you need is figure out what business needs and let the team make a technical decision about to fulfil those needs. From the business perspective, it is irrelevant whether it is microservices or monolith. Whether it is in containers or in VMs. Whether test coverage is above 90%. And so on and so forth. Business decisions are, for example, what should be the availability (e.g. 99.99%) and not how should that availability be accomplished.
What I'm trying to say is that you should not start with "I want microservices, let me see how to justify that from the business perspective". That is a wrong order.
Still, if you do need a business justification, I would suggest checking DORA. Microservices are only a part of it, which is a good thing. It shows numbers behind certain practices and choices, as well as the importance of making organizational changes.
You are one of the best developer youtubers out there.
1 like, comment and subscribe from me.
Thanks
It reads "why are you fucking microservices" lol
Microservices does not have to be "small". Whatever that means.
Being small is relative. One can say that small is 100 lines of code while other might say that 10k lines is small. To me, small is something that can be managed by a small team (less than 10 people) and that team does everything from reqs to production.
@@DevOpsToolkit I agree on that.
but hey... what if I'm alone? Does it mean I will never have microservices?
That depends on how long you work on it. A single person cannot create a big monolith in a few months but also cannot create and manage dozens of microservices. As a one-man-band, you are likely going to have a microservice (or two), unless you are a superhuman :)
Let me complicate things more .... should microservice have it's own repo?? 😂
personally, i prefer multirepo approach with each micro service being in its own repo. Others are going for monorepo.
So then if you need a frontend lol how tf do you do that as a microservice??? Asking for a friend 😉
I'm not sure... The last time I worked directly on front-end code was 10 years ago. Back then, we did have separate modules deployed independently, but I do not remember which tech we used back then.
this is not really an explanation, just a boring rant