What is microservices architecture?

Поділитися
Вставка
  • Опубліковано 28 лис 2024

КОМЕНТАРІ • 84

  • @DevOpsToolkit
    @DevOpsToolkit  3 роки тому

    How do your microservices look like? How different is what you're doing from what I explained?

    • @sauravadhikari8645
      @sauravadhikari8645 3 роки тому +1

      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.

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +1

      @@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.

    • @AndreiDinTheHouse
      @AndreiDinTheHouse 3 роки тому +1

      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.

    • @stef2528
      @stef2528 3 роки тому +2

      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!

  • @thescourgeofathousan
    @thescourgeofathousan 2 роки тому +3

    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.

  • @Dr0rpheus
    @Dr0rpheus 2 роки тому +2

    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.

  • @AndreiDinTheHouse
    @AndreiDinTheHouse 3 роки тому +1

    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.

  • @aleksandrarestov7150
    @aleksandrarestov7150 3 роки тому +15

    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.

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +4

      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.

    • @Xetius
      @Xetius 3 роки тому +2

      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.

  • @ChristofferVig
    @ChristofferVig 3 роки тому +2

    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.

  • @stef2528
    @stef2528 3 роки тому +1

    Straight to the point, explained in a concise, but warm way. You are incredible! Thank you.

  • @GuillaumeMaka
    @GuillaumeMaka 3 роки тому +3

    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)

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +6

      I prefer one repo per service. Monorepos are much harder to manage and tend to foster coupling.

    • @PflanzenChirurg
      @PflanzenChirurg 3 роки тому +1

      @@DevOpsToolkit AMEN!

  • @jonathanorrego6199
    @jonathanorrego6199 2 роки тому +1

    Question... Where should i study practical microservices implementation (nodejs) + communication + docker launch + auto scale of certain component

    • @DevOpsToolkit
      @DevOpsToolkit  2 роки тому

      I might not be the best person to give an advice on NodeJS (not the main prog. language I use).
      For communication, try Darp (ua-cam.com/video/-4sHUvfk2Eg/v-deo.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...

  • @NehaSoni05
    @NehaSoni05 2 місяці тому +1

    Hi Viktor,
    Great tutorial! I have one question-suppose we have two different teams. Team A's product handles services that provide data to Team B, which consumes this data. In the development phase, Team B is using the latest APIs from Team A. Now, if Team A’s APIs break or undergo significant changes, causing Team B's APIs (which depend on Team A's) to break, would you consider this type of architecture a distributed monolith?

    • @DevOpsToolkit
      @DevOpsToolkit  2 місяці тому +1

      I would just call it a bad practice. One cannot make breaking changes to an API without keeping the option to use the older version. You need to give others time to adapt to those changes.
      You can solve that in many ways. You can write code in a way that both the old and the new API are available. You can also run both the old and the new release of the app with that API in parallel. And so so on so forth.
      The point is that we need to give time to people to adapt to breaking changes before sunsetting the old version.

  • @momusi.9819
    @momusi.9819 4 місяці тому +1

    Thank you for the clarification between distributed monoliths and microservices. As it turns out, I was building distributed monoliths hoping to get the benefits of microservices. The video leaves me confused thought, because I cant imagine a scenario where the system as a whole is a collection of microservices that are "all" loosely coupled. In such a scenario, would not each microservice for example do its own persistent storage (DB) authentication and authorization, logging and much more? I would imagine that there is something like a "core" or platform that itself is maybe a monolith or a distributed monolith that provides services to those microservices. Do I miss something?

    • @DevOpsToolkit
      @DevOpsToolkit  4 місяці тому +1

      I don't see a problem each service that needs persistent storage using a separa instante of postgresql or a separate database inside a shared instance.
      Authentication and authorization is typically done through a service mesh except when it's user facing but that is typically reserved for a front end.
      Logging is easy. Just output to stdout and let logging collector take care of the rest.

  • @matscloud
    @matscloud 3 роки тому +2

    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.

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +1

      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".

  • @gigiduru125
    @gigiduru125 3 роки тому +3

    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 😂

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому

      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!"

  • @SumanChakraborty0
    @SumanChakraborty0 3 роки тому +2

    What are the security challenges in creating a microservice in line with the principal of devsecops?
    Can we have a separate video on it

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +1

      Great suggestion. Adding it to my TODO list...

  • @kingalok
    @kingalok 3 роки тому +1

    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.

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому

      > 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.

  • @andrepires5251
    @andrepires5251 3 роки тому +3

    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.

  • @charlesm1548
    @charlesm1548 3 роки тому +2

    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?

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +1

      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.

  • @amabamo5769
    @amabamo5769 3 роки тому +1

    It reads "why are you fucking microservices" lol

  • @GeertBaeke
    @GeertBaeke 3 роки тому +3

    I know one thing: I wouldn't want to argue with you about it! 😀 Great video.... and a reflection of reality (sadly)...

  • @Nilesh_Narkhede
    @Nilesh_Narkhede 3 роки тому +1

    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 ?

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +1

      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.

  • @valour.se47
    @valour.se47 3 роки тому +1

    There's a term called Bounded Context, if you understand it, i am sure you will have easy time making decisions regarding microservices.

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому

      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.

    • @valour.se47
      @valour.se47 3 роки тому +1

      @@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

  • @impactcoders5996
    @impactcoders5996 3 роки тому +1

    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?

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому

      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.

    • @impactcoders5996
      @impactcoders5996 3 роки тому +1

      @@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.

  • @galonge
    @galonge 3 роки тому +2

    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.

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +2

      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.

    • @galonge
      @galonge 3 роки тому +1

      @@DevOpsToolkit Makes sense. Thanks!

    • @gigiduru125
      @gigiduru125 3 роки тому +1

      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.

    • @Xetius
      @Xetius 3 роки тому +1

      @@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

    • @skipdigit
      @skipdigit 3 роки тому +1

      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.

  • @chandup
    @chandup 3 роки тому +1

    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

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +2

      Will do. Adding it to my TODO list...

  • @yasirkaram
    @yasirkaram 3 роки тому +1

    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

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +1

      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.

    • @yasirkaram
      @yasirkaram 3 роки тому +1

      @@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

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +2

      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.

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +1

      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.

  • @thinkdevops6534
    @thinkdevops6534 3 роки тому +1

    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!

  • @EmilDafinov
    @EmilDafinov 4 місяці тому +1

    "We do not create a microservice that is communicating with the database" 😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭 Why, oh why does every employer ask me to do that then😭😭😭

  • @pawegraczyk6050
    @pawegraczyk6050 3 роки тому +3

    Microservices does not have to be "small". Whatever that means.

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому +3

      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.

    • @pawegraczyk6050
      @pawegraczyk6050 3 роки тому +1

      @@DevOpsToolkit I agree on that.

  • @benitoprijs2869
    @benitoprijs2869 3 роки тому +1

    Very recognizable, thanks again for this fun video! Cool t-shirt btw...

  • @dmytroshchotkin2939
    @dmytroshchotkin2939 2 роки тому +1

    It's a nice passionate speech! =)

  • @trevordavid7697
    @trevordavid7697 Рік тому +1

    You are amazing!

  • @OlegKorsak
    @OlegKorsak Рік тому +1

    but hey... what if I'm alone? Does it mean I will never have microservices?

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +1

      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 :)

  • @vugardzhamalov8479
    @vugardzhamalov8479 3 роки тому +1

    Dear Victor what an amazing content you provide us with in your channel! Thank you!

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому

      Thanks Vugar.
      Any suggestions for a topic I should explore in one of the upcoming videos?

    • @vugardzhamalov8479
      @vugardzhamalov8479 3 роки тому +1

      @@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!

    • @DevOpsToolkit
      @DevOpsToolkit  3 роки тому

      @@vugardzhamalov8479 You mean something like ua-cam.com/video/Jq8MY1ZGjno/v-deo.html

    • @vugardzhamalov8479
      @vugardzhamalov8479 3 роки тому +1

      @@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

  • @sauravadhikari8645
    @sauravadhikari8645 3 роки тому +1

    You are one of the best developer youtubers out there.
    1 like, comment and subscribe from me.

  • @PflanzenChirurg
    @PflanzenChirurg 3 роки тому +1

    Instantly subscibed

  • @ricardomaraschini9517
    @ricardomaraschini9517 3 роки тому +1

    My dude!

  • @haralc
    @haralc Рік тому +1

    Let me complicate things more .... should microservice have it's own repo?? 😂

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому

      personally, i prefer multirepo approach with each micro service being in its own repo. Others are going for monorepo.

  • @jonassteinberg3779
    @jonassteinberg3779 2 роки тому +1

    So then if you need a frontend lol how tf do you do that as a microservice??? Asking for a friend 😉

    • @DevOpsToolkit
      @DevOpsToolkit  2 роки тому +1

      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.

  • @val_ezresponse
    @val_ezresponse 2 роки тому

    this is not really an explanation, just a boring rant