Do we really need even more?
The bad news is: yes, we do. That is at least what WSO2 is stating. And, it must be said, they’ve built a strong case. Existing languages, they say, may be more an more agile friendly, but lack the integration capabilities the emerging architectures need more than ever. The number of managed endpoints in a typical enterprise is still skyrocketing. Services are becoming more fine-granular, and more functionality gets added all the time. Image recognition? Voice control? Real-time speech translation perhaps? Just look at the explosion of cloud services on offer. It’s already staggering, and still growing daily. Wouldn’t it be nice if it was simply easy to unleash all these powers?
Granted, traditional integration tooling already has the capabilities to support complex integration scenario’s on large scales. But the way we use them today is simply not really agile. For starters, all too often, integration teams and development teams are separate, thereby violating the principle that developers must work together daily throughout the project. There missions are different, building great products versus managing an enterprise integration platform. And, as a result, we see an impedance mismatch, delivering frustration rather than great software.
Finally, to really excel at internet scales, both sides could do with way better support for container technologies – more and more the target environment for service deployments.
Welcome WSO2 Ballerina
So, there you have it, that is what WSO2 dubs the integration gap. Yes, there are a lot of specialized technologies, and general purpose languages, but in practice we need all of the above to create great software. So, we just try out new combinations of languages and tools all the time. As does every agile team. But building enterprise software haphazardly, unfortunately, ultimately kills productivity. We’re mostly jumping all over the place, acting incoherently, creating an inconsistent mess while we go, where we really could be performing a well-orchestrated dance instead. Please welcome Ballerina.
Ballerina is a general purpose computer language, aimed at programming server-side logic, specifically microservices. It is integration friendly, cloud native and Turing-complete. Bullshit bingo galore? Not really. And this is why.
Let’s start with Turing completeness. Granted, all general-purpose languages are Turing complete. It’s simply what you need to be versatile. So what’s new here? Well, frankly, in the integration space this is kind of groundbreaking. Unheard of. Think of languages in use for integration. WSDL, XSLT, XPath, XSD, the list is long. Powerful, perhaps, but the likes of XML, HTML, JSON, and YAML are simply not Turing-complete. Which makes sense, because these ‘markup-type’ languages are designed to structure data, not to describe computation on data. And having all those XML dialects to master, and still need a service implementation language on top, explains why so many integration-heavy projects/products are less agile than expected. So, WSO2 Ballerina uncovers a lot of potential here.
Cloud Nativeness
Cloud nativeness sounds great. But what does it really mean? Well, suppose your target environment is Docker – not a particularly unlikely choice to run microservices. Today, to generate the runtime environment artifacts you need, are, with any luck, automatically generated in your CI/CD pipeline. Of course, this comes at a cost. To simply build and deploy your code, you already have to struggle with two tools. Not a big hassle if everything goes right the first time around. But, in reality, all too often a distraction. Now, wouldn’t it be nice if your compiler would take you all the way? Just from code, managed in one place, by one person, in one IDE. Just like you are the art director, and Ballerina will perform any dance you have in mind. Wouldn’t that be cool indeed?
Ballerina has constructs that define the architectural environment so the compiler understands the logical environment the application will be running within. This enables the compiler to generate numerous runtime environment artifacts necessary to deploy your build in your target environment.
Furthermore, imagine calling a service on the web would be as simple as calling a local procedure or function. Ballerina comes with fundamental concepts of distributed system integration built in. Consider for example the following snippet:
endpoint http:Client clientEndpoint {
url: "https://postman-echo.com"
};
var response = clientEndpoint->get(“/get?test=123");
http:Request req = new;
req.setPayload("POST: Hello World”);
response = clientEndpoint->post("/post", req);
It is that simple to interact with a remote service. And because Ballerina is designed for distributed computing on the web, these constructs are no afterthought, but elegantly integrated into the core language.
Hype building
Sure, there is a fair amount of hype building up around Ballerina. But to suggest it is mere marketing wouldn’t do the language right. I always say, with great marketing, comes great responsibility. The people who invented WSO2 Ballerina, dr. Paul Fremantle and Sanjiva Weerawarana, are industry veterans with an impressive track record. And in my humble opinion, it shows. Now it’s time for us to show the Ballerina some love. Read some more, put on your dancing shoes and give it a try, and if possible, become part of it. I certainly plan to do so, and I suggest you do likewise.
