Kasun Indrasiri, WSO2’s director of integration architecture, spoke to us recently about some things he’s passionate about – WSO2, integration and its role in digital transformation, and an exciting new project that he’s been working on!
1. For how long have you been at WSO2 and what has your journey been like?
I’ve just completed 8 years at WSO2 and it’s been a fascinating journey indeed. I have been working on WSO2 ESB/WSO2 EI products and I got the chance to work with great colleagues as well as customers across the world. Being a part of this product team has been a great opportunity and I’ve enjoyed every bit of it.
The highlights of my job have definitely been the chance to help customers around the globe solve their enterprise integration problems, contributing to design and development of a world-class integration platform, and solving complex production problems to scale WSO2 ESB to handle billions of transactions.
2. Almost all enterprises are moving towards digital transformation to stay agile and shorten the time to market. What is the role of Integration in Digital Transformation?
In my opinion, integration between applications, services, data, and systems is the bedrock of transforming a conventional enterprise into a digital enterprise. Whether you are a green-field or a brownfield enterprise, the plumbing between those entities is absolutely essential. Conventional enterprise architecture fosters the use of a central integration bus or an ESB (such as WSO2) which can take care of all such integration problems. However, with Microservice architecture, we more or less do the same in a fully decentralized way.
3. Talking about Microservices, what are the key considerations when moving towards Microservice Architecture (MSA)?
Microservices is an architectural style in which you develop a software solution as a suite of independent and business capability oriented services that are developed, deployed, and operated independently. In this approach, we no longer use a central ESB to plumb different services and systems. Rather we do the integration at the service level itself. For example, if you need to create a business capability that requires calling multiple microservices and other systems, then you will create another composite service which encapsulates the service composition logic.
For any organization that considers moving into Microservice Architecture, it’s important to understand the benefits as well as the complexities that microservices bring in. Building business capability oriented services, using container-based deployment, and using CICD pipelines will certainly help you to build solutions in a rapid and agile manner. However, organizations require having a well defined strategy to overcome the challenges in microservices architecture such as inter-service communication, observability, decentralized data, and transaction management.
4. Having said that, what is your take on the ESB solutions (config-over code) and its future?
I think a majority of enterprise software solutions still use ESBs in production at the moment. Also, there are certain use cases for which the ESB style is well suited and these scenarios can continue to leverage ESB architecture. I won’t expect the ESB or centralized integration bus to disappear anytime soon.
However, with new architecture paradigms such as microservices, cloud and container-native applications, and event stream driven messaging, we are moving into a different landscape where integration logic is being dispersed into the services itself. Also, with the proliferation of services, APIs and SaaS applications, then integration problems will be even more complex. Therefore the conventional centralized ESB based approach won’t be the best fit for such use cases. In my opinion, there will be a dedicated set of technology stacks to address such integration needs in the future.
5. What’s the latest project you’ve been working on or your proudest accomplishment in recent times?
We have been exploring a next-generation integration platform for cloud-native and microservices oriented integrations. Most existing technologies are not really designed to cater to those needs. We have been building a new programming language called Ballerina, to empower this kind of decentralized and cloud-native integration paradigm. This is still work in progress, so stay tuned for more information!
I also completed my the first book, ‘Beginning WSO2 ESB’ last year. It was a compilation of my experience with WSO2 ESB/WSO2 EI , to help WSO2 ESB/EI users to get up-to-speed and master it quickly.
6. What advice would you like to give a budding developer/architect ?
Well, rather giving advice I would like to share a few interesting things I recently read in an article from Neal Ford of ThoughtWorks, on the role of a developer and an architect. I guess we are living in a technology era in which change is inevitable and the technologies as so diversified. Neither developers nor architects can merely stick to one particular technology and be complacent with that.
If you are a developer it’s quite important to focus on the technical depth of the current technology that you are working on. The architect should focus more on the technical breadth of the technology stack. It is quite important to have sufficient understanding on each technology stack. That way, the architect can pick and choose the best of breed technologies for a given scenario.