Back to the Tech Future Again - A Chat with Scott Hanselman
-
By Samudra Weerasinghe
- 24 Nov, 2021
Photos by Ramón Salinero, Alex Motoc, and Markus Spiske on Unsplash and Brett Jordan and Digital Buggu from Pexels
Scott Hanselman and Eric Newcomer caught up on the Hanselminutes podcast. They spoke about the evolution of technology and introduced Ballerina and Choreo — a new programming language and a new iPaaS built by WSO2 that helps cloud-native API developers rapidly build innovative solutions.
Here are some highlights! (Some parts of this conversation have been paraphrased and reorganized for better readability).
Scott: Whether it be web APIs today, or SOAP back then, all we’re trying to do is get transactions to do work over the Internet or the world wide web, which Tim Berners-Lee initially invented to pass academic documents over the internet.
Eric: Yeah, that was the original invention, and no one expected it to be used for transaction processing.
Scott: Is all of this that we have today in 2021 built on hacks or is it just abstraction layers? Should we be worried about the underlying infrastructure or is it just that we're building smarter and we're learning about our mistakes and building correctly, or are we built on top of something that Tim Berners-Lee could never have even thought about?
Eric: Well, I hate to say this, but I sometimes find it amusing that Tim tries to fix the web that he created even though long ago it completely got out of his hands. So, I think the original web did definitely create the foundation, but where it's been taken has been in completely different directions than it originally was intended.
Scott: The acronym ACID is used a lot when talking about transactions. It denotes the properties of a transaction: atomicity, consistency, reliability, and durability. I assume that this is still the gospel, for a lack of better words.
Eric: That’s a conceptual way to put it but it’s certainly a way of evaluating what’s going on and determining whether you're doing the right things or not for your business transaction. Absolutely. Still one of the tests.
Eric: The first time I saw a computer was in 1974 when I was coding back in college. You had a mainframe computer in one room. You had to take the system disc that they used during the day for admin out and put in the system disc used for student projects. We used to create programs on punch cards and run them through. Back in those days, you had to go to a physical location and code, you didn’t have a computer in your pocket. You didn’t have a network. I mean some computers had dial-up, but there was no networking. Everything was this mainframe-oriented central control model that you went to as a person.
Today, Google, Amazon, Microsoft, Facebook, and everybody have thousands of computers and hundreds of data centers. You can’t even go in there; they’re all protected by security and other means. You have no idea where your program is running. You probably don't even want to know.
But it’s very interesting to me how things have evolved from those days where you had one computer running one program; you pretty much engineered the application to run on the mainframe.
Eric: We were designing and building our operational systems based on how we would run our own company inside its four walls. Connecting it to an external network was a secondary consideration and not part of the design. You would take a web server and bolt it on to create a portal between what’s happening inside the company to the web.
This was inverted by Google. About 20 years ago, they created their data centers based on web design principles, so that there wasn’t a mismatch between what’s going on in the company and the external network like there was in the original days of the web. Google came out with the concept of having a data center that does everything like a web farm.
That to me is how the cloud got started. Microservices, big data, DevOps, and all the modern trends that we’re all trying to adjust to were created because of this change in thinking.
Scott: What does it mean when we say the wire is too tight?
Eric: There are too many dependencies that are introduced between programs. A typical update pattern to keep data in sync will be to read the record, lock the database, modify the record on the screen and send it back to the database. That’s stretching the wire a little too tight when you have hundreds and thousands of updates going on at the same time. If you can assume that these systems work independently and only exchange state, you can scale them up and down dramatically and bring in a different type of failure management and resiliency.
But you have to redesign your apps to do that. You might need a new programming language syntax, such as Ballerina, which we are working on at WSO2, that makes that all intuitive and makes this change easier to deal with.
Scott: When understanding the business person’s problem, at the simplest level they need everything to be in real-time. It needs to be perfect.
Eric: Yeah, it’s such a continuum and a trade-off discussion. Not everything has to be locked down and changed. Eventual consistency came out of this concept of designing the whole application as if it were on the web, which Google pioneered.
Web companies were finding that it took too long to go all the way to the disk and write the data in stable storage. So, they just wrote it to memory and told the user “Hey, we got it”, replicated it to different computers, and eventually did the update. It’s such a crazy shift but Google did it, now everyone’s doing it, and we have to engineer and re-engineer for it too. We need new tools and programming languages to do this.
Eric: Earlier, we had this assumption that things don’t fail and we will engineer failure out. Google turned that on its head as well and said things are going to fail and we will work around that. We know they’re going to fail, we don’t care, we’re going to make copies of everything on different computers and just keep going.
There is a window of failure as the memory is being replicated, but it’s a trade-off between another larger-scale failure where an incident takes your entire system down and you’re out of business.
Scott: When I was working in large banks, I always thought it was funny that they would say we can't risk failure, but then they would take the entire system down every 28 days for maintenance. And that's arguably a fail. But they don't acknowledge that.
Scott: One of the things that WSO2 works on is Ballerina, which you can see at https://ballerina .io. So this language acknowledges things like how network primitives should be baked into the language, and that latency is a thing, the network exists, the wire exists and that is known at the language level. Is that right?
Eric: Exactly right. If you look at a Java program, you’re kind of bolting on all the network libraries. When dealing with HTTP requests in Java, you have this complex code to put together, the string, the parcel results, and how you’re going to send it out. Programs written in Java aren’t really built for this widely distributed computing environment where all the assumptions about how things work have changed.
That’s really what we're working on. If you look at the Ballerina HTTP and GraphQL abstractions I think you would see what it is we're trying to accomplish in terms of making things intuitive and simple for the type of distributed computing that has become the reality now that the web model is really what everyone's using.
Scott: One thing I was impressed about when I was looking at Ballerina was that in VS Code, there’s a plugin that allows you to look at the code that you're writing for your services, whether it be sending an email or making a web service call, and then there's an associated view of that as a graphical environment. So basically, a sequence diagram.
I wish I had this in the 90s when I was at Nike drawing sequence diagrams manually, then later in Vizio, and then translating them into the language that I wanted to use. You can look at Ballerina code as a sequence diagram and just kind of flip it over on its side. Like here's the text version, here's the graphical version.
Eric: It turns out the solution to this graphical language compatibility thing is to put primitives in the language to create the diagrams. We’re really an integration-focused company and when you’re doing integrations, you always have to have sequence diagrams to show what it is you’re doing. Our thought was, well everybody needs a sequence diagram anyway so why not just create it from the code?
Then later, in Choreo, we were able to take the sequence diagram, change that and generate code from it because we designed it to do that from the beginning. [Choreo is an internal developer platform that allows you to discover, create, manage, reuse, and integrate APIs.]
Eric: The web created these standards that everybody was able to use to work independently. We take this for granted now, but one of the most interesting things about the web when it first came out was that people could update their websites independently. Back in the day with distributed computing, you had to coordinate the client and the server together to make sure all the changes were made on both ends. With the web, you don’t have to do that and that concept really carries through to cloud-native computing.
If you really want to get all the benefits of the cloud you need to re-engineer your monoliths to microservices that evolve independently. One of the biggest attractions is independent evolution, but they can only do that if they are accessible, manage their own state, and have no dependencies.
It's such a change in thinking. We need to reimagine not only our system software, which we're doing with cloud-native computing capabilities, big data, microservices, Kafka, etc., but we also need to change how we imagine our programming, how we stitch things together, and how things are going to work together.
Scott: You said that previous languages were built with greenfield in mind. Ballerina is meant to interoperate with Java. Can you call Java code from Ballerina and vice versa?
Eric: Yeah, it works out of the box with Java libraries. When Java came out and became popular, I was thinking “Okay, now I have to learn something else”, because then we thought there would be one general-purpose programming language that was widely adopted. Now I don’t think that assumption is there anymore. Now in the industry, we expect to use different languages for specific purposes that allow you to do different kinds of work more productively.
Java, because it’s not very agile for the cloud, there’s a lot of effort to try and retrofit cloud-native computing into its ecosystem. Our view was to design something (Ballerina) from the ground up that is agile. Something we worked on in the language was to put in metadata that is needed to create Docker files and Kubernetes configs to automate the deployment aspect and abstract that as well, which helps with the cloud-native shift.
Scott: Also, I love this. It’s a network-friendly type system. We learn in school ints, strings, and date times, but why not JSON and XML as types that are baked into the language.
Eric: Exactly - another assumption that needs to be turned on its head. Earlier, you designed the data types for the language that would do the work that you needed to do, but now with your application running on thousands of computers you need to think about data as what’s flowing between those computers, and the network data types you create schemas for in the language.
Coming from the point of view of an integration company, thinking about the problem in the new web and cloud space, we should be able to have the data types in the language that are needed on the network. And that’s what Ballerina and Choreo try to achieve.
Scott: Yeah, that’s really thoughtful. In managed languages like Java and even C#, we’re spending a lot of time brokering between one format to another, effectively serializing and deserializing. And since JSON is JavaScript, it’s only JavaScript that gets it for free. Why shouldn’t other languages get it for free as well?
Listen to the full podcast on Back to the Technology Future Again, and check out WSO2’s cloud-native programming language — Ballerina, and Choreo for Integration.
