To Code Or Not To Code? Just Cloud API Instead!

Transcript

Rahul Subramaniam: We should own a lot less code than we do today.

Alex Hudson: There’s an awful lot of freedom with code.

Steve Brain: There’s white space you fill with code.

Rahul Subramaniam: You can always do crappy stuff with really awesome things.

Hilary Doyle: Speak for yourself. This is AWS Insiders, an original podcast by CloudFix about the services, patterns, and future of cloud computing at AWS. CloudFix is a tool that finds and implements 100% safe, AWS recommended cost savings. That’s fixes, not just analytics. I’m Hillary Doyle, as always, joined by Rahul Subramaniam. Rahul, how the heck are you?

Rahul Subramaniam: Doing really well, Hillary, how are you?

Hilary Doyle: I am also, well, thanks. Look at us just starting at the day with a bang.

Rahul Subramaniam: I know. Looking forward to it.

Hilary Doyle: Well, at the edge of your seats, in this episode, our old school programming language is kind of dead. Should we be focusing instead on cloud APIs to code or not to code? That is the, well, it’s the gist of the question, but before we start, I am going to ask you to define some terms for us, Rahul. Let’s start with the most popular programming languages and what exactly we mean by cloud APIs.

Rahul Subramaniam: In the context of today’s conversation when we talk about programming languages, we are basically talking about Java, Python, C#, Go, and such languages. My contention is not really that these languages are dead, but that the code that we write has a very short half life and deserves far less importance than we give it today.

Hilary Doyle: Got it.

Rahul Subramaniam: And when we talk about API, we are specifically talking about cloud APIs that encapsulate functionality without consumers needing to worry about any of the infrastructure associated with it, so basically commoditized solutions.

Hilary Doyle: Commoditized solutions, there’s the rub. Okay. Code versus cloud APIs explained, albeit a little bit briefly. We will go deeper with guest and CTO for hire, Alex Hudson. He’s here to defend the honor and longevity of programming languages. We also have our usuals – the hot takes, our use case tips and tricks, plus we’ve got a visit from Steve Brain. He’ll also show up with his arms and his legs. He’s one of our in-house insiders. But first, let’s start with your AWS headlines.

Rahul, AWS has created new support for SQL Server in RDS Proxy, which would make it faster to connect and scale with SQL Server databases. Is this a surprising development?

Rahul Subramaniam: The SQL Server edition is actually really, really exciting.

Hilary Doyle: Oh, go on.

Rahul Subramaniam: Now, RDS Proxy has been kind of upping the efficiency of serverless code for quite a while with support for MySQL and Postgres. The problem is that since serverless code is short lived, operations like creating database connections and connection pools take an awful lot of time in comparison with the actual operations. So RDS Proxy takes away all of those operations and manages them virtually for all the serverless executions like Lambdas.

Hilary Doyle: Cool.

Rahul Subramaniam: Now, if only AWS could build an Oracle equivalent support, that would be so awesome.

Hilary Doyle: Okay, we have two bits of related news. Microsoft has partnered with Kyndryl to ease data migration from mainframe to cloud, and Google Cloud has joined forces with HCL Technologies to do something similar. Rahul, AWS’s two main competitors are helping customers migrate. Is this something AWS should concern itself with asap?

Rahul Subramaniam: I don’t think so, but I mean, whatever computation mainframes are doing could probably be done better and faster with cloud native APIs.

Hilary Doyle: Of course.

Rahul Subramaniam: The mainframe game is heating up for all three providers. Even though AWS has its own mainframe modernization service, the problem of complex refactoring and validation continues to remain across all three cloud service providers. I think these customers would be much better off if they went back to the core value proposition of the solutions that they’re running on these mainframes and just rebuilt that without trying to get feature parity. I think they’d be much better off if they just did that.

Hilary Doyle: Okay. So you’re saying that migration can and should be achieved with a lighter touch and what these CSPs are offering now is too heavy handed?

Rahul Subramaniam: I think the way they’re trying to migrate is flawed and they should rethink what migration to the cloud really means.

Hilary Doyle: Talk to this guy. Rahul, we’ll get to the emergence of cloud APIs and their impact on programming in a minute. But first I’d like to take a step back to understand the philosophy around code and how that’s evolved.

Rahul Subramaniam: A byproduct of the early days of computing was a culture of really trying to write code that everyone hoped would last the rest of time. Code is seen as art and there is this expectation that if not right, it never has to be rewritten again or last at least 10 years.

Hilary Doyle: But then cloud APIs came along and more or less took this focus on code away.

Rahul Subramaniam: Absolutely. I mean, you suddenly have these black box services that are fully managed, more efficient, and cheaper. And best of all, we didn’t have to build any of these ourselves.

Hilary Doyle: Do you have stories that you can share from your own work?

Rahul Subramaniam: Yeah, so here’s an example of how we leveraged an awesome pattern around business intelligence and visualization. We picked a set of AWS services that allowed us to replace hundreds of thousands of lines of code. Now over the years, I’ve seen about 50 different ways in which BI solutions have been implemented. But then AWS built QuickSight and we started deleting all the BI code across our product suite and built a standard pattern, which used S3 or Redshift as the data store. And then we started using Athena and QuickSight to embed a very standard but efficient and scalable business intelligence solution into every one of our products and we’ve never had to worry about scaling the solution. AWS just takes care of that for us.

Hilary Doyle: Great. So rather than focusing on code, now you’re focused on patterns.

Rahul Subramaniam: Nerd alert, Hilary.

Hilary Doyle: Hey. All right, well let’s lift ourselves out of the nerd weeds for a moment to talk about art and fashion please.

Rahul Subramaniam: Hilary, you know me. The art in my home is made of Lego and I have zero fashion sense.

Hilary Doyle: That’s harsh.

Rahul Subramaniam: But I do geek out on technology behind a lot of the modern day fashion and design.

Hilary Doyle: No problem. We will start at square one. You’ve probably heard of the fashion magazine, Vogue. I’m going to tell you about PhotoVogue. It’s connected to Vogue Italia and what you should basically take from this is: It’s fancy. It is a curated ecosystem of over 130,000 photographers with a collection of over 400,000 photos, each of which can be as large as 50 megs. Rahul, you may know nothing about fashion, but you do know a little something about the challenges that PhotoVogue faced in 2017.

Rahul Subramaniam: Yes. So PhotoVogue suddenly got very popular and photographers kept uploading images, which put a big strain on the platform, but also the latency and scalability were a problem for the editorial team that needed to process and catalog all of these images that were being uploaded.

Hilary Doyle: Right.

Rahul Subramaniam: So in one season, the existing IT infrastructure basically became very unfashionable.

Hilary Doyle: Nicely done. You’re catching up. That’s good.

Rahul Subramaniam: To get back on track quickly, PhotoVogue decided to step away from their old school on-prem setup, but they wanted to do it in just three months.

Hilary Doyle: And that is what we call fast fashion.

Rahul Subramaniam: We’ll go deeper into that in just a bit. It’s a good example of problem solving with the cloud APIs. But first we have an exciting conversation with Alex Hudson.

Hilary Doyle: Yes, we do. Alex Hudson calls himself an advisory CTO to a portfolio of startup and scale up companies. Many of them sit in the healthcare sector so you may owe your health in part to Alex Hudson. A lot of the businesses he works with have completed their digital transformations, and so he likes to say he’s sort of leading them into the post-digital era. What does that even mean? I don’t know, but we will find out. Alex Hudson, welcome. Thank you so much for joining us.

Alex Hudson: Thank you so much for having me. It’s great to be here.

Hilary Doyle: Alex, you’re a Python developer by trade and a pro programmer. You’ve said that no code as an alternative to most mainstream development is a pipe dream. Why do you think so?

Alex Hudson: Gosh, where to start? I think there are some use cases actually where it does shine. There are certain things you can do where it’s great. This specific problem I think we face is this issue of complexity. When you’re building bigger things, more moving parts that become more and more sophisticated over time, how do you do that in that kind of no code environment? And we don’t seem to have a good answer for that. My experience.

Hilary Doyle: Rahul, could you give us just an understanding of how relevant code is to your day to day work?

Rahul Subramaniam: We write code to be able to let computers know what we want it to do.

Hilary Doyle: Right.

Rahul Subramaniam: But the reality of the modern day setup is that almost 90% of the kind of code that we used to write over the last decade or more is now commodity and is available as commodity services. And my contention really is that we should own a lot less code than we do today.

Hilary Doyle: Alex, what would you say to that?

Alex Hudson: As developers, we don’t necessarily like using services depending on other people, and a lot of that is actually about that feeling of being able to have control, particularly over complex computer systems. If something goes wrong, you want to feel like what’s gone wrong, you know you have access to all the things underneath, and we are not good at kind of giving that up.

Rahul Subramaniam: Doesn’t that effectively break all the best practices that we talk about about modular design or modular architecture? Because you should have very clean abstraction and seams so that you have a standard interface that you can rely on in terms of what service it provides. And you shouldn’t really have to deal with anything that’s behind the scenes.

Alex Hudson: I wouldn’t want to understand how everything works, but also architecture is going to change over time. And some of the things that influence my systems are going to change over time. I’m not going to be able to make decisions necessarily up front that are the right decisions for the next five years. I’m going to have to change things around, I’m going to have to refactor how our system works.

Rahul Subramaniam: But if you really look at cloud APIs, they’ve actually standardized and actually hardened a lot of these aspects, whether it is the way you build your architecture to scale, whether it is for security, whether it is for a elasticity, all of those aspects are now baked in to some amazing standards that you can actually follow and deliver outcomes.

Alex Hudson: I think there are some cloud APIs out there that are great, and I would think about things like voice recognition, put in some audio, get some text back, but then there are other domains. So for example, in medicine, we want to use AI to diagnose conditions, and that tends to be less about how you run the AI and more the data that you have available, the insight and the labeling, and all of that. And you can’t really do that very easily against cloud API, and even if you’re able to, you then run into regulatory problems that it’s somebody else’s software running all of this and you can’t look far enough down the stack to be clear about how it works.

When we’re writing a new system that’s going to do something very novel, we want to write as little code as possible to try and get at the novelty and test it out and work with customers with it. But over time, that’s going to mature and we are going to want to be a lot more specific about how it works and we’re probably going to want to know a lot more about it.

Rahul Subramaniam: So that begs the question of how much specialty do you really need? Most novel solutions in my experience, have maybe 10% of the entire solution, which is truly novel, and everything else that goes into that solution is a commodity component that you can add to your overall solution.

Alex Hudson: I think particularly in these sort of low code environments and to some extent in low code, and to some extent when we’re talking about APIs, there is a boundary to the thing that you’re using. I’ll give you a really simple example. An organization I was working in that had used Salesforce in this whole bunch of different systems within Salesforce for doing coding without code. And in one of these systems we’d written some help desk functionality and one of the fields in the help desk ticket was the URL of the site that it was related to. And the person who developed it had chosen a string limited to 50 characters, and it is in a visual builder and we obviously found there were things that we wanted to record that were longer than that. In a code environment doing a kind of find and replace across a whole bunch of different places and refactoring that is pretty easy.

Let me tell you, in this Salesforce thing, we were going into one form and into another, and into another, and this string that was 50 characters long was in every place. It’s like going into a garden and finding that you got a whole series of weeds that you have to pull. And that’s kind of the issue is that there’s an awful lot of freedom with code. Everything is malleable. Everything is kind of changeable to a large extent and it’s just your ability to figure out what the change you want to make is and affect that change that restricts you. The platform itself is pretty unrestricted.

Hilary Doyle: But Rahul, are you using code to build workarounds in your own setups right now? It’s just you and me here.

Rahul Subramaniam: Yes.

Hilary Doyle: We’re safe.

Rahul Subramaniam: No, we absolutely do. There are gaps in the set of APIs that are available today, and those are constantly evolving. So one of the things that I ask my developers to do is that every time they write code, I actually ask them to justify why in the pull request that they send to me for review. I ask them to justify why that code that they just wrote is going to be really easy to delete because I believe that in the next year, or two years, or three years down the line, there’s going to be a service out there that’s going to fill in this gap and I should be able to delete this existing code and replace it with whatever comes down the line. Finding the right tool for the right problem is the challenge that most developers kind of lack the skill for and that’s basically where I’d say we as an industry need to focus.

Identifying standard patterns where you have the standard tooling for standard problems, that is the way forward if you want to really prevent people from doing all kinds of moronic stuff. I mean this holds true for code as well as no code solutions.

Hilary Doyle: And this, for you, is about living in the future, even though you admit that right now the future looks like a serious work in progress.

Rahul Subramaniam: Programming languages and the abstractions that we’ve been creating has been a work in progress since the late fifties, and that’s not stopped. In fact, the pace of it is just accelerated and I don’t see that stopping for the next two decades. So yeah, it’s always going to be work in progress.

Hilary Doyle: But it makes me nervous when you say about an API landscape, a cloud API landscape, that that is a work in progress because if I’m making a decision about the future of my company and I’m deciding to go all in on cloud APIs and to really limit the number of developers I’m going to bring on, that feels extremely risky to me if I’m dealing with circumstances like Alex just described where I’m effectively locked in.

Rahul Subramaniam: So here is one thing that I’m going to quote Werner Vogels.

Hilary Doyle: Oh, go on.

Rahul Subramaniam: He says in every single re:Invent talk that he does.

Hilary Doyle: At every opportunity.

Rahul Subramaniam: He says APIs are forever.

Hilary Doyle: Yeah.

Rahul Subramaniam: Which means that if you have an API that’s been published, that API does not go away. You can create a new API that does things differently or better, but the API that you built is forever. And that’s the underlying philosophy that Amazon builds its web services on and I think that’s the right way to do it.

Alex Hudson: I see that they’ve gone out and covered an awful lot more breadths. I don’t think they’ve been successful building one API on top of another. If I look at what’s out there right now, even the sort of latest compute APIs and things, you’ve got Lambdas and things like that. They’ve made the systems faster and they’ve made use of the RAM disk drives and things that you can get now and all of that good stuff and there is progress, but there’s very little that you could say, oh, this is clearly a much higher abstraction than what we had back then, and it’s a result of one team building on top of the work of another. And I think that’s a bit of a failure because even now you have developers saying, “Hey, all that Hiraku stuff I used to use 10, 15 years ago was easier and more straightforward for me. I got more done.”

I think that’s interesting to think about. Has that ability to turn all of your teams into APIs developed anything except it’s allowed people to be swapped in and outside of Amazon teams more easily and I’m not sure technically it’s helped very much.

Hilary Doyle: Rahul, are you seeing that with your teams? You’re speaking to the king of AWS over here with Rahul. I mean he’s in there every day. So are you seeing an easier turnover within your own teams and what do you say in response to this notion that it isn’t as clean as Alex would like to stack these APIs on top of one another?

Rahul Subramaniam: I would say it’s definitely a work in progress, but I disagree with the fact that it’s been a failure in terms of building solutions on top of these set of APIs. I mean, there are two ways I look at it. One is, look at the number of organizations that have literally sprung up overnight and become multi billion dollar empires because they were able to very quickly trade beyond the AWS platform very quickly trade on their solutions and go to market very, very rapidly because they leverage these APIs. And you’ve heard me talk about this a lot. There are higher order services that AWS has been focused on over the last couple of years, which truly do use a lot of these underlying first generations of APIs that they created so I actually don’t see this as failures.

Hilary Doyle: So Rahul, how would you respond to Alex’s concern that with no code we abstract away the key details?

Rahul Subramaniam: I want to start with saying that I’ve never met a developer who’s taken over an existing code base and said, “Oh, that previous code base was awesome.”

Hilary Doyle: I can second that. Yeah. Question for both of you is how important are languages in this kind of coding? Rahul, do you care about coding languages?

Rahul Subramaniam: I care about whatever’s simplest that gets the job done fastest.

Hilary Doyle: Okay.

Rahul Subramaniam: So that’s my only criteria. I don’t spend an inordinate amount of time worrying about the language that my developers use as long as it is well abstracted and developers can get their functionality done very quickly and they have a standard interface that they expose. Yeah, I don’t care about the language.

Hilary Doyle: Alex, how important is language to you code wise?

Alex Hudson: It’s a lot more important. Yeah. If you’re developing code, I think it is important to know more than one language. I think if you’re stuck in a language, you’re probably also stuck in a pattern of thinking. There are, obviously, some examples where it does make a difference. So for example, if you’re an AWS Lambda programmer, there are certain languages that start up a lot more slowly than other languages and you may not want to go there. And then depending on the size of the run time and things like that, that will impact your startup speed. There are still practical considerations like that that you always end up having to take account of.

Hilary Doyle: Thanks so much for being with us, Alex. This has been a great conversation.

Alex Hudson: I’ve enjoyed this, Hilary. It’s been great speaking to both of you.

Rahul Subramaniam: It’s been an absolute pleasure.

Hilary Doyle: Rahul, they say you should try to surround yourself with people who are smarter than you. And in your case, we all know that’s not possible, but you can surround yourself with brains. In this case, Steve Brain. He’s a colleague who has been itching to debate you, so we are welcoming him into the ring to expand on your conversation with Alex Hudson. Hey Steve.

Steve Brain: Hey, how’s it going?

Hilary Doyle: Well thanks. You heard the chat. What are your first pieces of takeaway?

Steve Brain: Gosh, it was a really cordial chat. Alex seems like a great guy. Wow. Maybe a little too nice.

Hilary Doyle: It was a debate, Steve.

Steve Brain: When you mean cloud API, the one level of cloud API is I want to store a blob and how I store a blob doesn’t really determine my architecture so I think you mean more than that when you say cloud APIs.

Rahul Subramaniam: I’m talking about things like Kendra, I’m talking about things like AWS Connect, I’m talking about things like all the vertical AI services, whether it is comprehend, recognition, forecasting, personalized. I’m talking about services like that which give you black box functionality with all the best practices baked in.

Hilary Doyle: Rahul, there’s going to be a need for code likely to fill in the gaps. And so Steve, what are your thoughts about the language that you should be using or the languages that you should be using to fill those gaps?

Steve Brain: Yeah, I think the real important thing to understand here is how big the gaps are.

Hilary Doyle: Yeah.

Steve Brain: Because I agree with Rahul, there’s some point solutions with APIs. Twilio have done a wonderful job at telephony. I wouldn’t build a telephony stack again. Stripe have done a wonderful job with payments, but these are vertical, deep specific APIs, but there’s still a lot of white space in between. And to fill that white space, and this really goes to the conversation of Alex and Rahul, I think I agree with Alex. The white space is broad and no code. You don’t just, like, drag from the Kendra API, to the Stripe API, to the recognition API and have an application. There’s white space you fill with code and we still need engineers. Liberal arts majors, we’ve tried it over and over to have them be engineers and we keep going back.

Hilary Doyle: Hey, I take offense to the direction this conversation is going in, but I will allow you to proceed.

Steve Brain: No knock on liberal arts majors. I’m just saying I wouldn’t want the writing my flight control system next time I get on the plane.

Hilary Doyle: Steve, just say it in [inaudible] and everyone will be fine.

Rahul Subramaniam: So let me just ask you this, Steve, in a more specific manner, does the programming language itself matter? I agree with you that there are gaps, but should it really matter given that at some point of time down the line, if these gaps are important enough, someone will come up with an API or a cloud service that you will want to replace what you wrote with.

Steve Brain: It matters for a couple of reasons. The first is that everything we think we throw away ends up having a 30 year lifetime. And everything we think we are going to have will last for 30 years seems to get thrown away immediately. And that’s partly because of the way startups work. Like you’ve got to move fast, you’ve got to be scrappy to be successful. If you are very careful and stayed, you generally don’t succeed.

Hilary Doyle: I’d like a summary. The takeaways from each of you. One takeaway, 30 seconds or less, Steve, you’re up.

Steve Brain: Cloud APIs are great, but there’s a huge amount of white space still between the APIs and programming languages and good quality code still matter a lot and that isn’t getting any easier.

Hilary Doyle: Rahul.

Rahul Subramaniam: I think I’m going to build on top of what Steve said and add that no one wants to own and manage all of this code, so even if you’re writing code to fill these gaps, fill them in a manner that are abstracted so that as soon as there is an API that’s available that can fill a gap you can switch over.

Hilary Doyle: Always building even with his arguments. Thanks you two. All right. One less brain in the room, but feels like less. Just kidding. Rahul, this is your moment to drive home to sell cloud APIs over old school programming languages. Assuming you’ve convinced our listeners, what are the tips they need to help things go smoothly?

Rahul Subramaniam: So this week my tips are going to be a little bit different. I mean, you kind of need to follow all of them for this to really make sense. So here goes.

Hilary Doyle: Oh my God, listen up. Yeah.

Rahul Subramaniam: First, stop spending an inordinate amount of time picking the programming language or the tech stack, and instead use the time to research cloud development patterns that you can just copy.

Hilary Doyle: Roger.

Rahul Subramaniam: Second, for any code that you write, make sure that the comment log answers the question about why that code is easy to delete. Now, this practice causes a mind shift change and makes developers write well abstracted code.

Hilary Doyle: Great.

Rahul Subramaniam: And then lastly, try to stay on top of announcements about new managed services and make use of every opportunity you get to delete the code that you own with one of these managed services.

Hilary Doyle: The three word summary, never stop decluttering.

Rahul Subramaniam: You nailed that one, Hillary. That’s exactly it.

Hilary Doyle: I’d like to get this PhotoVogue use case back on the runway, please.

Rahul Subramaniam: The only runway I’m familiar with are for planes, Hillary, so.

Hilary Doyle: You’ll be fine. Finally, I have something to teach you because this use case, Rahul, has been a welcome opportunity to revisit the fashion and art of 2017. You know, just to get the vibe. 2017, Moonlight deservedly wins the Oscar, La La Land does not, in one of the greatest mix ups of Oscar history.

Rahul Subramaniam: Yeah, I remember that one.

Hilary Doyle: Yeah. Okay. Yeah, see you’re right back with me. 2017, also, year of the puffer jacket, the pussy march hat, and the ugly sneaker, according to my browser history.

Rahul Subramaniam: Wow.

Hilary Doyle: No explanation needed, I’m sure. Fashion-wise, it was the year of yellow, although Pantone said it was actually the year of 15-0343 which is obviously green. And finally, Rahul, it was the year that Balenciaga put a $2,100 tote bag out into the world that looked almost indistinguishable from the 99 cent IKEA version. Oh my God. The memes.

But in the midst of all of this hurley burley, there was PhotoVogue just trying to meet the growing demands of its photographers and editors over a hundred thousand photographers already using the platform, which meant this old school on-prem business had a sudden and extremely pressing need to scale AWS to the rescue per usual. Yeah, sure. They brought speed, but what else did AWS resolve for PhotoVogue. Spotlights on you, Rahul?

Rahul Subramaniam: Hillary, I didn’t understand most of what you had said in the beginning.

Hilary Doyle: Oh my God, I feel so seen right now. Story of my life with you. Go on. Yes, yes.

Rahul Subramaniam: But I get AWS, the hundred thousand photographers, and the scale, so let me focus on that. Okay.

Hilary Doyle: Okay. Stick to your knitting.

Rahul Subramaniam: AWS was a godsend for PhotoVogue’s digital team. Within three months, they were experiencing 90% faster UX that scaled seamlessly, and at the same time, lowered their cost by 30%.

Hilary Doyle: Amazing.

Rahul Subramaniam: One, they wanted to store massive and an ever-growing number of large images.

Hilary Doyle: Yeah.

Rahul Subramaniam: And I think it was what, 400,000 images that we spoke about?

Hilary Doyle: Yes.

Rahul Subramaniam: Each being about 50 megs and S3 was just the perfect solution for this kind of storage. It was very inexpensive to just switch over to S3. Second, they wanted to make it really easy for the photographers to upload these very large images without causing their infrastructure to bottleneck. Now, traditionally, you would write code and you would own the entire upload process and dump it into whatever data store. But with S3s pre-signed URLs, these uploads were just so simple because they did not need to use any of their infrastructure to have a massive scale of uploads happening. So they could have a million photographers upload their photographs in parallel and they would actually not see any load on their own infrastructure. It is just an incredibly beautiful solution.

Hilary Doyle: And that was thanks to cloud APIs.

Rahul Subramaniam: Absolutely.

Hilary Doyle: PhotoVogue from dress code to no code, A-list to API. You love my jokes. That’s it for us, for now. We will be back. You’ve been listening to AWS Insiders from CloudFix. I’m Hillary Doyle

Rahul Subramaniam: And I’m Rahul Subramaniam.

Hilary Doyle: CloudFix is an AWS cost optimization tool. You can learn more about them at cloudfix.com. Check out our show notes.

Rahul Subramaniam: And leave us a review. Please follow us.

Hilary Doyle: We’ll catch you later.