Microservices Will Finally Makes Sense After This Video... Part ~ 1

@thom.code

196.3K followers · usually 2.4K views a post

Views

55.0K

Likes

3.8K

Comments

269

SoundTikTok sound · original sound - thom.code

Promoted product

IntelliJ IDEA

JetBrains is a cutting-edge software vendor specializing in the creation of intelligent development tools, including IntelliJ IDEA – the leading Java IDE, and the Kotlin programming language.

4 videos2 creators

Why it worked

The video effectively breaks down a complex technical concept (microservices) into easily digestible parts using clear visuals and analogies. It addresses a common pain point for developers and businesses (complexity of monolithic applications) and presents microservices as a logical solution, making the information valuable and shareable.

Summary

This video explains the concept of microservices by contrasting it with monolithic architecture. It illustrates how monolithic applications become complex and risky to update over time, leading to the need for microservices, which break down applications into smaller, independent services.

Structure

1Introduction to daily software updates by major companies
2Explanation of monolithic architecture for e-commerce apps
3

Original caption

Part 1 ~ Microservices Will Finally Makes Sense After This Video In this video, Cloud X Berry explains microservices in a simple and beginner-friendly way. Amazon, Netflix, Uber and Spotify ship software updates every single day — and millions of people keep using those apps without ever noticing. That is not luck. It comes down to how the backend is put together, and one of the most popular patterns behind it is called microservices. We start where every application starts: one project, one code base, deployed as one thing. That is a monolith, and for a small app it is genuinely the right choice. Then the team grows, the code base grows, and a three-line bug fix in notifications means rebuilding, retesting and redeploying the entire application. That is the problem microservices were designed to solve. From there we build the idea up piece by piece: splitting by business capability rather than at random, why the split lives in the backend and never touches what the user sees, what actually happens between services when you click Place Order, and what an API contract really is. Then the three advantages that matter — independent deploys, independent scaling, isolated failures — followed by the trade-offs most explainers skip. CHAPTERS 0:00 Why you never notice an update 0:24 How applications were traditionally built 0:43 One project, one code base: the monolith 0:59 Where the monolith starts to hurt 1:43 What microservices actually are 2:14 Splitting by business capability 2:45 The misconception: backend, not the UI 3:09 One click, several services 3:37 What an API really is 3:59 The API contract 4:39 Advantage 1: deploy independently 4:56 Advantage 2: scale independently 5:17 Advantage 3: failures stay isolated 5:54 The trade-offs nobody mentions 6:27 Start with a monolith, move when you grow 6:39 The one thing to remember WHO THIS IS FOR Developers hearing "microservices" in every architecture conversation and wanting the idea to actually click, backend engineers weighing up a split, and anyone interviewing for a role where system design comes up. #microservices #systemdesign #softwarearchitecture #backend #api

More from @thom.code

On-screen text

Microservices Will Finally Makes Sense After This Video... Part ~ 1 Every day, companies release software updates COMPANIES LIKE amazon NETFLIX uber spotify EVERY DAY NEW FEATURES BUGS FIXED MILLIONS OF PEOPLE WITHOUT EVEN NOTICING THE ANSWER ? POPULARITY ARCHITECTURAL PATTERNS MICROSERVICES First, how applications were traditionally built MICROSERVICES LET'S FIRST LOOK AT HOW APPLICATIONS WERE TRADITIONALLY BUILT TRADITIONALLY BUILT MICROSERVICES Imagine you are building an e-commerce application FAIRLY SIMPLE Login, catalog, cart, orders, payments, all in one app E-COMMERCE APPLICATION USER LOGIN PRODUCT CATALOG SHOPPING CART ORDERS PAYMENTS NOTIFICATIONS INVENTORY Everything inside a single project, deployed as one application ecommerce-app/ app/ auth/ catalog/ cart/ orders/ payments/ inventory/ package.json SINGLE PROJECT DEPLOY ONE APPLICATION This type of architecture is called a monolith MONOLITH FOR MANY APPLICATIONS IT IS ACTUALLY THE BEST PLACE TO START As the business grows, the application grows with it THE APPLICATION GROWS 22 MORE DEVELOPERS 48 MORE FEATURES ADDED The code base becomes much larger, and then you discover a bug CODE BASE MUCH LARGER NOTIFICATION FEATURE A SMALL BUG A few lines changed, but you still deploy the entire application WHAT ACTUALLY HAPPENS LINES CHANGED TEST DEPLOY THE ENTIRE APPLICATION One feature changed, but every feature is part of the same deployment DEPLOYMENT PAYLOAD NOTIFICATIONS 1 OF 6 CHANGED ONE DEPLOYMENT Over time releases become slower and every change becomes riskier VS THE CODE BASE GROWS TIME RELEASES TESTING EVERY CHANGE Different teams working in the same code base, where one change affects another GET USER CODE BASE ELEMENT LOGIN ORDERS PAYMENTS NOTIFICATIONS ACCIDENTALLY Exactly the problem microservices were designed to solve THE PROBLEM MICROSERVICES DESIGNED TO SOLVE We divide it into multiple smaller backend applications BACKEND APPLICATIONS 5 SERVICES LOGIN ORDERS PAYMENTS INVENTORY NOTIFICATIONS MULTIPLE SMALLER APPLICATIONS Each one is responsible for a single business capability RESPONSIBLE FOR A SINGLE BUSINESS CAPABILITY For example, one service manages users, another processes payments MANAGE USERS MANAGE ORDERS PROCESS PAYMENTS MANAGE INVENTORY SEND NOTIFICATIONS Each of these independent applications is called a microservice INDEPENDENT APPLICATION IS CALLED A MICROSERVICE

Transcript

Every day, companies release software updates. Companies like Amazon, Netflix, Uber, and Spotify release software updates. Features appear, bugs get fixed, all without even noticing. Millions of people continue using these applications without even noticing. That is possible? One of the most popular architectural patterns behind it is called microservices. First, how applications were traditionally built. Let's first look at how applications were traditionally built. Imagine you are building an e-commerce application. In the beginning, it's fairly simple. Login, catalog, cart, orders, payments, all in one app. Everything inside a single project, deployed as one application. This type of architecture is called a monolith. For many applications, it is actually the best place to start. As the business grows, the application grows with it. More developers join the team, more features are added. The codebase becomes much larger, and then you discover a bug. Notification feature. A small bug. A few lines changed, but you still deploy the entire application. What actually happens? Lines changed. The entire application. One feature changed, but every feature is part of the same deployment. One deployment. Over time releases become slower and every change becomes riskier. Releases. Testing. Every change. Different teams working in the same codebase, where one change affects another. Get user, code base. Element: Login, Orders, Payments, Notifications. Accidentally. It's easier for one change to accidentally affect another feature. Exactly the problem microservices were designed to solve. The problem. Microservices. Designed to solve. Instead of building one large backend application that does everything, we divide it into multiple smaller backend applications. Backend applications. That does everything. Multiple smaller applications. Each one is responsible for a single business capability. Responsible for. A single business capability. For example, one service manages users, another processes payments. Manage users. Manage orders. Process payments. Manage inventory. Send notifications. Each of these independent applications is called a microservice. Independent application. Microservice.