Untangling the web of multiple Micro-services and Integrations
Software Design
Designing software products are hard! Several strategies are out there, discussed millions of times by different individuals or teams. We’ve seen different strategies working for companies at different stages of their growth.
Huge companies, with millions of users, are obvious examples of the best use case for micro-services, as they need to ensure the uptime, scalability that the added modularity can provide. On the other hand, it can be slower to implement and too complicated for small companies who need to create and iterate quickly, without getting bogged down in complex orchestration.
What are Micro-Services?
We all are familiar with the term, “services”. It has been used for decades and we use them to build our software systems. They are persistent and are presumed to be available all the time and stateful, meaning that they store information between transactions. AWS’s EC2 instances are a good example of where teams run their services.
Micro-services, on the other hand, are these minimized services that are self-contained and are not dependent on any other business function. It is a small component of a bigger application that is deployed separately and tends to stay in place for successive uses. They are a mix of stateless functions, but like services that they are persistent.
As a developer, you have the urge to design a perfect system. Componentization and Reusability are some of the major factors that you consider while building and micro-services architecture fit in well with it. It lets you independently scale parts of your system, modularise your code to minimize risk, and changes to your application can be rolled out without affecting your whole system. What could be more perfect than that, right?
Mirco-services can cause Huge problems!
One obvious thing that comes to your mind is since their services are “micro”, there gotta be a lot of them. The next obvious thing that comes to your mind right after that is tracking, troubleshooting, and maintenance. That’s just on top of the head, let’s dive in:
💰 Initial Investment
You are testing your idea and want to launch it in public as soon as you can. You hit a big blocker right at the start if you go with the Mirco-service based design of your system. You need to get skilled people with knowledge and experience to build that kind of architecture right from the start.
You need a lot more resources to build and take care of all the services you end up with. Believe me, micro-services tend to grow more quickly than we realise. If there is one thing that I have realized being a developer, there is no end to optimization. Even if you have a lot of investment that can get you resources, it’s probably not a good idea to put in that amount of effort and money before testing your idea out.
👀 Tracking and Troubleshooting!
With all the modularisation and services growing in number, it becomes harder and harder to keep track of all the things you are using. It naturally becomes hard to identify the root cause of an issue and take corrective actions due to the large number of them, the number of instances running, and communications flow, especially if they are not carefully designed.
One request to your system can span across multiple services, and it becomes critical to understand interdependencies for troubleshooting since everything is now an independent service, you have to carefully handle requests traveling between your modules.
🧪 Testing & Debugging
Testing a Micro-service based application can be cumbersome. You need to confirm each of the dependent services is running and connected even before you can start the testing. The impact area becomes less in size but you need to get very sure about how any service affects your system if not functioning properly. With a high number of these services, it becomes exponentially hard.
To write integration tests also, the engineer needs to have a thorough knowledge of all the services you are using. Analyzing and finding logs for multiple of these services can be very tricky and mentally taxing.
📉 Complexity, Performance, and Prioritisation
The complexity of your application increases proportionally when adding or delivering more micro-services. You can get into dependency hell very easily if you keep adding more services, especially when you need to scale and reiterate quickly. You get to feel the after-effects later when things start to go down and you end up fixing multiple services for a single issue.
You’ll need to think about the security of all of your services individually. You’ll have to move them across different private networks to minimise risk, which if not configured properly can expose more points of external disturbance. Not to mention network delays using a lot of services.
You also need to think about prioritisation when you have a lot of services at your disposal in terms of importance, resource allocation, etc. It would not make sense to allocate an unnecessary number of resources to a service that is used for relatively small and edge functionality.
Enter Low-Code!
If you take a step back, you can see that a lot more than often than teams who build micro-services when you have self-contained business logic or function. The steps that you take to reach the point of actually writing your business logic are either identical or well defined.
For example, if you want to use AWS Lambda for some operation, the steps for creating, deploying, and using the lambda are the same for everyone. It’s the business logic that is different for every company and individual. Keeping this in mind, you can create a layer of abstraction on these defined services and integrations.
When these abstractions are low-code or code-optional, it becomes a more natural fit for the audience. The development becomes a lot faster, and there is a low barrier approach towards modeling your micro-services with low-code.
How Canonic can help?
We understand that the need and importance of all the different services out there and wanted to make it possible to integrate with the one (or multiple of them) you need to power your product. In essence, we act as a bridge between different numbers of inputs (data sources) and outputs(APIs, Web-hooks, Triggers, etc). Instead of you writing code for all of the different services and maintaining them, you can connect with tons of different data sources or services (Airtable, Google Sheets, Pin-interest, etc) with canonic and get the output however you want.
Taking an example of a simple customer information dashboard, you’ll need to integrate with your backend systems to get the user’s data from it. You’ll need to connect with your payments service provider like Stripe to fetch all the subscription and payments-related info. You might need to connect with a customer relationship tool like Hubspot to fetch any conversation-related data.
Since each integration and data source has its API, unless the responses are cleaned and transformed by a custom backend, they are not very intuitive to simply integrate with the frontend. Canonic’s built-in-code editor provides a way to write your custom logic on top of every data point you are integrating with. We make it easier for companies and individuals to reach the point where they want to write their business logic and take away all the intricacies down the road. In the end, developers and companies must do their due diligence and understand what works for their specific use cases.
We are celebrating #30DaysOfCanonic! Every day we will cover guides, how-tos, and blog posts on what you can build on Canonic. Learn More
