Writer: Surajdeep Singh
Editor: Austin Lang
Reviewer: Christina Lewis
I enjoy collecting vintage sneakers and have a collection of about 14 to 15 pairs. I’ve made it a personal mission to purchase at least three new pairs a year.
If you share my love for sneakers, I want you to imagine yourself as the owner of a brand-new vintage sneaker business. You’ve built all the right connections, gotten your stock in order, and are ready to build a killer app.
The question is, should you opt for a monolithic or microservices architecture? If this sounds like Greek to you, in a monolithic architecture, all components of your app (such as the frontend, backend, and database) exist within a single codebase.
On the other hand, you can opt for a microservices architecture.
In a microservices architecture, your app is segregated into services that are responsible for a specific feature of your app (such as user authentication, listings, and payments).
In my opinion, you should start with a monolithic architecture, as they’re easier to develop and deploy initially, and swiftly transition to a microservices architecture when your app is expected to grow significantly.
A hybrid approach isn’t a bad idea either. Either way, I don’t expect you to decide straight away. Our journey together may not be a long one, but I guarantee you, by the time it ends, you’ll take to microservices like a fish to water!
-
Navigate This Article:
How Microservices Work
Let’s connect the dots: if we consider the vintage sneaker business app as a “service”, the smaller, independently functioning units it’s broken down into in a microservices architecture are called… drum roll… microservices.
The true beauty of microservices architecture lies in its independence — each microservice can be built, deployed, and scaled independently.
For example, if a microservice like sneaker listings is experiencing an exceptional surge during a holiday sale, it can be scaled up by a microservice management specialist such as Kubernetes in a jiffy!
You may be wondering, “If microservices operate on their own, how does the service work as a whole?” It’s obvious that microservices need to communicate with each other to pass requests and responses between them.
I mean, how else would you convert potential buyers into customers (think of the purchase lifecycle)? This communication is possible through Application Programming Interfaces (APIs) — they act like microservice “messengers”.
Key Components
Can you imagine driving on a road that doesn’t have traffic lights or a traffic cop? Someone is bound to get into an accident and things could get nasty.
Similarly, APIs need a traffic cop in the form of an API gateway to route them to the right microservice. For example, if one of your users wants to log in to your app, the API gateway will route that API request to the user authentication microservice.
If the user wants to view their order history, the gateway will send that request to the orders microservice. Now, there’s something I want you to note here: the API gateway routes external user requests only.
So, what about internal communications between microservices? This is where service discovery comes into the picture.
Service discovery makes it possible for microservices to find each other on the fly — they’re constantly scaling or moving around.
For example, let’s say one of your users has added a sexy pair of retro Jordans to their cart and wants to check out. The orders service needs to communicate with the payments service to process the payment.
Service discovery ensures they can dynamically find each other’s location and get those sneakers to your user’s doorstep!
Note: Load balancers are a component of microservices architecture as well — they help distribute incoming traffic to servers with the most availability.
Key Benefits of Microservices
From the information I’ve shared, I’m certain you can think of at least three benefits of microservices, if not all four (some online resources may list more, but these represent the key ones).
I’ll be honest with you: I could only think of two off the top of my head (scalability and resilience and fault isolation) and I was super mad at myself when I read the other two. Yeah, I’m hard on myself at times.
Scalability
Microservices and containerization are like two peas in a pod. Let’s say you’re using Kubernetes, a platform to manage containers at scale (in this context, they’re lightweight units that run your microservices), to handle your app’s microservices.
Remember the holiday discount example I used for your sneaker business?
If the sneaker listings microservice is in hot demand, you’ll need more resources — AKA containers — to handle the sudden surge in traffic.
In this situation, Kubernetes can spin up new containers to handle the traffic spike, without affecting other microservices.
When the demand subsides, it can scale down.
Flexibility in Technology
Since each microservice operates independently, you have the freedom to use different programming languages and tech stacks for each one.
For example, you could use Node.js or Python for user authentication and authorization because they’re easy to use and integrate, and Python or Java for the sneaker product catalogs, since they’re ideal for heavy lifting.
Building a tech stack for a microservices architecture is indeed an exciting challenge!
Faster Development Cycles
Faster development cycles, you say? You may argue, that in the case of a monolithic architecture, you can still divide the codebase into smaller parts and distribute the workload among your team.
What you aren’t taking into consideration is that if you need a new feature or if there’s a bug to fix in one part, any changes you make affect the whole codebase.
In a microservices architecture, each microservice has its own codebase, database, and sometimes even programming language — this speeds up development and deployment. It’s as simple as that.
Happy employees, happy customers.
Resilience and Fault Isolation
Another benefit of operational isolation is isolated failures, preventing total application downtime. In layman’s terms, if the payments microservice fails for some reason, your users can still browse for sneakers and add them to their cart.
Once the payment system is back online (the faster, the better), they can check out. While I get your users might be a little frustrated, at least they can use some parts of the app!
Of course, if the user authentication portal is down, you may be in for a rough time!
Common Use Cases for Microservices
What do tech giants like Amazon, Netflix, YouTube, Capital One, and JPMorgan Chase have in common? Apart from the fact that each rakes in millions quarterly, they all use microservices in some capacity.
Microservices architecture is commonplace in eCommerce, streaming platforms, and banking and financial institutions.
I’ll use the examples of these high-profile companies to break down how they’re benefitting from it.
eCommerce Websites
Amazon is one of the pioneers of microservices architecture, having transitioned from a monolithic architecture in the early 2000s.
By using microservices to handle features like product search, inventory management, checkout, user authentication, and recommendations separately, Amazon can rapidly develop, deploy, and scale these microservices independently.
It has a market cap of nearly $2 trillion for a reason. Yes, trillion.
Unless your eCommerce business is small or medium-sized, a microservices architecture is a must.
Banking and Financial Services
I think you know where I’m going with this: banking and financial institutions use separate microservices for accounts, transactions, and analytics.
JPMorgan Chase, one of the world’s largest banks, uses microservices for its financial products, trading platforms, payment services, and customer engagement tools. This enables it to respond to market changes as needed.
I believe microservices are an absolute no-brainer in this sector.
Streaming and Media Services
Netflix has millions of users worldwide, and realized it needed to move to a microservices architecture in 2008 to better handle its audience.
More than 1,000 microservices later, Netflix is the world’s most popular streaming service, with almost 300 million subscribers.
I’ve watched more than 100 movies and shows on the platform, so I have nothing but praise for it.
Media delivery is one of the key areas where Netflix uses microservices — they allow Netflix to scale rapidly to handle millions of simultaneous streams, especially for global events or new releases.
Microservices vs. Monolithic Architecture
One of the standout differences between microservices and monolithic architecture is fault isolation — if any critical part of the app goes down, it can affect the entire system.
Basically, it’s sink or sail with monolithic architecture. But it’s not all gloomy if you can’t implement microservices for your app — if you’re a budding entrepreneur, it’s best to start small and transition to the big leagues when you’re ready — like Chelsea academy players.
Yes, I said it: microservices architecture is where the big boys play. To back this statement, here’s a list of the differences between the two architectural types in the form of a table:
| Feature | Microservices Architecture | Monolithic Architecture |
|---|---|---|
| Components | Multiple, independent microservices working together | One large, integrated application |
| Communication | APIs | Internal method calls |
| Development Complexity | More complex | Simpler initially |
| Scalability | Scales microservices independently | Scales the entire app together |
| Deployment | Independent deployments | Entire app must be deployed at once |
| Tech Stack | Different stacks for different microservices | One stack for the whole app |
| Fault Tolerance | Failure in one microservice doesn’t affect others | Failure in one part can bring down the whole app |
| Scaling Costs | Cost-effective | Expensive |
I’m not a bully, so I’m not going to peer pressure you into opting for a microservices architecture from the get-go. Begin your journey with a monolithic architecture and when you’re ready, get yourself a team that can whip up microservices for you.
Challenges of Adopting Microservices
Khichdi is a classic Indian dish made with rice, lentils, and numerous veggies (in my preferred version, anyway).
To prepare it, all you have to do is toss the right proportions of these ingredients (and an assortment of masalas) in a pressure cooker and let the steam work its magic. You can compare a monolithic architecture to khichdi.
Now, preparing rice, lentils, and veggies separately may take more time and effort, but it’s guaranteed to taste better (especially with a mango pickle!), just like microservices.
Complexity in Communication
Have you ever been to an orchestra? If you haven’t, I’m sure you’ve watched a video or two on YouTube. I went to an orchestra with a friend in June of last year, and it was a powerful experience.
Let me tell you, the conductor has their job cut out for them! When you’re dealing with multiple microservices, you have to grab your conductor’s baton to keep everything in sync. One misstep in this complicated dance could cause a domino effect of issues.
Data Management
When you break up your app into multiple microservices, each one has its own database. This means you have to handle distributed data and ensure data consistency.
We all have that one close friend who almost always replies to texts late, right? Well, your app can’t afford to be friends with them anymore — you need real-time data across your microservices.
While this distributed data model can be tricky to manage, I know you have what it takes.
Increased Operational Overhead
Alongside having their own databases, each microservice also has its own infrastructure, deployment pipelines, and monitoring. It’s like having multiple mini-apps to deal with. And you know what that means — higher costs.
You need to ensure you do each microservice justice. For example, if you don’t set up proper monitoring, debugging becomes like finding a needle in a haystack.
Security
I just want to make it clear, I’m not trying to steer you away from microservices — I’m just trying to explain what you’re dealing with. So I’m not going to call security management an issue.
Let’s just say managing permissions, authenticating users, and ensuring sensitive data is encrypted across all the communication channels is challenging. I suggest creating a comprehensive overall security strategy and doing all it takes to uphold it.
Tools and Technologies for Microservices
By choosing the right toolkit for your microservices, you can certainly make your life easier. You’re no stranger to Kubernetes — just revisit the holiday discount example to refresh your memory.
To simplify things, microservices and containers are a match made in heaven and Kubernetes is a godlike figure for them — the platform allows you to package microservices into containers and easily deploy, manage, and scale them.
This brings me to another crucial component of the jigsaw puzzle: Docker.
Docker
Now, Kubernetes on its own can’t create containers — this is where a container runtime tool like Docker comes into the frame.
You can imagine Kubernetes as a Ferrari with an engine. I mean, what good is a car without an engine, be it a Ferrari or a Ford? Docker brings the Ferrari to life because, make no mistake, Kubernetes is as good as it gets for container orchestration.
Service Meshes
Service meshes are another must-have for your Kubernetes configuration. Microservice-to-microservice communication is riddled with complexities… if only you had a trusty “traffic cop” to step in and control how they interact with each other.
This is exactly what service meshes like Istio, Linkerd, and Consul can do for you — they act as a smart traffic system for all communication that goes in and out of your microservices.
And the best thing is, these tools integrate seamlessly with Kubernetes.
CI/CD and Monitoring Tools
I also recommend CI/CD tools like Jenkins to streamline and support the building, testing, and deployment of microservices and monitoring solutions like Prometheus and Grafana to track the health, performance, and overall behavior of your microservices.
Did you watch Bob the Builder as a child? Well, if you did, let’s just say if Bob were building an app, these are all the tools he’d need to make you go “wow.”
Implementing Microservices: Best Practices
Every building needs a solid foundation. Whether you’re just starting out or looking to improve your existing setup, these key considerations should help you build microservices that are efficient, scalable, and easy to manage:
- You should design your microservices based on specific business capabilities — don’t blur the lines. For example, you should have different microservices for managing customer orders and processing payments. This approach allows each service to evolve independently without affecting the others.
- Your API management game needs to be top-notch and make sure your APIs are well-documented — for example, the last thing you need is for your developers and teams to be scrambling for information when they need to troubleshoot issues.
- Just to re-emphasize, you need to have robust monitoring and logging in place to track the performance of your microservices and catch any potential issues early. Like most problems, the earlier the diagnosis, the sooner the potential cure.
- Finally, keep in mind, while microservices operate independently, they’re part of a single system (your app) and often rely on each other. If one fails, for example, the entire system could be brought down… unless you implement patterns like circuit breakers and timeouts to handle failure gracefully.
Even if you’re a casual reader who has nothing to do with application development, you’ve learned one of the greatest lessons in life today: handle failure gracefully. It’s all a learning experience.
Final Thoughts: Are Microservices Right For You?
As much as I like microservices, I’d advise you to start with a monolithic architecture for your business. A single codebase for your business is easier to develop initially and when sales are picking up, and you’ve got your hands in all the honey pots, step up your game.
Because when I said microservices are meant for the big leagues, I meant The English Premier League, La Liga, Serie A, and Bundesliga (I’m a huge football guy) — every football player dreams of playing in these leagues. And you should too.
Mind you, if you have a solid budget and an experienced team, by all means, start with microservices. A hybrid approach isn’t a bad idea either — Hannah Montana (AKA Miley Cyrus) knew what she was talking about when she sang, “The Best of Both Worlds.”
