Why Amazon, Netflix, and Uber prefer Microservices over Monoliths

Nigel Pereira finds out why big tech moved from monolithic applications to a superior form of programming in the form of microservices

A famous Mark Twain quote reads “The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and starting on the first one.” That’s precisely the point of switching to microservices from monolithic applications that are getting too large or too complex to handle. Monolithic applications or “Monoliths” are software programs written and deployed as single units. While this is how most programs were developed in the past, a lot of organizations still use monoliths today as they are a lot simpler to manage.

What’s wrong with Monoliths?

Unlike modern software applications that are made up of numerous modular parts that can be added, removed, or upgraded independently, a monolith consists of one single codebase with all its functionality internalized. A basic analogy here would be the difference between a simple machine like a crowbar made up of one single part, and a complex machine with many parts like a bicycle. If a crowbar is ruined you can’t really do anything about it but with a bicycle, there are a lot of parts that can be removed, repaired, or replaced.

Similarly, with software, Monoliths function like black boxes where all the functionalities are interdependent on each other and can’t be modified without affecting everything else. The Amazon app, for example, used to be a two-tier monolithic application where all the components were tightly coupled together. The problem with this model is that as you get bigger and start scaling up to meet demand, you can’t really upgrade anything without tearing it all down first. Amazon achieved this by decoupling all functional units from the monolith that served a single purpose and then wrapping them in APIs that allow them to function independently of each other.

Divide and Conquer

Microservice architecture refers to the practice of treating every function of an application as an independent service. For example, on an e-commerce platform like Amazon or Shopify, or eBay, your ‘buy’ button would be one function, there would be another function to add your item to the shopping cart, and there would be yet another function to calculate the tax, and so on and so forth. This would be in addition to a function that would check inventory, a function that would check current prices, and maybe even a function to make recommendations. With Microservice architecture, each of these functions can be run, managed, upgraded, and modified without affecting the live system.

Microservices make everyone’s life easier by breaking applications down into separate functionalities that can be run, managed, upgraded, and modified independently of each other. In the case of Netflix, a massive breakdown in 2008 that caused several days of downtime led them to shut down their own data centres and migrate everything to AWS. This also led them to break up their monolith into 700 different microservices, each responsible for one functionality. This allowed them to independently scale services without having to upgrade the entire monolith.

Service Mesh Tools

While Microservice architecture is ideally deployed via containers, the newest unit of software we’ve covered extensively in a previous post, microservices can also be deployed as VMs. There is also an entire ecosystem of apps and tools that help manage and monitor microservices, the most popular of which are the service-mesh tools that provide microservices with a dedicated network to communicate with each other. Not to be confused with APIs that help microservices communicate with the outside world (user-to-service), service meshes help microservices support each other by providing them with a dedicated network for communication (service-to-service).

Istio and Linkerd are considered among the best service mesh tools that help abstract away the complexities associated with managing connections for hundreds of different microservices. Service meshes also record performance metrics which make it possible to locate problems. With modern applications typically consisting of hundreds of microservices running thousands of instances in containers that are in a constant state of change, managing service-to-service communication is just impractical without a service-mesh. The popular ride-hailing app Uber shifted to Microservice architecture in 2014 when they outgrew their monolith and have since built their own service mesh called Uber Catalyst.

Simplifying Complexities

The modern enterprise is all about simplifying procedures while abstracting away complexities and having a lot of smaller problems that can be tackled independently is a lot better than having one giant mountain of a problem where you don’t even know where to start. Microservices make it possible to scale up applications as per modern-day demand while still maintaining the simplicity associated with dealing with a monolith. This is because you’ve essentially broken down your application into hundreds of “little monoliths” each of which can typically be managed by a relatively small team.

In case you missed:

• TikTok parent company creates KubeAdmiral for Kubernetes
• This single-cell organism is smarter than a human
• Introducing Nvidia’s L4 GPU profiles in the cloud
• In the realm of Shadow, Zombie, and Rogue APIs
• NavIC, India’s Aatmanirbhar answer to GPS
• Meet Einstein Copilot, Salesforce’s new conversational AI
• This Device can Actually Record Your Dreams Like a Movie!
• Thoughts of superbugs keeping you up at night? AI vs. HAI
• A chip in the brain helps a man with paralysis walk again
• AI in the Field of Scientific Discovery, Are We Ready?