 My name is William. I'm part of the product marketing team here at GitLab. And today we are talking about microservices. So with that, I would like to share one of my windows and show a page I recently created about microservices and I'll talk through this page today. So if you go to the GitLab homepage under resources, you can find topics. And here we have several pages that talk about various industry topics. And today I'll be going through this microservices page. So in addition to this video, the page itself is a resource and we will continue to add content to this page. So the first question is really what are microservices? And so here are some microservices are a modern software architecture. And so it's how you're designing or architecting your software application where rather than having a single application, what you're actually doing is splitting that into many smaller component services. At a high level, this allows teams to innovate faster and to achieve massive scale, although there are a lot of benefits and a lot of challenges to microservices that I'll cover as we move on. So at a high level, the easiest way to understand what a microservice is, is to compare it to a monolithic application architecture. And so in a monolith, you have a single application. This is usually a single code base. This is usually written in a single programming language with a single database, et cetera. You can kind of get the idea here that everything in a monolith is all in one place. And that means all of the developers in the organization are all working on this one code base. And even though they might have different bits of functionality, so these different shapes here, this might represent the user authentication component or part of that application. And this might represent the UI. And this might represent some other type of business logic. And if things wanna change in the application in a monolithic architecture, those different teams need to coordinate with each other because one change to one part of the code base affects all of the code base. I'll give you an example. If all of your code is in one application, let's say you wanted to import a module and one of the teams wants to import version 1.8 of that module. But for another team, because of their dependency tree and the different parts of software that they depend on, if you upgrade to 1.8, it actually breaks their code. So their code relies on 1.7. So you can see here are two teams that are odds with each other because they're both using the same module as the dependency for their code, but they each want different versions for whatever reasons. And this is a problem with a monolithic architecture. All of that coordination, all that overhead, in addition to trying to deploy it, there are a lot of problems that exist with monolithic architecture. So a microservices architecture is where you take each of these components and you deploy them as their own application or really as a service. And a service has some other implications to it. So it usually means that there's some type of API that allows you to access that service. And within a microservices architecture, each of those services is meant to have one function. So you can see here that there are just a few individual here, but in reality, you could have five or 500 or even 5,000 microservices. 5,000 is probably a lot. Even folks like Uber, I think Uber has like 1,700 microservices. So you can imagine as you start to break these things apart and each component of the code becomes its own thing. This gives you a lot of advantages. It means that you now can just deploy that one thing. And whatever dependencies, whatever type of data model you wanna use, whatever type of database, each service can have its own storage. That team can make that choice. So you can have one team who develops in Node.js and another team that develops in Python and another team that develops in Scala and each is building their own service. And so you get this advantage of being able, each team being able to own their own service, each team being able to deploy dependently, each service being able to be upgraded independently. And you can see how this can help you scale because this part of the service, this is larger, and this might represent running either on a larger VM or potentially maybe there's more instances. So maybe this is say like the authentication service that gets hit a lot of the user service that gets hit a lot. So you need a lot more instances and a lot more power here. Whereas this might be a smaller part of the service that can run on a smaller bit of hardware. So each service can now be scaled independently as opposed to a monolithic application where in order to scale that out, you need to create copies of everything. So you could see if you wanted like five copies of this, you also need five copies of this, which you might not need in a microservices architecture kind of handles that. So at a high level, those are some of the differences between a monolith and microservices. A great resource that I highly recommend reading is Martin Fowler. This is the quintessential article on microservices. And in it, he kind of says like microservices, it's a bit of a buzzword or a bit of a term that nobody has a strict definition for. It's kind of like a DevOps, right? Everybody has a different definition. So in his research and in his industry knowledge, he's come up with these nine things that he feels are common to all organizations or to most organizations that are doing some type of microservices. They usually have these nine things. And I wanted to highlight some of these because it comes into play when you start asking the question, okay, well, if I'm either a startup that wants to do microservices, which there are a lot of reasons for startups to even start your microservices or in particular an enterprise that wants to adopt a microservice architecture, why would I want to use GitLab? Or what advantages does GitLab have if I'm employing microservices? And so as you look at some of these components of a microservice or attributes of a microservice, you can see that GitLab can really help with several of these. So one idea is this componentization by services. This is what I described above. This is the main idea that rather than a singular thing, you have each of these type of modular components. Another one is that they're usually organized around business capabilities. And I will pop over to the article as well because Fowler has some nice visuals. And I thought this one would be helpful. And rather than just copying all of his visuals, I just linked his resource because it's great. So you can see in a traditional enterprise organization, they might organize teams based on like technology. So you have a UI team that just builds the UI and then you might have a middleware team that just builds those middleware components and you might have a team of database administrators. And so each of these are siloed by their function technologically. But more typically in a microservices architecture, which should be familiar to us because this is also similar to DevOps. When you move to DevOps, DevOps and microservices go together like peanut butter and jelly. Instead, you usually have a team that owns a service end to end. So they own the UI, they own the data model, they own everything about that service. So a single team will usually own that service end to end and own the uptime for that service. And so you have a cross-functional team. So that's one of the cultural differences as folks move to microservices. Another concept is products versus projects rather than I'm building this new feature and it's a project and it's gonna take two quarters and then we're done with that and we move on to something else. As you have these cross-functional teams that own a service end to end, that becomes a product for them. So they might own the user service and they own it long-term. It's not just a project, it's more of a product for them. Smart end points and dump pipes. If anyone is familiar with another term called SOA or services-oriented architecture, there's probably some contention between the term microservice and SOA. I'm gonna give you my opinion on it. My opinion on it is that SOA is just a bit of an earlier or an older term and that microservice is a newer model and one of the differences between those two is that in an SOA model, which is a services architecture, the difference was you had a lot of this middleware. So this would send data over to here and that middleware would do a lot of translation of that data or the pipe itself was smart as it was translating things. And microservices is a bit different. All the intelligence is at the edge, is in the end points. And so you use dump pipes. And so in particular, most microservices are just built on HTTP. So the same technology that runs the internet or that actually the internet in general, that's too many protocols that runs the web like your web browser. So the same way you make an HTTP request to a web server to receive your web page, HTTP is the protocol and the mechanism that most or in many microservices employ as the API mechanism. And so there are other protocols you can use, but the idea is smart endpoints dump pipes, decentralized governance. I don't wanna talk through all of these, but one that is key here is infrastructure automation. So as you move from a monolithic application, that deployment cycle can be very manual here. I have a bit of code and everybody commits their code. We do a code freeze and now we're gonna do a release and we cut a release. And then the operations team deploys that one monolithic application. When you move to microservices, you really just can't handle it. If you could imagine doing that process for let's say 1700 microservices that Uber has, it just would be impossible for an operations team. So instead you need to automate that deployment process. So continuous integration, continuous delivery and continuous deployment become a critical part of doing microservices. You really can't employ a microservices architecture at any type of meaningful way without automating your infrastructure and without doing CI CD. And so there's some other components here for the sake of time. I'll just point to the article. He also gave a talk on it. I've linked the video. That's a really good video to watch. So at a high level here, engineering teams reap some benefits of microservices. So essentially what you're doing is you can imagine this is a lot more complex than this. This is simpler, easier to design, easier to deal with, easier to deploy. This becomes a lot more complicated. So there are trade-offs. So by accepting more complexity, you are gaining some of these other benefits. So the benefits that you would gain would be that services can scale independently. Talked about that a little earlier. Individual services can fail without taking down the entire application. You can imagine if your application is what makes you money. Let's say you have an online store and an e-commerce application. As long as your application is running, you can take orders. But if one component fails, let's say there is a recommendation algorithm that recommends products for you to buy. In a monolithic application, if that recommendation component fails, the entire app goes down and you're not making any money. But you could completely imagine that in a microservices architecture, where each of these services is independent, if the recommendation engine fails, your website can still work. You can still take orders. It's just this one little component may not be working at that time. So real advantage of microservices. This is a big one I talked about. Earlier teams can choose their own technology stack. You can have somebody who uses a MySQL database and another team is using a NoSQL database. And another team is doing some other type of caching. Each can choose their own stack, their own language that they write in. As long as the API between the services is consistent, each team can choose their own technology stack. So this allows you to attract and retain more talent. This allows you to build faster, et cetera, et cetera. Functionality can be tested and swapped out more easily. That if you wanted to test a new recommendation engine, instead of having to build it into one application and deploy that entire application to test a potentially good or potentially bad new recommendation engine, instead you can just A-B test that service. You can send some traffic to the test and continue routing off of your recommendation engine that you know that works. So you can test and swap functionality easier. And the huge one of course is developer productivity. Developers can ship faster and they tend to be happier when they own their domain. You can imagine a team owns their service, they own it end to end, they pick their technology, they can run faster. So there are of course some business value, faster pace of innovation, as I've kind of talked about, business being able to move faster, be competitive in the marketplace, greater stability and resiliency. So a lot of times we talk about moving to new technology or digital transformation or modernization. And we'll say the reason to modernize or the reason to go through digital transformation is to move faster. And that's true. You do get a faster pace of innovation. It's very important. But for many initially enterprise organizations, moving to better technology, I say better, but moving to more modernized technology, it's not just about moving faster, but it's actually about running more stable. It's about being more predictable. It's about having less downtime. Those can be a lot of times suffering less downtime is actually less loss of revenue than shipping new things. Greater scale, the software keeps up with business demand. And of course lower costs even. So because your infrastructure is tailored to each service, you don't have to speck out a bunch of infrastructure that you don't need. So just to move quickly along because I do wanna get some time for Q&A, talking about using GitLab with microservices. There are several benefits I have to reformat this a bit, but of course built-in CICD. Infrastructure automation is critical. And so the fact that GitLab is built-in CICD makes it perfect for migrating or adopting microservices, migrating to or adopting. Our built-in container registry in Kubernetes integration. Kubernetes and containers are really, really helpful for microservices for many reasons in terms of the automation, in terms of immutable deploys, orchestration, et cetera. So the fact that GitLab integrates and works really well and designed around these technologies makes it excellent. Of course, when you have a single application and you wanna know what's happening with my application, you've just got one place to go look, it's very easy. When you wanna say, where did my code break? You've just got one place to go look, it's very easy. When you start breaking apart into many services, now monitoring that network because the application itself is actually running across the network, monitoring that network and monitoring the interaction between those applications is absolutely critical. And so the fact that GitLab comes with built-in monitoring and packages Prometheus makes GitLab ideal for microservices is something critical. We have specific features because we embrace this architecture pattern. We have built features today and we're building features in the future. So these are things like multi-project pipelines. If each microservice is in their own project or their own code repo, being able to run a single pipeline across all of those repos, you can imagine can be helpful in a microservices. We have even shipped the ability to have what's called a mono repo. So one way to do microservices is each service has its own code repo and then you can run a pipeline across all those repos or many companies have what's called a mono repo where they have one code repository and each service puts their code in let's say a different folder within that or different directory within that code repo. And so you would say, I just updated my service. I don't wanna run a pipeline across the entire code base. I just wanna run a pipeline to test my service and you can do that. We've shipped that feature, I believe in 11.5, maybe 11.4. Group clusters, then we even have features on the roadmap, things like a global Docker registry, first class container builds and the ability to define multiple pipelines in a single CI YAML file. These are on the roadmap. So GitLab is great for microservices today and we're even shipping more functionality to make it better. So with all of that, I have some additional resources and links on this page. You can get to it from the topics page of GitLab. And with that, I'd love to stop sharing and stop the recording. Thank you to everyone on YouTube.