Brainwave PS-03: Eric Newcomer, WSO2 – Architectural Evolution from WS* to Cloud-Native

Problem Solvers — Podcast / vCast for March 24, 2021:

Full transcript of the podcast:

Jason English: Welcome to the Intellyx Brainwave. We’re here for another action packed episode of our podcast /video cast. Today we’re joined by Eric Newcomer. He is the new chief technology officer at WSO2. We go way back working with Eric in the past in previous roles directly and indirectly prior to joining Citi in 2012, he was Chief Architect for investment banking, IT division at Credit Suisse.

And before that, he was a CTO at IONA Technologies. Before that, a distinguished engineer and an architect at Digital Equipment/Compaq Computer. So welcome to the show Eric and great to have you on with us.

Eric Newcomer: Thanks, Jason. It’s great to be here. Thanks for asking me, sorry if there’s any construction noise in the background here occasionally, but life in the big city.

Jason Bloomberg: Right. Very good. Well, it’s great to talk to you again, Eric. You know, we go way back. I think we worked together a bit when you were at IONA or at least in the web services standards efforts. I know you; I remember you as being the God of WS-Transaction. You were like the guy who understood everything.

Eric Newcomer: I wrote that spec. Yeah.

Jason Bloomberg: Yeah, exactly.

Eric Newcomer: But yeah, I was involved, I just kind of made the pivot from transactions to web services when I joined Iona, the reason for it when I was at you know, Digital, Compaq, which is now part of HP, I was involved in a Microsoft partnership activity. So I knew a lot of guys at Microsoft and IONA, when I joined them, they started talking about the pluggable or the configurable, ORB that was in the base of their new product.

And one of the configurable protocols they kept showing was SOAP. And this was in 1999, 2000. I said, what is that? And they said, well, we don’t know for sure Microsoft is talking about this. They have the spec, and they haven’t released it. So I said, I know people at Microsoft, so I called them up.

And you know, I kind of hold this spec and I brought this to the guys that IONA, and they said, here you go, why don’t you get somebody assigned to this who understands languages and protocols and data mappings that stuff. I’m the transactions guy. And they said, who do you think we are, Digital? We’re a small company. You have to do this. So I said, okay. And so I did both jobs for about a year and it seemed like web services were going to turn into something and I kind of pivoted to that.

Jason Bloomberg: Yes. You mentioned ORB and only us gray hairs or no hairs will remember what that is. Right? Object request broker. And it was a part of the CORBA movement that predated web services. And we won’t have to spend too much time on the history lesson, but this all leads up to the story of APIs, which is the modern story.

So help us sort of get some historical context. We had ORB and CORBA, we had web services. And now we’re talking about APIs. So what can we, gray hairs and no hairs teach the millennials about APIs, given this historic context?

Eric Newcomer:  Main thing is it’s all about the design. You get the design right, that’s 90% of what you need to do. This was true, even for DCE before CORBA, but if you want to go back that far, to kind of the original distributed systems efforts that were trying to become standards. These kinds of things had a lot in common. They were coming out of industry. They were more LAN-based protocols kind of trying to do.

We’ll bring the mainframe apps out of the distributed world, the same qualities of service through distributed computing. And then we got into this whole web services versus REST battle in the mid 2000s. I’m sure you remember that as well. And now REST APIs are the way to go.

That’s kind of the end result of that. I don’t know if it was a bad word, just slowly emerging standard. Now the design practice is the same but the technology is different and APIs on top of REST, have some really different characteristics than what the old DCE CORBA Java EE had in the past.

So that would be the second adjustment, which is first of all, Get the design, right. API first, interface first as we used to say, figure out what you want to expose to your client’s main design practice, not what you’re wrapping on the back end. That’s the wrong way to do it. Then once you’ve done that, the second thing to understand now is how is REST different?

If you’re coming from that world of distributed computing, how is REST different than the old stuff?

Jason Bloomberg: Yeah, so that API first to a backend web services days, we called it WSDL-first and that’s an important core best practice. But as I remember, as the transition from web services to REST as REST became sort of more predominant, it was still hobbled by its HTTP- centricity.

HTTP had never really been designed for that. Right. It was a stateless protocol and it closed down. It closed down the interaction as soon as it was complete. And it didn’t really lend itself to APIs and then it became sort of core to the REST approach. But today we don’t necessarily have to worry about the constraints of HTTP with REST.

So, so how have you seen that API is evolving? You know, we had WSDL, XML- based web services. Then we had this. HTTP-based story that was very limited. And then now we have modern, restful APIs. So sort of what’s going on there.

Eric Newcomer: Well, I can see which first of all, I have to say I can see which side of the fence you fall on.

With this REST for sure debate. I got this a lot from the OMG guys back in the day when I was first starting with web services, I would go to the CORBA meetings, the standards meetings, they’d say, Eric, what the hell are you doing with this crappy HTTP protocol on this text-based payload? Why aren’t you using IIOP and a good binary protocol? It’s a much faster service.

And I would say, sure, you guys just get IIOP and the CORBA stuff to be as widely adopted as HTTP is, and no problem. So you kind of have this, the adoption phenomenon was there because of the web. It drove the adoption of HTTP much more than CORBA was ever adopted.

So kind of de facto, this stuff was out there. But this is also of interest is how this happened because HTTP, as you know, comes from this whole other world of computing around SGML and document-oriented standards, and it was invented as a way to share research documents. And the way you exchange state was you had a document, you downloaded, it, changed the state, uploaded it back, and somebody would figure out what was changed in the document.

So they could update their database. And it’s based explicitly, when SOAP first came out I remember working with Don Boggs to try to do transactions early because, you know, he knew I was a transactions guy. He was a SOAP guy and thought, let’s go do this. And I had recently finished doing a transaction internet protocol at IATF with Tandem and Microsoft.

So we tried to do this and we called it SOAP-TP of course Sorry, couldn’t help, but laugh a little bit about this crazy name we came up with, but pretty soon after we got a little bit more into it, we realized it was really impossible to do this because the transaction distributed internet protocol like classic distributed two-phase protocols dependent on a shared session state to coordinate the two phase commit protocols.

And if you lost that session, it was a two pipe model. You had a pipe for the application data, pipe for the transaction coordination protocol. And if you lost that pipe, you rolled back. It’s the same OMG with OTS, JavaEE, X8 all of it was the same. And without HTTP having persistent sessions, as you correctly pointed out as a limitation, I would say the other side of that, it’s an advantage.

And I would say what I want to talk about a little bit when we get to them. But certainly in the days when it came out and us classical distributed computing guys were looking at it going, what the hell is this? This is not at all what we’re used to. It doesn’t have the right qualities.

If you read the REST thesis from Roy Fielding, he explicitly says we don’t want to have shared session state because it interferes with scalability. He was talking about a WAN-based protocol, you know, up to that point, we’ve been talking about LAN-based distributed stuff, right.

And I think he was correct that for a wide-area network, you cannot really have a shared session state you have a two pipe model. You have to have everything on, on one pipe. The interesting implication of this for me is that it’s trying to simplify the picture, or you might say it just pushes the complexity around. Now let’s say if you’re doing transactions as a restful resource, the application has to keep track of the state, the log state, and pre-log state if anything goes wrong, the application has to do the rollback essentially, instead of the system doing it.

Is that better or worse? I think both cases can be made. The case for being better is kind of to deal with the assumptions that were made in the old, distributed computing environment.

We got to put all these abilities into the system. You got to have transaction security, reliability, but all of this stuff relied on the session–shared session state.

And I think, do we really need all that complexity in the first place? Because this was kind of almost a knee jerk reaction, you go to CORBA they reinvent all these capabilities, .NET reinvents, all these capabilities, web services reinvent all these capabilities.

Do we really need those? Some applications don’t some applications do. So why not make it a problem for the applications where they need the complexity and simplify everything else?

Jason Bloomberg:  Yeah. So shared session state that, you know, that is a phrase that just sends goosebumps down my spine. Yeah. A lot of this history.

And I remember, when REST became, you know, you mentioned some of the origins of REST and REST sort of first hit the scene. One of the core principles was at the OS, hypermedia as the engine of application state.

And it seemed so promising and innovative that instead of a shared session state, external to the interacting end points. We could just use the hypermedia themselves that is within the message itself to maintain state. And it didn’t really prove to be that workable in general. And now we have microservices interacting by modern APIs in say a Kubernetes context, which is an inherently stateless architecture where it externalized the state via a whole different way of thinking about state information.

So again, we don’t have a shared session state in Kubernetes, and we never could write Kubernetes is designed in such a way that it’s just would be alien to have a shared session state across the entire, yeah– yeah. So what are we doing today with shared session state is a cross that out. It’s an anathema, but we still have to deal with state.

We still have to commit transactions in a microservices environment. So what are we doing?

Eric Newcomer: Well, I think for our transactions, we really should be looking at transactions as a resource as the model for this. But I think there is a complication and you kind of touched on a little bit. One of the respond to the Kubernetes thing, first of all, and the microservices thing, because I think there’s something else that’s pretty widely misunderstood in the industry.

And some of it is the same reason web services were misunderstood back in the day because they’re trying to kind of bolt them on to their existing software so they can keep selling the stuff that they have. So I don’t want to pick on IBM, except I liked to pick on IBM for my career. I’ve been a computer competitor of IBM.

So that kind of comes naturally. I read their red book on microservices and they got all the concepts right. And they got to the example section and they want to show examples on Java EE with EJBs. No, no, no. These are not, that’s not how you do microservices, but of course they want to keep selling what they have.

But microservices, what’s missed often about this as microservices come out the right way to develop applications for commodity data centers that are comprised of hundreds of thousands of small PCs. So you have to distribute the workload across them. I followed this very closely because I know Adrian Cockcroft at Netflix, and I know some of the Amazon guys, so they were great when they did the famous monolith to microservices.

They created small units of work called AMI Amazon machine instances. That was their whole focus to break the work up into those things. Only later did they call it microservices. The real evolution of these things comes from the rightsize of work for these commodity data centers comprised of PCs. Now that’s why you don’t have a shared session state either, because these fabrics or these networks of computers work only if you have stateless kinds of interactions, because part of what they do, part of what makes them work is they allow for failure of these components. So if you look at some of the early design docs or Google files, they say our requirement was to keep the system going and space of component failure, even because we built this system on these cheap components that are subject to frequent failure.

So they built their own file system and they wrote multiple copies of data out to multiple machines. So if anything failed they had another copy of it. Does Oracle work on Google file system? No, we have a problem, we have a mismatch between the old world and the new world around how state is managed because of getting the benefits out of this cheap, cheap hardware by allowing things to fail and keep going.

So I think people tend to miss that microservices come out of that world as many other things, too, such as Kubernetes. So back to this API point, though, If you’re talking about APIs, microservices, and just really kind of two levels to this, and it’s this constant debate, people still are debating, you know, what’s the right level of granularity for microservice, but my frame of reference, tends to be the Netflix talk and the Amazon guidance that built their website.

And I think those two work pretty closely together in the Netflix migration. And I remember asking Adrian about this, what was his model? And he said, well, we have this AMI, this unit of work, we put a RESTful interface around us. That’s our coarse-grained service. And behind that, we have a bunch of fine-grained services using the Java interface to talk to each other.

So you have some, you know, some people will say the microservices, those are those fine grain things behind the coarse-grained interface. Some people will say the microservices that coarse-grained interface and behind that is just a lot of smaller things making that whole thing work.

But I think both are important to think about because you could have a mixed environment where you use HTTP for the coarse-grained service and GRPC or something else for the finer grained services, you know, it’s not a one size fits all thing. And there’s a lot of considerations.

What are you doing? Are you doing a venture or an architecture? Is Kafka the right way to do things. So on. So there’s a lot there, but I think the fundamental characteristics of the commodity data center as visible in the cloud is the things that really need to be taken into account when doing these designs.

Jason Bloomberg: Yeah. You bring up a lot of interesting points. I mean one of the points you made is how Google and really all of the cloud providers figured out how to architect a scalable infrastructure based upon low cost commodity hardware which is now sort of the core of the cloud. We just thought it would just build a resiliency-based architecture instead of a high-availability architecture.

If we’re looking for high availability, we have to jump through extra hoops to achieve it in this context.

Eric Newcomer: Yeah. That’s all different too. Yeah, achieve high availability.

Jason Bloomberg: But there’s also this discussion of fine-grain versus coarse-grained services. And I think that’s a point that the audience who hopefully will find this podcast may still be confused on.

And I still see a lot of confusion and there’s still confusion. Really. It seemed to really take off. As people started moving to a microservices architecture before they really figured out the elements of a cloud-native architecture that required more of than just the microservices, but when microservices came on the scene, people were just building lots and lots of microservices and they ended up with it’s a big mess, right.

It was point to point integrations and things bogged down and it didn’t scale. And it was just like you know, the pre- web services days all over again. It’s like they hadn’t learned the lesson from the point to point integration days.

And part of the challenge was this notion of fine-grained services versus courser-grained and the bounded context principle, which I hadn’t really seen that people talking about it in the web services days, but it became very important once people realized that to do microservices right they needed really to move to this cloud-native architecture.

That was more than just a bunch of microservices. So, right. So, what are you seeing in terms of the modern approach and feel free to talk a bit about what WSO2 is doing as well, because, I know they’re sort of onboard with this modern approach to architecting a microservices based infrastructure.

Eric Newcomer:  Some of this relates when you mentioned bounded context that relates to team organization as well, the famous eponymous team…

Jason Bloomberg:  Conway’s law, the software and the organization mirror each other, right?

Eric Newcomer: Yeah, exactly. And if you don’t really tackle that part of the concept, you may have trouble with the whole microservices concept as well. In terms of how do you approach this? Yeah, WSO2 has a methodology called Celery where we look at cell based organizations, organizational structures that determine the responsibilities of the different teams in, within one of these autonomous units.

So we give a little more detail on here’s your microservice bounded context. Here is the type of skills you need within that microservice to work on.

Whatever it is, you’re working on with it, whether it’s a GUI component or a database component, and try to drill down a little bit to help formalize the structure of these teams a little bit in terms of the granularity for microservice though, I think I’d like to get back to maybe some of the earlier points we were starting to touch on around how do you do the design of these things?

So, when I was at Citi I was Chief Architect in Treasury & Trade for several years. And we, at one point started a program of doing target architecture as targeted enterprise architectures. And we were doing a lot of these at Credit Suisse. That was part of their architecture culture.

And the reason for doing them was to try to help map out the strategic investments and make a decision, an informed decision when you’re spending money on a project as to whether it helps you get to a strategic place or it’s a tactical fix or whatever.

And of course, you’re going to have some of each, but without a framework for that discussion. You may not know whether your decision is aligning to where you want to go, or it’s just something else. No, you don’t want to help, you want to know, whether you’re going somewhere. So we did a lot of these and the way we started this was to take a blank sheet of paper and say, let’s forget about our existing systems.

I know that it’s very common practice in enterprises to say, Hey, I have an existing order entry system, existing payment system — I’m gonna modernize that I’m going to take to the next level. Let’s evolve it. You know, so the next step and let’s, do something with it, build on what we have, but often what we have is not what we want and we’re iterating toward the target.

Can’t really get there and you have to stop and say, where do we really want to go? And then work back to where we are, and then figure that out, and figure  out that journey. So we always try to start with strategically, where does the business want to be in five years? Three to five years.

And let’s say if you’re in payments or liquidities management or something like that, You would talk to the business people and they would say, gosh, you know, we would really like to have our customers be able to define their own liquidity portfolios, to see the structure of all their accounts in a certain way.

So we don’t have to do this. It’s not in the product now, but something strategic for the company we say, okay, let’s map that out as a service and the great part about SOA, which is also inherited by microservices as a design practice, you can align your business, a service to a software service very easily and say, Hey.

I have a service let’s give simple examples. I’m a bank. I’ve got services for paying you. I’ve got services for paying credit card debt for paying your mortgage for transferring money for cashing into a transfer inflating currency. I’ve got all these kinds of services, and I want to expose these as software APIs.

So let’s just design, take that, say I’m going to do payment. Very simple example. I’ve got a payment service and this mapping; this methodology is very straightforward. I would say, if somebody is going to start with a design start that way, align whatever the business services are.

And if we’re a target architecture where they want to be three to five years and work back from there to say, okay, I’ve got a business service, representing that in my software service, and I’ve got that as an API, that API has to connect to this system, and it has to get this functionality from existing systems. Or we have a gap here, something that doesn’t exist. Let’s build that.

So that, that would be in a nutshell, a way to try to approach this really focused on what the business needs to support the services they’re offering to their customers and their partners, and get that codified into an SOA design methodology.

Domain-driven design is a good one with the caveat that it’s based on object orientation. So we have to kind of discard those parts that have to do with object oriented design, but the concept of breaking things up into domains and sub domains. It’s very good. We use a subset of TOGFT which solves is another other possibility.

Jason Bloomberg:  There’s a lot of good advice there. And the fact that the business should be driving the architecture. That’s, that’s been true since the dawn of computing, right? That is a constant, you know, as these technology waves come and go, now we only have a few only have a few minutes left.

I definitely wanted to get sort of your– why it is you joined WSO2. We started working with WSO2 at Intellyx, soon before you joined. And I was quite surprised as well as pleased that you had joined, but it just struck me that having worked with them, that I wouldn’t have expected them to hire you.

And so I’m just sort of interested why you took the job and what you’re trying to accomplish there.

Eric Newcomer: I didn’t expect them to hire me either. It was a surprise, but a welcome one. It started with Sanjiva. I have known Sanjiva for 20 years. You’ve talked about the old web services days. I remember meeting him in those days and being on a lot of committees together.

And Paul Fremantle, I knew from those days as well. And I had always kind of kept track with WSO2. We used some of their technology at Credit Suisse, for example. So I had contacts on and off and What Sanjiva explained to me about the company, you know, he had been out as CEO and then came back and was looking to rebuild to kind of restart and look for new directions and new strategies, especially around cloud-native computing

Cloud computing, you had heard me talk earlier. This is one of my passions about how everything has changed because the commodity data center and all the innovations coming out of them. I was working on this at Citi. I was a part of the strategic team who was figuring out our cloud migration strategy. And I was doing work on microservices.

I brought in OpenShift and did a pilot on AWS. I thought this would be great. I’ve got some bad background here that I think can be really helpful –Sanjiva was telling me the company is looking to change and evolve to the next level of growth. And it will be based on work, moving toward cloud native strategy.

And on top of that, we have Ballerina, it’s a kind of a secret sauce or secret weapon that has a tremendous potential. As a cloud native language, I think we’re not there yet. But one of the biggest problems I see in the industry is people understand, I need to move to the cloud, but as we’ve been talking, there’s a lot of things that are different.

A lot of things you have to learn and change. The people don’t know how to do it. And the programming languages we have today are not designed for this either. You know, we see a lot of efforts to sort of retrofit into Java capabilities you need for cloud native computing

Just like object oriented COBOL to me.

Why are you doing this? You need a purpose built language for cloud native development. So that’s another, another big reason why I joined. I see a lot of potential there.

Jason Bloomberg:  I did it again. And I keep doing that. I remember Ballerina from a few years ago when it, when they first started talking about it and, and I was scratching my head.

So, you know, why do we need this? You know, that was before we were even talking about cloud native computing. And now, you know, you mentioned it’s a cloud native language, so they really pulled a Wayne Gretzky right there, skating where the puck is going to be putting together a Ballerina years ahead of when it really became something.

And I think it’s still a bit ahead of its time. So this is a good topic for the next podcast, right? We’ll talk about that because we’re out of time for today and Ballerina is a whole topic in its own. right. But it’s definitely a good cliffhanger to leave our audience with.  Yeah, really appreciate you joining us and JE, you want to take us out?

Jason English: Yeah. Thanks Jason and Eric for the scintillating discussion today and hope we’ll get on with you again sometime. Eric.

Eric Newcomer: That would be great. Jason, it’s great to meet you and Jason. Wonderful to reconnect and thanks for a great discussion. It was a lot of fun today.

Jason Bloomberg: Thanks a lot.

Jason English: Until next time. All right.

 

©2021 Intellyx LLC. At the time of publishing, WSO2 is an Intellyx subscriber. All dialogue in this program represents the expressed opinions of the hosts and guests, and are not necessarily the official position of Intellyx, or any company mentioned or included in this podcast audio or video.