Drivers for decomposition
Conventional wisdom has it that scale and scope are the main drivers to separate a big service into smaller ones. This is similar to an organization. In a small business, there is perhaps a single person doing everything related to HR, Finance and Fleet management. However, when you grow, those are typically split into separate units. So, although the scope did not change (you’re still the same business), the scale drives changes to your organization. Whereas when the scope changes, say you expand into the US, you might add new functions, in this example perhaps a legal officer. You get the idea.
In software architecture, an additional driver has emerged. And that driver is the speed of change. Being able to quickly react to changes in the market, or test new ideas, brings its own set of architectural challenges. How to make sure that a change doesn’t have any unintended side effects? How to enable multiple changes running in parallel, without any coordination? After all, coordination takes time, and consequently opposes agility. Moreover, more and more upgrade scenarios simply assume running multiple concurrent versions and being able to change the ratio of execution at any point in time in any direction, without any prior plan. Hence the change initially has a very small scale, but may quickly grow afterwards. Good luck coordinating this across multiple teams.
If you think this through, then the only viable architecture is having small autonomous units that can be deployed and routed independently. A higher speed of change requires a smaller scope and or a smaller scale of operation. There simply is no other way to architect for rapid and frequent changes. That is exactly why the speed of change has become the third driver for decomposition.
The Microservice Dilemma
Now how small can you go? If you think the smaller the better, think again. Would every class become a separate service, with its own database schema, independent of every other class, the number of different endpoints would explode and the computational complexity to somehow get some overview would far exceed todays capacity. Even with a full event-driven architecture, a reasonable number of event types and a reasonable number of events per type per second would seriously limit the scope of a solution. Just do the math. Look at your database logs and imagine every join will trigger at least one message over the network. Then imagine that the query optimization an RDBMS can do, has to be built into the software as well. Consequently, the amount of data that has to travel over the network will skyrocket. So how small can you actually go?
Something has to give. That’s why an architect has to balance scope, scale, and speed of change. Since trade-offs will be weighed different in different domains, and within different organizations, there is no simple heuristic that can guide the decisioning process. It really is a balancing act. An architectural design process, if you wish. This will ultimately define the granularity of your service architecture.
Soft Integration
Notice that in the previous section I mentioned the word ‘reasonable’ twice. If you guessed that there’s a key to escape the dilemma, you wouldn’t be far from the truth.
In fact, you can never really escape the dilemma. But with new technologies, you can definitely stretch the limits a bit further. WSO2 has been working tirelessly to bring Ballerina to the market. This is a prime example of such a new technology. It’s a clever approach to bring integration to the masses. And this is how.
We know for a long time that decoupling can help us conquer complexity. In a SOA approach, there is technically a decoupling of consumers and producers of services. That’s good. However, with all the logic we’ve implemented on the middleware layer – enrichment, transformation, orchestration, policies – we’ve built sometimes strong dependencies on a functional level. The thing is, the middleware is darn good at implementing these kinds of functionality. You can model powerful integration logic in a fraction of the time it would take you to build it yourself. And you can change your policies in real time.
In a microservice architecture, we simply assume endpoints are smart enough to do the integration logic natively. In a green field design, there is little need for integration logic anyways, simply because all the microservices are designed to easily work together. In real life, that’s often a bit different. There we still have the commercial-off-the-shelfware and cloud services we want to use rather than build ourselves. But they don’t have the smart endpoints built in. So we still have an integration challenge. And, when you come to think about it, after a few steps in the evolution of your fresh microservice architecture, you might need some clever glueware to keep it all together. Yet another facet of the microservice dilemma.
That’s where soft integration comes to the rescue. It brings the power of integration logic to the teams that are used to manage business logic in a language they already understand: software code. You define and publish your interfaces and policies as you’re used to – as an API. Next, you generate Ballerina code which covers all the basics. From here, you can add whatever you need, in a computer language designed for integration: Ballerina. Enrichment, transformation, orchestration, and everything else you need. You can simply deploy your extended microgateway as a sidecar to your service. Alternatively, using the built-in database connectors, you can build entire microservices with Ballerina.
Break Grounds
So, there you have it. Thanks to the power of Ballerina you can scale up the number of microservices you design, allowing for an accelerated speed to market, without ever losing control. Something Elon Musk would proudly market as ludicrous. And similar to the electric car, once you’ve experienced it yourself, you know the future has arrived.
Through the MicroScope is a blog series of indefinite length, focusing on designing resilient, distributed, cloud-native architectures. Every edition will shine a different light on the microsphere. Ready to read more? Read the previous Through the MicroScope blog.
{{cta(‘d9fab8d4-8a5f-4b31-8e17-6df83b075dfd’)}}
