Has the microservices “trend” got you, too? I'm sure that you've already weighed your application's needs — and that it's a large-scale app, with a reasonably complex codebase that we're talking about — before you decided that: building microservices is your best option.
A way of structuring your app that would significantly reduce its complexity...
You've first learned all about its hard-to-resist-to benefits and now you can't help wondering:
What are the main challenges to expect? And the most common mistakes that companies building/deploying/moving everything over to a microservices architecture make?
Glad you asked, for here are the main risks and problems that you'll most likely face:
1. But What Is the Use of Microservices, More Precisely?
It's a new way of splitting a large-scale, complex app into... multiple, autonomous, manageable and independently deployable services. Into smaller services modeled around a business domain...
Or, a way of leveraging a design pattern based on the +30 years old principle of “separation of concerns”.
The main advantage? Managing your heavy, large-scale application gets less... cumbersome. And it'll be easier for you to meet high expectations of speed and agility.
2. Main Challenges Associated with Building Microservices
2.1. Synchronizing Data Across Microservices
Keeping consistency across a whole ecosystem of microservices is, indeed, a true dare.
Nevertheless, you still have solutions at hand. One of them is using the SAGA design pattern, for instance.
2.2. Enabling Communication Between Microservices
Another real challenge to keep in mind when building microservices: how do you ensure services communication across your network?
You could go with a publish-subscribe event-driven model or use API gateway...
2.3. Ensuring Security
This might turn out to be a serious problem in the context of a heavy infrastructure of microservices.
In the context of an intricate “cluster” of technologies, languages, version controls...
The solutions to this challenge?
- use an API gateway
- come up with a custom solution to secure your microservices
- go with one of the ready-to-use enterprise solutions, with an identity management platform (Otka, for instance)
2.4. Monitoring Your Entire Infrastructure
A true dare, without question. You now have an entire network of different:
- version controls
- languages
- technologies
- containers
- machines
… to orchestrate. Keeping a close eye on them all is 10x more demanding.
Where do you add that, even if you do spot a suspicious... issue, rolling back your entire infrastructure is way more challenging and riskier than rolling back a monolithic architecture...
The solution: make sure you place “proactive measures” on top of your priority list. And, implicitly, on top of your list of expenses, as well...
2.5. Identifying the Source of Malfunctions
When trouble strikes, digging for the “culprit” is no child's game... Especially when time is not on your side, for you'll start panicking when one error risks to affect multiple services from your network.
The solution: use a centralized “root cause detection” tool.
2.6. Issues Risk to Propagate Across the Network
And this turns into a particularly risky threat when you can't identify the very root of that error.
At least with monolith architectures it used to be quite straightforward: you knew where to start digging for the source. You didn't have data scattered all over a complex network, right?
The even trickier part is that, in many cases, you can't access it in your dashboard metrics or within your logs...
3. Mistakes You're Most Likely to Make When Building Your Microservices
3.1. You Don't Create a Centralized Logging for Microservices
Building microservices and not setting up centralized logging means... sabotaging your whole work.
Without a central logging repository it will be X times harder to track down issues and debug your app.
The solution: use log aggregator (Fluentd is but an example).
3.2. You Add Too Many Functions to Each Micro Service
Or, in other words: you get modularity all wrong...
There should be just one microservice standing for one business function. For instance, in case of an e-commerce app you should assign:
- checkout to a service
- order-related tasks to another service
- user details to a different service
See my point? Once you “cross the line” and you end up with multiple functions for one service you risk turning it into a... monolithic one.
3.3. You Don't Ensure that Microservices Are Totally Separated
Another high-impact mistake that you risk to make when building microservices.
Since your microservices are different, ranging from memory-intensive to compute-intensive ones, you need to clearly separate them.
And to either:
- set a heap space accordingly
- move the computer-intensive ones on a more powerful processor machine
3.4. You Don't Make Your Microservices Scalable Upon Demand
Mind you don't overlook or just underestimate this aspect: your microservices should scale upon demand.
Here's an example for you:
Say that most of the customers using your e-commerce app are just searching products. In this case, it would be but logical to scale that service alone, the one standing for “products search”, wouldn't it?
The END!
These are the main challenges to be prepared for and the most common mistakes to be aware of when building microservices.
Have you already dealt with other unexpected problems while implementing this new style of architecting your app?