Pivotal Conversations–So Isn’t Microservices Just SOA With JSON?

April 29, 2015 Coté

featured-pivotal-podcastAs you jump into microservices, it starts to sound a lot like SOA.

Coté asks Apiary’s CEO, Jakub Nešetřil, to reflect on this, since he spoke on that topic recently. Then, we discuss how architecture and development starts to shift with a microservices approach and how to introduce just enough governance to keep sane. This leads us to discuss managing API design in microservices architectures. We also discuss what happened to the idea of “the API economy” and how it evolved.

 

PLAY EPISODE

 

SHOW NOTES

TRANSCRIPT

Coté:
So it’s been several weeks since we saw each other last.

Jakub:
Yeah, it was awesome catching up.

Coté:
Yeah, so does James … he’s the … not the wheelhouse. He’s a Heavybit guy right?

Jakub:
Yep.

Coté:
And does he actually own that place that we did the conference in?

Jakub:
No, no I think that was a winery that was located close by and yes.

Coté:
That’s … because I was thinking maybe he owns this place and that place. They’re right next door to each other. Wouldn’t you want to get yourself set up to here’s my office and here’s the bar that I go to afterwards.

Jakub:
Yeah, yeah. That’s starting a theme right here. You know, Apiary is actually kind of hybrid Czech San Francisco company and so we have beer culture instead of a wine culture and one of the things that I was thinking about is that we’re going to start sponsoring meet ups but it has to be Czech beer.

Coté:
Ah.

Jakub:
As long as it’s Czech beer we can sponsor a meet up.

Coté:
Now you guys have that Budvar right? Or am I misplacing that?

Jakub:
Yeah, Budvar versus American Budweiser

Coté:
Okay, so what’s the story with that? Let’s get the stat, because I’ve heard non Czech natives give me interpretation and read Wikipedia but I want to hear the story from a real person.

Jakub:
Coté, you’re going off into the deep end. Into the highly controversial. All right. Well, you’ll get what you ask for.

Coté:
Fantastic.

Jakub:
That … I mean … there’s a town … there’s a thousand year old town in Czech Republic called Chess – kah – bull- yay – vits -ah]. That’s the Czech name of it. Now the German name of it for 1000 years is Budweis and Budweis is the German name for that and so Hamburg is a place in Germany and hamburger is a citizen of Germany, Budweis is a place in southern Bohemia and Budweiser is something coming out of Budweis.

Coté:
All right, and no doubt there’s a hot dog burg or something somewhere right?

Jakub:
Exactly, exactly, and so by extension the Czech name for the beer is something different. It’s Bull – yah – vit – ski – bud – var but the German name and the more international name is Budweiser beer and that of course doesn’t fly well with American Budweiser and so I think this is a lack of in 180 countries around the world and the … Historically, in the medieval times the world used to be divided between the Spanish and the Portuguese colonies. They tried the … the dividing line in southern America so I think the same goes for Budweiser and Budweis in. Dividing the world in two halves.

Coté:
That’s fun to think. Yeah, so you recently moved to San Francisco, or around to run basically run your company over here.

Jakub:
Yeah.

Coté:
And what …

Jakub:
Year and a half.

Coté:
That’s one of the things I was curious to ask you about is what’s that like? I mean, I’m sure you’re sort of … like a lot of us you’re a citizen of the internet if you will, and even more narrowly and interestingly a citizen of the programmers and the tech people of the internet. But, it still has to be a pretty weird thing to move that far. To pick up and move somewhere, especially for work. Is it … Has it been great or weird or how’s that been panning out?

Jakub:
Yeah, I’ve been very fortunate to be moving a lot with my parents even when I was small. So, I lived in Germany and went to school there. I lived in Canada and went to school there. I lived in New Zealand and my wife is from New Zealand and now San Francisco so it’s almost a little bit like business as usual. Except, there’s this one except, it’s the first time in my whole life, and I think every programmer feels that, that you come somewhere and you’re suddenly not the odd one out. You’re suddenly not the minority.

Coté:
Right.

Jakub:
It’s like you’re part of the mainstream and in certain aspects it’s actually a little bit disorienting because you get used to the fact that when you out … when you’re out there on the street and you’re passing the billboards on a highway they don’t talk to you. They talk to the guy that, I don’t know, buys a washing machine or wants to buy a car but not to you as a programmer. And suddenly, you pass these billboards and you’re like ooh, hold on a second what did just happen?

Coté:
I know, that’s … I still … it’s funny you say that because that’s the number one thing that still amusingly freaks me out every time I’m in the bay area.

Jakub:
Yep.

Coté:
Right?

Jakub:
Yep.

Coté:
Because you see that driving from the airport and it’s just … You see these signs that you would almost never see anywhere else. I … You guys have all those dice signs of these slightly flabby pale men in boxer shorts.

Jakub:
Oh yeah, oh yeah. Yes that’s …

Coté:
And I find …

Jakub:
That’s distressing.

Coté:
That’s distressing in a whole other angle, but I finally saw one of those in Austin and I felt like yeah we’re on the map. We’ve got the terrible tech billboards.

Jakub:
Yes.

Coté:
So, yeah I mean the reason we were together a few weeks ago, we were at an event where were going over … for a Heavybit, talking about continuous delivery and how it fits into things there and you had this talk that I thought was pretty great. Obviously you were there talking about your company and how awesome you are. You did a good job there. But, I think what … the part that I thought was fascinating was more of as we move into this micro services era, how can you make sure you’re not shooting yourself in the feet or the foot, right? How do you add a certain amount of structure to it and one of the parts that jumped out to me especially is you tackled head on one of the things I ask frequently is if you hear someone talk about micro services or look at the diagrams long enough you start to ask the question well isn’t this SOA? I wanted to have you on to hear what … you pose that quite well and how do you answer that question that when we talk about all these micro services things it seems a lot like what we were going after with service oriented architecture.

Jakub:
I started calling it Microsoft.

Coté:
That’s right.

Jakub:
It’s micro service oriented architecture and yeah. I mean certainly there’s a lot of resemblance there. I think the micro aspect to it, I’ve heard several different people quantify it but all of them is the scope of it is essentially SOA with insert something else, and I think for me it’s SOA in 2015 as opposed to SOA in 2005 and the world has changed. And, the way that software is being built has changed, the way that software is being delivered has changed and so a lot of these concerns that we had in 2005 were pretty valid. They were fundamentally focused at a different world and a different way that software is being built. So, with the massive amount of cost going down on infrastructure and the software defined infrastructure left and right, the whole software engineering process just became super super agile, super quick and the tolerance for the classical of upfront design, waterfall model became much much lower than it was back then.

So that’s one way to look at it. The concerns of trying to make sure as your architecture, trying to look at API’s and sort of see across the whole company all of the stuff is really important. I think there’s another element to it which is that, you know around SOA the government and protocols of APIs were SOA and WSDL, which was you, heavy handed and a lot of drawbacks but one thing that it did was that it was a very well defined protocol. We expressed then with API’s there is no well defined protocol. I mean it’s just a philosophy on how to build API’s, which gives them a lot more flexibility and adaptability to different scenarios in most cases, but that flexibility can absolutely appeal you, if, you know, if you’re engineers within your company are trying to get left and right and you know, you’re getting 15 different API design approaches in your company and that can spill out of control very quickly. So I think almost some of the standardization of you know, some of the aspects of trying to make sure that you’re API’s are consistent within your company are even more important today then they were back in SOA days.

Coté:
Yeah, I mean that captures a lot of things that I’ve been noticing when I’ve been trying to run the diff on the two, if you will. As you’re saying it, it does start with this … there’s two things which are sort of difficult to prove out so people have to take leaps of faith when they take a look at them.

One of them is well, the tools we have nowadays are just kind of better. Right? Like we have more fungible infrastructure so things can be more agile. And already using all these terms that are sort of like make people’s eyes roll, but it is … it’s just like things just run a little bit better than when we were doing SOA and WS star stuff back then, right?

Jakub:
Yeah.

Coté:
Like things are faster and therefore you can have faster turns on things and you know, to a certain extent, there’s almost a ratio between sloppiness in engineering and usability. Right? Like the sloppier you’re allowed to be the more usable something tends to be in the sense of you don’t have to do a lot of upfront specification of it and have it be perfect and have all these things lined up. If you have fast turns for doing things it’s easier to fix things if you will and kind of duct tape them together in a way that’s very solid, which again, I’m even using a way of putting it that makes it sound like it’s not solid, but that’s the point. It’s, there’s so many more safety nets in place because technology has gotten better. Go ahead.

Jakub:
I would think almost, I would say that we’ve also made a huge kind of leap in developer tools themselves, you know. When you look back ten years ago, stuff like developer experience and usability for developers, that just didn’t exist. I mean the whole category didn’t exist and nowadays you have many, many different areas and many start ups focusing very heavily on creating tools that intuitive that are really easy to use that bring that. And actually, to that other effect, when you see that across the whole industry in enterprise software or you know, left and right. You notice it a lot more kind of usability focused than it used to be, you know, even just ten years ago. So, I think the industry of writing software has become almost in the sense that it has to be simple from the get go. It has to be simple from the start, and it has to be very approachable. So, back in the 90s and 2000s the software engineering was a lot more engineering that it is now.

Coté:
Right.

Jakub:
It had a lot more kind of structure, kind of, you know, computer science, white lab coat approach to it than it has these days.

Coté:
Yeah, and that gets to the second thing that I’ve been trying to put into crisper words, but it’s essentially once you have the bitterness we were just speaking of, it shifts your mentality to essentially exploring, let’s see … it shifts your mentality to not doing so much planning up front. Right?

Jakub:
Mm-hmm (affirmative).

Coté:
Like instead of thinking that you know, the concern, I don’t want to necessarily say this was a concern in SOA but definitely in the web services spec era, was let’s all specify the same data model so that we can be inter-operable. Right. We want to make sure that we’re all speaking the same language and so it all works together. And that almost comes from this mentality that having a lot of upfront planning because we’re only going to have a few shots at making it work. Whereas nowadays I think there’s more of this expectation of yeah, we’ll just – at some point we’ll, you know, we can push software into production so frequently that it’ll kind of work out and we’ll figure out how it integrates together. Like we don’t need to worry about all this upfront planning.

So it’s almost like you have these two things together. One the mentality, like the tools get better, the raw infrastructure is better and that kind of encourages this other attitude of let’s, not so much fixing an engine in flight, but we have a much better chance of instead of spec-ing something out, just sort of getting code in front of people and seeing how it works, and then integrating that code as necessary instead of worrying about upfront specification of things.

Jakub:
Yeah. Yeah. Exactly. And so you know, that’s I think, that was part of what were discussing because the wheelhouse is that you know when you enter into a micro services kind of, micro services architecture set up. The process of making sure that your API’s are consistent across the company and that you are not kind of running in 15 different directions at the same time and that your contracts are strong and in force and you know, you know what they are, that’s incredible important. But at the same time you’re entering this kind of reality in the set up where it’s very hard to kind of argument today that you should spend six months specifying something before you start building it. That’s just not realistic.

Coté:
Right.

Jakub:
So, so, you know, the key trick and the Holy Grail here is to find a way to have a structured process to have the same process for building API’s that is almost adopted bottom up from developers individually that where you have a motivational system in place where they are actually interested in specifying things upfront. That’s a combination of making things simple and light weight so you don’t spend a lot of time doing it and helping giving you a return on investment. You as your own individual investor, right. Whether that is you know, generating some prototyping code for you initially or letting you prototype or visualize things very quickly. It’s just kind of put in instant gratification so it’s not just kind of a corporate level architect that is benefiting from the consistent process of designing API’s across the company but it is actually the developers doing the work in the trenches that get to benefit from this.

From that point you have a kind of inverted control and you get kind of bottom up adoption inside the company and I think fundamentally that there is no other way to roll out developer software these days than actually get the developers to love your product first before you can actually go and work with the CTO.

Coté:
Well certainly, that’s sort of one of the consequences of the whole, you know, like you need to become … every company is a technology company now like that sort of mentality. Much of that means, you know, you still need … it’s more additive. It’s not like the developers take over but they become extremely important to a technology being successful. I always characterize whether it’s developers or admins but they’re sort of the … they’re the last mile of making the sale successful. Right, because once you get the product in place, if the developer or the system admins or whoever don’t like do a pretty good effort of making it work out well, then it’s going to fail. So, it’s important to essentially get them interested and excited about it. Doing it early on, it’s not only valuable for like closing a deal or whatever but it’s also valuable kind of like in this infinite loop kind of way of they’re ultimately sort of the end users for the … well, they are kind of the end users for this kind of stuff you and I work on right, like software development stuff and infrastructure and all of that.

So getting them to use it earlier is good for us because it gives us feedback about what they’re doing and how it’s working out and not working. It also seems like, you were covering in talking about speeding up the time it takes for developers to get code into production or to move things along, right? Like one of the things we talk about, and I work in marketing for Pivotal Cloud Foundry and we’re always talking about interesting ways of doing ROI. Right? Like it’s your return on investment of doing this and one of the things we kick about quite a lot is how long does it take you to essentially get code in front of a customer and however it is you can shorten that cycle. I don’t know if that necessarily helps out a vendor’s ROI, sort of Excel diagrams but I think of someone doing software. There’s a certain metric that should be tracked of how fast can you start getting feedback from actual real users about how your software is working …

Jakub:
Yeah.

Coté:
Or not working. Because it’s not so much that you can take that feedback and you know, go make payroll with feedback, but you can definitely take that feedback as kindling to make your product better and then start making payroll, if you will. Start, start …

Jakub:
That’s …

Coté:
Start running your business.

Jakub:
That’s a great example Coté. And you know, taking it back to kind of micro services here, this is something that’s very close to me and that I have seen in the API space very, very frequently. You know, even know in the 2010 when every single other aspect of software development has accepted the fact that like waterfall planning is just ridiculous and that you have to integrate very quickly. The API space is still very, very much dominated by kind of lone back the developer, the only guardian of my data structures and then to lock myself up in an ivory tower and for the next three months and then come up with a perfect version of an API that nobody has ever you know, touched and talked about and I’m going to gift it to the world and leave. You know and any modifications and changes.

And a lot of that mentality is being given by the frustration and panic and pain of having to change APIs and version them and then give us the idea is the whole process in supporting, like I said outdated API’s. And that’s you know, understandable. Outdated APIs and version API’s are horrible pains. Huge pains. But I think there’s an element missing and that’s why you, that’s actually one of the reasons why Apiary started initially is to really kind of less focus on kind of massive kind of enterprise wide specifications and more focused on how can we flush out a big prototype with an API. And getting them in front of users as quickly as possible so that we get much of the right stuff in place and we get as much of the feedback in place. Specifically for an API, before we marry ourselves to this to intensely whether it’s writing code or just kind of mentally adopting that this is what our API is going to look like.

So that quick integration curve writing process became incredibly popular, and one of the reasons why developers love Apiary And we almost get a version of control here, which I’m sometimes really, really excited about, where it is that API consumers that get to co-write the API spec. That becomes really powerful in the microservices because in the internal architecture, those, the producing team and the consuming team are typically very close. There was in one company and sometimes there was in one team and the fact that they can actually write software in parallel becomes an incredible time saver.

So we get these situations, and I get this all the time, people coming back to me and saying, I just had like my full time developers build my whole app before I started writing the back end, off that kind of mark that was produced out of the quick API design document that we produced together. The fact that they can actually get like 70% there before I you know, starting my API implementation really means that you can save yourself a lot of iteration around kind of changing a API design that’s broken.

Coté:
Then so, how do you guys fit into that? If I’m kind of sitting down day to day or week to week how am I using y’alls tools to not just having crazy web pages that are documenting my API’s. What’s the process look like?

Jakub:
It all starts with that first meeting when you’re thinking about building an API and you’re either kind of, you know, you’re inside meeting room ideating on a white board and then taking a photo of it and sending it to a co-worker, or summarizing it down into an email and sending it down to somebody else, saying hey, I just thought would could build something like this. That white board should be. And, if you do that it becomes, you know, we do a lot to try to make it super simple. We have a language that is like really, really simple for developers to write and we can write down a quick API in five minutes. It’s marked down, it’s like very organic, it’s very simple for developers.

What it creates for you, is creates this kind of common space, common language kind of when you talk about it that’s machine readable, human writable so it’s super simple but it’s also machine writable, and machine readable. The important aspect of it is that we take your white board, we take your … we build a language that we have API blue prints. It’s a… We take that API blueprint and we immediately create a API prototype, the moment you hit your first button. So, from day one when you’ve proposed your first API idea, your first resource you know, your first data structure. You have an API that’s sitting out there on the internet, somebody can query it and guess what, if they decide that the API is broken, that they would like to have a different resource, they would like to change the of a certain data structure, they would like add to it, whatever. They can go in, edit that out, click the save button and boom the API prototype is updated immediately.

Coté:
So there’s basically like, I don’t know if this is over applying the word but there’s essentially a DSL that you have that’s heavily marked down base. It’s not like as technical as the kind of DSL’s you might see in puppet or chef or something but nonetheless, it’s a human friendly, machine friendly language. So that’s an area, that’s why you bring up the story, oh we’re white boarding something and we just use this little API blueprint DSL to, as if we’re documenting the API, and then from there your system can construct, if only, I don’t know what you would call it, but a mock API, just at least what the endpoints look like. That hooks up with the idea that oh, we can start coding to it. It may not be functional but at least we can start coding to this thing because it’ll at least stand up the mock API that we can start using.

Jakub:
Yeah. I have kind of a micro example of this. Like the minimal 101 API design problem, which is imagine if you have a database of users and you’re going to do an API that’s an address book. Right. So the initial kind of default mode of the backend kind of API developer is will I have a resource which is a person, and I have a collection of those resources so I’m going to have one kind URL for slash people, or slash persons, whatever, and then I’m going to have slash person, slash 1 or whatever it is that is actually the individual person. On the surface this looks like a perfectly valid, kind of restful style document oriented API design until you get use case which says I am a mobile developer and I need to actually build an address book on a mobile client. It needs to show like 50 people on the same page and so I need to make 50 API calls in order to get their individual names because guess what, we have forgotten to add the names into kind of pagable kind of collection. Right. We’ve just got individual API points for each person and so this is a great example of where like initially the API design is perfect and it’s perfectly valid until it hits a real world use case. This is such a big problem with latency not going away, with being pretty constant, like the bandwidth is increasing but the latency is still the same. So the API becomes incredibly critical. You see this left and right across the industry.

So you don’t have one true, right API design. It’s impossible to say that. That was true back in the WS start up days when there was just one way to design API’s. But nowadays that’s not true anymore and so you have to kind of start thinking about how people are going to use your data, and that’s very much an exploratory process of you know, learn by trial and error.

That’s why exposing that early prototype and coding through it, at least the partial application is incredibly valuable.

Coté:
So how does … you brought up one of the things that’s often a common clunking in my mind as well. What’s the governs that you put in place or the controls or whatever, so I guess you don’t change the API. Back in the Java days and things and WS star days, like changing a publicly published API was taboo because it would just break things. So do you find that that’s still the case when people are working on the API’s behind micro services or how is that been panning out?

Jakub:
Well, I mean ultimately at the end of the day this is all change management. Change management means, you know, who is consuming my API, how do I communicate to them and how quickly can I get them to change, right. For the different contacts and industries can have vastly different answers. If you’re in the financial industry and you partner is moving at a glacial speed then you have kind of ten years life cycle on changing it I think, than just stuck with an API that there’s no way that you can change it. If you’re working in a closely tightly knit team that’s working on micro services and you’re kind of continuous to maybe you have a two week window you know, before you can change an API in backward compatible way. Internal dependencies and other teams can adapt quickly. So this very much depends on the situation where you are as an API.

But I think kind of generally speaking, that difference is without kind of bring that, you know, we brought that into the discussion without much ceremony but I think, so where we help with this is once you get through that first hoop of getting developers to kind of start thinking about API’s, describing them, you know talking about them, having an early, quick, kind of rapid integration of that job process on kind of collaborating on API. You have this kind of process where you’re catering a lot of your ideas, a lot of your intents of where your API’s are going very, very early on in the process … even before start, you know, way before you start deploying, often before even you start coding.

So that’s a great place to start looking at how do my data structures look like, how do my status points look like, do I need to create a certain commonality between the API’s. Sometimes this is very technical and you really want to use kind of one common time format or data format, or data structure. Sometimes these almost kind of very comic. We have a customer out of New Zealand who has a massive API problem because half of their API’s have British spelling and half of them have American spelling. The amount of time that they lose by hunting the elusive kind of S versus Z’s somewhere in their URL or in their data structure is really frustrating to them. So having a common way to design API’s you have kind of a common way to validate against these constraints that you’ve set themselves inside the company. Some of them can be architectural constraints, and some of them can be, you know, British spelling constraints.

Coté:
Yeah. Everyone has their, like I have neurosis I think where I can’t stand two spaces after a period. And so any type of document that has that I have to immediately change it or it just, it doesn’t work out well.

Jakub:
Exactly. Exactly, exactly. So in a circumstance like we’re in a very, very interesting space because we’re getting this kind of massive amount of kind of spontaneous developer adoption. They love prototyping, they love describing their API’s quickly, they love that the fact that they have a documentation from. We can start looking at how do we help companies in a larger scale with hundreds and thousands of developers and potentially hundreds of thousands of API end points. You know, how would we help them keep things consistent.

But, consistent from a way where it’s not the old 2005 governance of you know, beating everybody down into obedience, but how do you help them by actually all the way back when you were individual developers are designing API’s and you know, thinking about them, how to guide them and hint through good completion and intelligence, you know the director or editor is saying yeah the end point I have written down here, perfectly fine, run with it … but actually it’s breaking a rule that we set ourselves in the company so you might as well think about changing that.

Coté:
Right, and that’s where your tool can help enforce things, is that essentially the way you’re making this API is breaking convention. It’s almost like the red squiggly of API design and use essentially.

Jakub:
Yeah. The way you take that into a stance, at the end of the day we start by this kind of organic, very simple hints for individual developers. We wrote it out to kind of view the across the whole architecture for architects, so looking at the API as a whole, the amount of kind of transgressions against certain internal policies. We also start looking at stuff like how do I make a diff between two different API versions. So how do I think about the changes that have happened between two different versions of an API, what are the kind of changes that have happened? How do I produce an automatic change log? How do I automatically notify about back making changes to my customers and clients. Because we have this format that is one hand side comes across as a very human readable, very simple documentation format, and on the other hand side can be automatically machine analyzed. We can really kind of dive deep into it and look at the changes that are happening in an API in the development pipeline weeks or months before you about to deploy an API and catch changes that are background breaking and suggest that those need to be populated to a customers way before it actually happens.

Coté:
Yeah. That sounds helpful. It’s like the difference between … it’s like when I switched from using Emax to Eclipse. It’s much handier. So before we run out of time, here’s … to change the scope of focus like to be more abstract, one of the things that I’ve been noticing and like in seeing you do a talk a couple weeks ago kind of cemented this notion in my head is that when we … over the past five years when we, or, people have said the phrase API, I think they meant several different things. It’s come to mean something much different than it did originally. Like, and tell me where you think this interpretation might be wrong but I think the first time that I heard API’s talked about was sort of like right after the sort of mash up era of things. And the notion was, it quickly evolved into the let’s call it the API economy and there was almost this notion that companies that were tech companies are like, I remember Tesco was the big example of someone who published API’s publicly, and Best Buy had API’s and Netflix just shutdown some of their API’s. Like they had API’s and it was almost as if like when the word API was used, it was not how we were just discussing it, sort of, well, we’ll get to that. More internal use of API’s but more like open up your business through API’s so the people can integrate with you. And then it seems like in recent times, I mean I’m sure the API economy was interesting and that’s still definitely a thing if you … especially if you look at programmable web and the metrics that people like Apogee and yourselves, but it seems like it turns out the more valuable thing for all this API econonmy thing like what we’ve been talking about is, well when you’re designing your own applications you should be thinking of it in a micro services way. Then all of that API thing we were talking about becomes extremely useful. It seems like everyone has kind of like moved to that second way of thinking about it rather than just thinking oh I’m going to integrate with Tesco’s API and that’s going to be a wonderful new era of things.

Jakub:
Yeah. Comments around both on the side of the Tesco and both on the side of internal API’s, I think the excitement around kind of API economy it’s resembles a little bit for me because that dot come boom in the late 90s. It was the excitement of automating things and kind of doing things automatically in mass. Suddenly a business developer is going to become something that is, a discovery somewhere on the internet, on YouTube … I’m going to find the best provider for a certain infrastructure for a certain something, automatically since API discovery and enter a contract and start getting services from somebody automatically. At the end of the day, the realization is, you know, if you use somebody’s third party API, you are binding your service to their service. You’re binding your company to their company. You trust their terms of service, you trust their security. You trust their team. You trust their brand and there’s a lot more that goes into it than technical compatibility. I almost kind of tell people, we’ve had this massive kind of arguments in the API community about the value of API discovery services, and I tell people, you know look at how people use API’s these days. They don’t go online and search for a messaging API and then decide to use Twitter’s API because it’s got the most features for the best price. You know they go to Twitter because they want to integrate with Twitter and then they find out it has an API and how to use it. Right.

Coté:
Right, right.

Jakub:
The reason for that is because I picked Twitter as a company and there’s a brand to it and there’s values and I trust them and whatever else. But there’s a lot more human to it than people thought initially in the API economy. That completely changes when you look at internal infrastructure inside companies because now you’re not crossing boundaries of trust anymore, hopefully, unless you have some kind of department fighting. Now you’re not crossing legal boundaries anymore. Often times you’re not crossing the firewall and so you have all of this kind of trust. You have none of the security concerns. You have none of the dependency of a third party business and so you can really move much more quick and much more kind of pave way on breaking down your application, your massive application models into a lot of small different chunks that can move very independently and so in a certain sense it’s just another manifestation of kind of conversion of the top down kind of control over your idea or organization into small, kind of five people commandos that operate independently you know, into the special ops of engineering.

I think that’s a trend that’s over the last ten years. It’s the unification of engineers and operations people into. It’s creating these kind of vertically integrated end to end responsibility teams and it’s breaking down the application into many, many small different chunks that can move independently. On the surface that looks incredibly like, empowering, you know, you can move much quicker, you have a lot more control, a lot more independence. Where it’s sometimes hidden a little bit behind the view of it that you look to remove the complexity of your massive application being massively complex. You’re pushing a lot of it into interfaces between micro service components. So the complexity gets squeezed out of the little individual nodes and it gets squeezed out onto the network almost, if you will, onto the interface. So suddenly the difficult part isn’t writing your 500 lines of code that implement that individual micro service, the difficult part is where the micro service fit into the overall application. How do you exchange data with the other parts and with the other micro services? That’s where you start getting this complexity that isn’t traditionally understood, I think, because the traditional engineering and discipline is understanding the complexity behind lines of code, not understanding the complexity of stringing things up together.

Coté:
Yeah, I mean, yeah. I always think of as you outlined it as, complexity as a balloon right?
You squeeze one part and it just goes to another part.

Jakub:
Yeah.

Coté:
You’re right. To a certain extent, complexity shifts off into … I don’t know what the kids call it nowadays but into the business logic. It’s sort of like eventually you’re going to actually need to write an application that does something so you’ve got to wire together all these micro services. Knowing how to do that correctly is, I would almost say it’s a welcome complexity, right? Like it’s nice to focus on the application layer, but it still is a complexity nonetheless, right? You don’t sort of build it all into the various tiers of your system and I think the other amount of complexity, that is especially pivotal that we see all the time and like to think we help out with is … you know, there’s these people called ops people. Operations people. I think to a certain extent when you describe like dev ops culture and like micro services and all this stuff. It’s like that old picture of like here’s how you draw an owl. Draw two circles, step one. And the second step is draw the rest of the owl and there’s a perfectly drawn owl over there. To developers it’s like oh sure, I get it. I’ll just keep sketching and doing something. No problem. It’s like the developers are the ones who can draw easily where as the operations people are like I have no idea what you – it just sounds terrible. Right, because you’re shifting all the heavy lifting on the ops people, right? They’ve got to stand up basically clouds and like completely self service systems that can scale up and scale down and just work wonderfully so developers don’t have to worry about it and the complexity shifts to other areas. I think, and we were talking about it earlier, I think things seem to be better than they used to be.

Jakub:
Yeah. No, absolutely, and one of the reasons for that is because a lot of this can become commoditized, right?

Coté:
Right.

Jakub:
So to a large degree some of auto scaling and standing up the cloud, and you know even the stuff that you’re doing with Cloud Foundry, you don’t have to do this in house in every single company around the world anymore, right?

Coté:
Yeah.

Jakub:
You can go out and actually get help, and guess what it works for 99.9% of the use cases, right. That’s I think the massive transformation that we went through is that we’re not starting from scratch anymore. Not just on the software side, but also on the infrastructure side. So I see API just kind of wanting step on that little path where you know, we’re the ones take care of your API design, and development infrastructure. Other people take care of your cloud infrastructure and autoscaling and monitoring and you know, automatic notification, and user support and many, many other areas that have been really kind of greatly simplified over the last couple years.

Coté:
Well great. This has been a fun conversation. It was good to get into the slides a little bit more, and so before we wrap up, you know, to further be like western American guy, I guess you’re the American guy … like you’re one of the few people who has like more accents in his last name than I do which is just one accent. So how is your name properly pronounced?

Jakub:
All right. So Czech has one funny character in it, it’s not found in any other language in the world. Not just the character but also the sound of it. It’s R with a little hook over it and it’s pronounced “rjuh” and so my full name is “Neh-shet-rjuh-il” and not even my wife can pronounce it, which is saying a lot because it’s her last name as well now. So it’s pretty tough.

Actually I have a good story about this, especially around continuous delivery because I single handedly broke Heroku in the early days by having a stupid name. Because you have common messages that got pulled into Heroku and Heroku just completed bulk the that’s you know in the good app common messages and the whole application just went down whenever I would try to deploy anything. So there used to be days when having accents in your name was actually critically, critically difficult in the pronunciation.

Coté:
Yeah, I always encounter that in government documents like you know, I’m always very tempted to actually do the old option E E and put the right accented E in the names and things but I just don’t. I don’t bother because I know it’s going to break something.

Jakub:
You know Coté, how we always get this like beautiful rendered font until you get to the accented character that’s like in the fallback font because …

Coté:
Exactly.

Jakub:
… font doesn’t support these characters.

Coté:
Happens all the time. Well great. Well thanks Jacob for this. So if people want to find out more about yourself or API, how do they … where can they look?

Jakub:
They can just go to apiary.io. There should be an email for me. It was a lot of fun Coté.

Coté:
Yeah.

Jakub:
Great.

About the Author

Biography

More Content by Coté
Previous
New Pivotal Cloud Foundry Service:  GemFire Session State Caching
New Pivotal Cloud Foundry Service: GemFire Session State Caching

Pivotal Cloud Foundry makes application development, provisioning, and general lifecycle management much ea...

Next
Data As The New Oil: Producing Value for the Oil & Gas Industry
Data As The New Oil: Producing Value for the Oil & Gas Industry

During a webinar for Data Science Central, Pivotal’s Senior Data Scientist, Rashmi Raghu, discussed how apt...

×

Subscribe to our Newsletter

Thank you!
Error - something went wrong!