The Flipside of Microservices: Knowing When to Embrace or Pass

Many teams explore the idea of breaking their applications into smaller services. This brings up a question: are they doing this to create a complete Microservices system, or just trying out the idea of making smaller apps to make them easier to handle? But going into the world of Microservices can be complicated and tricky, needing careful planning and a lot of effort to set up the necessary tools and structure to make it work well.

However, at the heart of “Microservices” is a really interesting idea – it’s a way to create apps that can grow and adapt easily, especially when it comes to handling more users. But there’s still a puzzle to solve: are these Microservices good for everyone? suitable for all situations? And as time goes on, what problems might come up when it’s about keeping everything working smoothly?

Breaking Things Down

Microservices break down apps into smaller, specialized parts. This is great because you can work on one part without messing up the whole project. It speeds up development and lets teams work independently on different parts, which is awesome for scaling things up.

But, here’s the thing: Microservices mean lots of separate projects. That means separate repos, setups, and rules to manage. If you’ve got a bunch of these Microservices, it’s like trying to remember which remote controls belong to which gadgets. Keeping everything updated and in line can turn into a puzzle that’s not always fun to solve.

Real challenge is “how granualar should teams or companies go in breaking down the larger application or system?”. When a team that is responsible for a decent size application decides to break it down into many smaller size apps (with the idea of Microservices), that will soon become challenging for the long run.

Puzzle of Micro-Frontends

Picture this: you take the idea of “Microservices” and apply it to how the front part of a website works – the micro-frontends. Sounds cool, right? It offers flexibility and lets you reuse things.

Now, imagine this: instead of having just one big piece, you break it down into lots of tiny pieces. Each of these pieces has its own place to stay (code repository), its own way of being built (language, framework, version, etc.), and its own path to get out into the world (deployment). The process of working on them locally, testing them, and getting them ready to show to the world? It’s like getting caught in a web of complexity. And here’s the twist – it can become pretty tricky for the developers to keep up with all these small front-end pieces.

It’s like trying to keep track of a whole bunch of puzzle pieces, each with its own unique shape and place.

Tackling the Puzzle of Updates & Upgrades

Imagine being in a situation where you’re tasked with updating a foundational library that’s spread across multiple microservices. This whole affair is often triggered by the stringent demands of InfoSec or Security & Compliance standards. You’re looking at upgrades for Node or Ruby, possibly a shift in Rails, and don’t forget those client library upgrades to keep up with the shifting sands of services like RDS/MySQL/PostgreSQL, message brokers, and versions of other application dependencies.

But here’s the kicker: what looks like a simple update job can quickly turn into a complex process of testing and checking. Each of those microservices has its own set of needs and things it depends on. And this is where things get tricky – making sure that all these pieces fit together without causing chaos.

And let’s not even start talking about the sheer number of tasks that suddenly pile up on your to-do list. It’s not just one or two tasks – you’re looking at a bunch of them, all waiting to be taken care of. Now, the team that’s already familiar with these new microservices might handle it fine, but for those who are new, it can be a lot to handle. The flood of tasks, the growing list of releases, the planning, the constant testing – it can get pretty overwhelming.

It would be great if there is great deal of automation for testing, releases (CI/CD) and a great source code branching strategy, etc. but let’s be real – as nice as that sounds, turning this into reality isn’t all that easy.

Transition Troubles

Imagine this: organizations have to think about moving their code homes from one place to another. Why? Well, maybe to save money or to have better ways (features) of working together.

Now, hold on tight, because here comes the real head-scratcher. Moving a big bunch of code is already kind of complicated, right? But what if you’re not just moving one thing – you’re moving lots of smaller things, like these microservices? That’s like adding an extra layer of confusion. Going from one platform to another, or trying to put all your code in one place, is like trying to solve a really tough puzzle. And you can’t afford to lose any of the puzzle pieces. It takes super careful planning and making sure everything happens just right.

The Crucial Role of Appropriate Tools and Setup

Imagine this: someone using your app says something isn’t working right. Now, where do you start looking to fix it? Is it in a main part of the app, or could it be in a separate part that does its thing later? Figuring out what went wrong in the whole process can be like solving a puzzle. Finding the real reason might take some time. It might not seem like a big deal at first, but it could become a bigger problem later. It all depends on how many parts your app has, how they talk to each other, how well you’re keeping track of things, and how easily you can see what’s happening.

But here’s the bottom line: if you don’t have the right tools and setup to manage all these parts of your app, then going for the microservices way might not be a good idea. It’s like trying to go on a big trip without the things you need for the journey. It can make things much harder than they should be, and you might not get the good results you were hoping for.

Striking the Balance

Here’s the deal: Microservices and micro-frontends aren’t magical solutions. Yes, they bring some powerful tricks, but they also bring some complications. Finding the right balance between being organized and being able to handle things is super important. You don’t want too many of these small services, or it might end up causing more problems than it solves.

Picking the Right Way to Build

When you’re thinking about how to put together your project, you’ve got to think it through. Here are some extra tips for making the right choice, especially for teams that are in charge of one or a few parts of a big company system:

1. Size and Complication: Think about how big and complex your application is. If it’s not too huge, you might just need to keep it the way it is. Or maybe split it into 2 or 3 pieces. But don’t go wild. For big and complicated things, microservices work better.
2. Teams Doing Their Thing: If you’ve got different teams working on different parts, and they all want their space, microservices could be the way. But if your teams can cooperate without messing things up, keeping it all in one piece might be smoother.
3. Growing When Needed: If you’re planning for some parts of your app to grow a lot, extracting that as a separate service makes sense. But if growing isn’t a big deal and it doesn’t really add value to business, keeping everything together can be easier.
4. What You Know and Have: Think about what your team knows. Microservices ask for more knowledge about tricky things like distributed systems and how stuff is put together. Check if your team can handle it.
5. How Your Team Works: Take a look at how your team is set up and talks to each other. If your team is spread out and chatty, microservices could fit in. But if things are more centered, keeping it all as one might work better.
6. Right tooling and Infrastructure: Does your company have the right tooling (for build, deployments, code scanning, log analysis, transaction tracing, etc.)? If not, solve for that before attempting to break the app down into smaller sizes.

More Pointers

• If there’s a real, real need for breaking a big application into small pieces, think about just doing it a bit – like 2 or 3 pieces, not going all-in for Microservices.
• Microservices are something that needs a whole-company or org effort, not just a bunch of teams doing their own thing. You’ve got to think about finding problems, checking logs, and looking at how everything’s working together when stuff goes wrong, mainly in production
• To take an example - when a team of 5 folks decides to break a big app into 20 tiny apps, guess what? You’ll need more folks to look after those 20 apps now.
• If your team is responsible for one of the apps that is part of a larger enterprise level system, there is definitely need for interservice communications between your app and some of the related apps or components within that system. You may call it Microservices or simply Service Oriented Architecture. Communication can happen via REST or SOAP API calls, GraphQL or Message Brokers, etc. But within your app, need for breaking down the app to smaller size ones, is where you give enough thoughts.
• Here’s food for thought: delve into the “majestic monolith” concept. Check out this link: The Majestic Monolith. This method shines for apps raking in revenue with bustling user bases, like Basecamp.