All the latest news and views from the world of Java

The Podcast

The Late Podcast 4 : Amazon AWS Interview

14-Aug-2017 in Podcasts

If this podcast appears to be out of order, that's because it is! In June we recorded an interview with Ian Massingham, Worldwide Lead, AWS Technical Evangelism at Amazon Web Services. Unfortunately we weren't allowed to publish it without his permission, which we now have!


Matt:Okay, welcome to, we think this is number four in the series of our All About Java Podcasts. I'm Matt Greencroft.

Richard:I'm Richard Chesterwood.

Matt:And with us today, very excited, we have Ian Massingham who is a technical evangelist from Amazon AWS. Welcome Ian!

Ian:Hi, thanks for inviting me to participate guys, I appreciate it.

Matt:Well, it's great to have you here. And it's hot on the back of, yesterday was the AWS Summit in London.

Richard:Day before yesterday.

Matt:Day before yesterday, it's gone so quick this week. And you were just telling us actually, before we started here, that you had more people than you expected.

Ian:Yeah, it was our largest event ever in the UK. We expected around about 6,000 guests and we actually had over 7,000 so we had a really good turnout. Obviously our CTO, Werner Vogels, a larger than life character in every way, gave the keynote. We had over 40 technical breakouts covering actually many, many different aspects of AWS from beginner to advanced and also across the services portfolio we've got. And as usual we were able to feature a huge number of customer speakers as well, so pretty successful event, and already had some good feedback from some tired people that worked on it, and some, good feedback from some customers that attended as well, so it's been a good event this week. Yeah.

Richard:And what we were debating was, do you have a handle on, or I guess you've got the figures on, how many of the people attending were new customers or-

Ian:Yeah in fact, our managing director for the UK and Ireland, Gavin Jackson, opened the keynote and talked a little bit about this. So around about 40 percent of the people that were at the event were new to AWS or experimenting with AWS.


Ian:This is not unusual for AWS summits. Obviously, they are free events that we run in cities around the world and we do get a lot of customers coming along that are curious, that are just getting started with Amazon web services, want to learn more about how they can put the cloud to work. So it's actually pretty common to have a high ratio of newbies at events like that, and that's why we have the diversity and the content programme with the intro-level content and the more advanced sessions as well.

Matt:It says ... Do you see this is an event that gives people a chance to really then explore and to find out more? Because I mean we obviously have an interest because we use AWS for our own company, and so we are incorporating elements of it in the courses that we do. But one of the things that was going through my head is what's the reason that Amazon puts all this effort and all this resource into producing these massive one day events?

Ian:Well customers tell us that they're valuable. I mean that's the real reason that we do anything at Amazon. We have, not just Amazon Web Services, that's Amazon more broadly. We have obviously Amazon leadership principles that we use to run the business, and the first one that comes out when you look at the list of 14 leadership principles on the Amazon website, which encourage you and the audience to do, if you've not already done that.

You'll see customer obsession is at the top of the list. We have processes that we use, methodologies that we use. One called working backwards where we try to ensure that everything we do within Amazon starts with and is centred around the needs of customers, and this makes us able to run a lean operation where we're able to prioritise things effectively and make sure that we only focus on activities that are important to customers, so that's good for efficiency. But it also makes sure that we remain beyond customer-focused in what we do, and the reason that we run these summits is because customers repeatedly tell us that they are a valuable tool in helping them make more and better use of the cloud. That's why we run them. Obviously it helps us encourage and accelerate adoption of the services, so it gives us a sustainable business by doing that. But that's not the main reason, the main reason is we want to support customers in achieving their objectives, and one of the ways we do that is by educating them.

Matt:Okay, thank you. So should we get into some of the detail?


Matt:'Cause I think, we certainly, well I came away from yesterday ... Sorry, I keep wanting to say yesterday, I think cause it was such an intensive day, I needed to a day to recover-

Ian:You can't remember yesterday.

Matt:Yeah, yesterday I blanked out. But I came away from the summit, definitely with one of the biggest messages I got was serverless. Serverless is, it's obviously not a new thing, but it's a growing thing. And I guess we were just talking a bit about, what we you mean by serverless, what are some of the use cases. We're thinking about how actually it might solve a problem we've got.

Ian:Yep. Yep.

Matt:So you want to tell us a bit about from your point of view?

Ian:Yeah, certainly do that. So the term serverless is not a term that was invented by Amazon Web Services. That's a industry or maybe accurately community term that's arisen as a result of architects and software developers building applications using this new model, using this new paradigm. What we launched back in 2015 ... I think I'm getting my dates right. At the end of 2015 was a service called AWS Lambda. We described as an event driven computing service. With AWS Lambda what you can do it create software. Initially we started with support for JavaScript and Python. We've now added Java and C-Sharp support as well.

You create software. You package it up into deployment bundles in a defined structure with a specific entry point. And then that software, those functions, those AWS Lambda functions to give them their full name, they're activated in response to events. Okay. And actually we support a broad range of different event sources. We started out with a few but over time we've been adding more and more event sources. And each time one of these qualifying events occurs, your AWS Lambda function will be invoked and it'll be passed metadata about the event that has triggered it.

So maybe a good way to illustrate this is with a real world example. Maybe I've got a website or application that requires image or video transcoding. So I'm receiving images from my customers in a variety of different formats, maybe a variety of different sizes, but I need them as .png’s in a specific aspect ratio and a specific size to display in my UI. How might I to go about doing that?

Well in the old days I could have had an Amazon EC2 instancing around, listening to a queue maybe, popping messages off that queue, and processing images as they arrived.

Richard:And pay your bills.

Ian:Oh, yeah. I was gonna say it's got ... there's an obvious advantage there. Which is it's a event driven process. So I initiate an activity in response to getting a message in my queue, but it's also a process where I have to have that listener sitting around the whole time or when my application's active, polling that queue to see if there were new messages there. So it's not a event driven. Not a push based model. It's pull based model.


Ian:And I've got the cost of that EC2 instance whenever I'm performing that function I'm running an instance and I'm paying for it by the hour as you know.


Ian:Okay. Now I can auto scale that, because can scale on the queue depth.


Ian:If I wanted to do so using a CloudWatch metric, but it's still going to have fixed costs. There is a floor cost there that's going to be incurred regardless of whether or not I've got a message in my queue. Implemented the same thing with AWS Lambda. Well I set up and Amazon S3 bucket or object store. I configure event notifications on that bucket. Each time an object is added to the bucket, I'm going to trigger a specific Lambda function. I push my photos into that bucket. Each time a new photo arrives, a Lambda function gets triggered. It's passed metadata about the new object that's been created. It can process the object depositing it back in the same or a different bucket. When it's been transcoded to meet the size and format requirements that I've got.

So what are the benefits? Well I've got no fixed cost. If I have not photos arriving overnight, guess what? I have zero costs.


Ian:Conversely, if I have a thousand photos arriving concurrently, actually I don't even need to change my Lamba concurrency limit now within my account, because we recently increased that to a thousand concurrent functions.

Richard:Oh right. Okay, that's neat.

Ian:So we can run a thousand concurrent transcoding jobs without having to change anything. If we want to do more, just request a limit increase. From Amazon Web Services, we can increase that and I know customers that have got that limit set at hundreds of thousands and higher of concurrent functions.


Matt:Okay. Wow. Beautiful.

Ian:We've got practically unlimited scalability. You don't have to manage failure conditions. You don't have to manage maintenance of EC2 instances. You don't have to worry about distributing them across availability zones.


Ian:You get all these benefits of simplicity, cost efficiency, and you don't have that floor cost. No activity, no cost.

Richard:Wow. So you don't have to worry about security, patching servers, that kind of thing?

Ian:You have to worry about security of the operating system or patching the operating system.


Ian:Obviously you still need to worry about the security model, or take into account the security model of the functions themselves.

Richard:Of course. Yeah.

Ian:And there's a few things though that are relevant actually, we can talk about. The first thing is if you want to, you can run the functions inside a VPC, and you can attach an ENI to them, an elastic network interface to them; and this can allow your functions to work with data sources or state stores that are inside of VPC.


Ian:So think a relational database is running in RDS.


Ian:Or think a MongoDB or Cassandra clusters sitting inside your VPC. If you want to use those as a state store rather than our own DynmoDB, well you can do that. You can run your Lambda functions inside a VPC and give them secure access to resources.


Ian:The functions actually run with a security group attached to them. Just like instances. It's exactly the same security model that you would have for EC2 but you remove the overhead of running that EC2 fleet. There's some caveats there, but we're not going to discuss them here. Check the documentation. Things like having enough IP addresses in each subnet where you're going to create you functions. If you've got high concurrency-


Ian:... you need lots of addresses available so you can create lots of VNIs and attach them to your functions. So there are some design considerations. Everything's documented on our docs. Second important part of the security model, is the AWS IAM or identity and access management, but it plays a role in Lambda. Both in controlling who can invoke functions via our API, but also the functions themselves run with IAM roles. So you can have functions that can communicate and initiate actions on other AWS APIs. And actually the example I've just given where the function not only receives metadata about that object on S3, but also wants to read the content of the object so it can perform that transcode. Well that function would be running with an IAM role that gives it a permission to access that particular S3 bucket or that particular S3 prefix within that bucket.

So you have this fine grained access control that comes with IAM. Which is in play whenever you run Lamda functions. You can have a very strong security model around your functions as well.

Richard:Perfect and I think what would be attractive to our customers if they're thinking of experimenting with Lambda is I think the pricing is very sort of straightforward and you're not with experimenting your going to nowhere near leave the free tier.

Ian:Yeah. You can run quite significant applications in AWS Lambda without leaving the free tier. We offer a million function invocations and 400,000 gigabyte seconds of execution time per month for free forever. So it's not like EC2 where your free tier runs out after a year. With Lambda you can use that for as long as you use AWS. And as we're in Leeds, might be worthwhile talking about how customers use this. There's an agency here called Parallax. Which you might know.


Ian:Good Yorkshire company. Run by several Yorkshire men and Yorkshire women. They're a digital agency so they're working in the advertising digital branded apps space. They also do digital signage and a few other things. But last year they worked on a project with David Guetta for the Euro 2016 football championships. They created a browser based application to support the creation of a record called This One's For You, which David Guetta recorded for the 2016 European football championships, and they recorded the voices of a million fans. Okay. They had a browser based app where you could go load . You get David Guetta explaining to you on a video what you needed to do.


Ian:You'd then get an experience where you recorded your own voice via your browser. Whole thing was implemented using this serverless pattern. Okay. The audio artefacts were stored in S3. The source for the application was delivered from S3. There were endpoints that were expressed using AWS Lambda for the various transactions that took place within the application usage flow, and at the end of it they generated some customised art work. The album cover. The record cover for This One's For You with your own personalised graphics.


Ian:On top of it which you could then share on social media, but the whole thing was built completely serverless.

Richard:Wow. That whole thing?

Ian:Yeah. The whole thing was built completely serverless, and the whole project cost Parallax less than 500 dollars over a three month period.

Matt:Super. Goodness me.

Ian:So very, very cost effective. You want to know more about that, jump on Twitter. Find a guy called Mr. Real and tweet him and ask him to tell you more. He's the guy that built it, the Parallax gems soul. He's actually in AWS community here.


Ian:His definitely a friend of AWS, but also a great JavaScript developer as well.

Matt:Fantastic story. It is. I think we could be re-engineering or whole site after this cal.

Richard:I've always thought it. My entry into ... I'm not sure if it was on your presentations, or webinars, or where it was, but I was told wherever you think of Cron jobs ...


Richard:... think of a Lambda function.


Richard:And I think my thinking's moved on from that little bit now, but now I'm starting to hear entire real estates I can't wrap my head around.

Ian:Yeah and then this is partially to do with the extension of the number of supported events sources. So I talked about S3 when I started. You just mentioned Cron. Well CloudWatch events is our scheduling event emitter. So we emit events on a schedule using CloudWatch events.


Ian:And those events can act as Lambda events sources and then trigger Lambda functions on a predetermined schedule. So any scheduled job that you would run via Cron.


Ian:As long as you can express the scheduled job in JavaScript, Java, Python, or C Sharp, you can run it. Of course and you can wrap and access the features of Amazon Linux inside these programming languages. So it's the entry point and it has to be in one of those four supported languages. You could actually compile Golang and deploy it in your deployment bundle and run Golang binaries on Amazon Linux as part of the process.

Richard:Oh. Okay.

Ian:Or call out to shell script.


Ian:The shell commands within your JavaScript, or Python, or within the other programming languages presumably it's supported there as well. You've got a lot of flexibility as to what the programming model is as long as you use one of those four supported entry points. And the event emitter is the thing that does the scheduling but there are other even emitters as well. The, our API gateway, so you can express a restful API or other API structure by assigning resources and actions to Lambda functions so when they hit that API endpoint and request that particular action on that specific resource, I can implement the logic required for that action using a Lambda function.


Ian:Okay. So we have an API gateway. It's very common to use that as a mechanism and to build a multi-platform backend for mobile and web applications, and our API gateway actually has SDK generation for JavaScript and Java as well.


Ian:So if you're writing web apps, you can build your skeleton SDK directly out of the API design that you built on our API gateway. That's a service that can be used as an event source. AWS IOT, so if we connect the device applications, we have a rules engine can evaluate the content of messages that come from connected devices. And one of the targets for that rules engine can be AWS Lambda. So you can implement backend logic for connected device apps using Lambda. If you're building appliances, or connected vehicles, or connected street infrastructure, the logic and backend infrastructure for the can run in Lambda on demand. Amazon Kinesis, you know this? It's a-

Richard:Very little experience so far. There's a stream-

Ian:Yeah. High volume. Well data streaming any volume actually. So think Apache Kafka. But while Kinesis enables you to establish a similar environment though, it removes the heavy lifting of having to deploy, and operate, and manage failure conditions in your stream management service. We deliver that as a service to customers. Every second that stream can be polled and if there are new records within the stream, they can be processed by AWS Lambda with a configurable batch size. You can basically use AWS Lambda as a mechanism for responding to real time data streams. There could be other event sources that I've forgotten ... our Amazon CloudWatch events-


Ian:... Amazon CloudWatch logs, so you can respond to log events. You can respond to events that are emitted by other AWS services, using it was AWS Lambda. We already talked about using that for scheduling as well.

Richard:Yeah. Yeah.

Ian:There could be more but these are some of the cool ones.

Richard:But we have our one Lambda that we have in production at the minute, we are doing more, but response to an email that sense-

Ian:Oh, yeah. Of course. Yeah. Yeah.

Richard:Yeah. So comes through-


Richard:... SES. Comes through SES.

Ian:Yeah. Simple email service yes.

Richard:And we do some processing of the email and it shoves attachments onto S3.


Richard:And then sends a message to a queue which is then picked up by another microservice in the system.


Richard:So very simple. I should say to anybody listening to this, I think in Java we obviously already use the word Lambda and it's a slight scary area.


Richard:And I can assure anybody trying Lambda it's the jar file in Java.


Richard:In Java it's a jar file and you have a special entry point method but apart from that it's-

Ian:Yeah. It's just standard Java. Yep. Yep.


Ian:I can say for Python developers as well it's just the same. You have a special entry point but other than that it's just standard Python.

Richard:Yeah. And presumably there would be no problem with ... I mean when we say Java we really mean just Java class files. So we could ... we haven't tried this, we could use Scala or the JVM languages.

Ian:Yep absolutely.


Ian:Yep. Yep.

Matt:Fantastic. Is there a length ... As I understand that Lambda functions are going to relatively short lived, so is there a maximum execution time?

Ian:Yeah. There is. There is. There's a five minute execution time cap.


Ian:So this is one of the constraints. If you've got a long running job that needs to run for more than five minutes, then there are some other approaches that you can take. Which we can maybe talk about a little later on. So you do have some constraints. And that really is ... I mean it's there as a backstop really to prevent customers from having functions that don't exit cleanly.


Richard:Right. Okay.

Ian:So you don't want to, obviously because you're paying by the hundred millisecond, 128 megabyte memory footprint chunk for your granular billing. Okay.


Ian:You don't want to have customers that are hitting unnecessary charges because for some reason their functions are not exiting cleanly. There may be in a state which is hung, so that time limit is partially there to protect customers from over billing as a result of functions not exiting cleanly.


Ian:We've seen other approaches that customers have taken if they want to mix event driven programming models together with long running jobs. You talked about one of them which is SQS queues where you might receive and event in Lambda, push that into a queue, and then have an conventional EC2 worker tier coming along and picking up those long running jobs.

Richard:Sure. Okay.

Ian:This can only be helpful if those jobs require specialist resources. I mean what if the job requires a GPU? Well if you have a EC2 instance pick up the job, you can then take the event driven initiation, but you can process it with one of our P2 instances. Which has the high performance and video GPU accelerators in them. So you can mix the right computing resources for the right job, but still benefit from the event initiation. And then the other way to do it of course is with docker containers on our service. ECS, the EC2 container service. You could have a EC2 ECS cluster sitting there waiting for these longer running jobs. And because as I said before, Lambda functions have IAM roles. You could give a Lambda function an IAM role that allowed it to initiate tasks on ECS. So running a collection of containers in response to an event as well.

Richard:Right. Okay.

Ian:Again a quicker way to initiate those tasks and give you more fine grain control over how you place them using out scheduler. There's a lot of stuff you can do there if you want to mix and match these different models.

Richard:Perfect. And I think did you say, I think it's a five minute?

Ian:Yes. Five minute limit.

Richard:300 seconds.


Richard:Are there any other restrictions? Can I ... if I'm using other libraries, can I deploy the-

Ian:You can. There's a maximum deployable size. I forget the number, but it's in the docs. And there's also a maximum memory cap as well. I think it's 1.5 gigs.

Richard:Oh. Okay.

Ian:But you probably want to check the documentation for that as well.

Richard:Sure. Okay.

Ian:So you can't dial in more than 1.5 gigs of allocated memory per function. When you do dial up and memory allocation is something that you do at function creation time, where you can tune later on by changing the attributes of a function in the API push deployment. That doesn't just scale memory, also scales CPU allocation, and it scales network bandwidth allocation as well. So all host resources scale linearly in accordance with the amount of RAM that you allocate to the function.


Ian:So if you've got a function that needs a lot of CPU time, but is light on memory, you can still improve it's performance by dialling up RAM.


Ian:Because these other resources will scale linearly as well and that's the charging metric. The number of 128 megabyte chunks that you allocate to that function will drive how much you pay for it per hundred milliseconds.


Ian:But you're getting other resources as well as RAM.

Richard:Yeah. Wow. Mind blown. We're probably thinking in the background about how ... I mean we've got two things to think about. Obviously our customers want to hear about this though to see how it fits in with our software development courses, but we're also developing using this stuff as well. And I know Matt's going to, he's going to raise 50 cases for me tonight.

Matt:Well. I'll probably but I mean actually one of the things that seems to be first is that we our platform is a monolith that is gradually being moved bit by bit into this microservice architecture.


Richard:With enormous amounts of pain.


Richard:But I must stress most of the pain is getting rid of Grails.


Matt:Rather than it's true. So that's a side topic to today. But what's interesting is that we are taking advantage now of having a load balancer, with multiple servers supporting our front end. It can scale all that kind of great stuff. And yet they'll be bits of our architecture, particularly the daily billing process, where you don't want that to scale and want multiple times. We've got to ... there are bits that need to be pulled out and run once. Now daily billing is probably a good example because actually every ... that process, yes it has to run once, but we don't want the server sitting there running 24 hours a day, that's going to be operational literally for two minutes just to trigger off-

Ian:You don't with our daily billing process, I mean it's quite a simple phrase, daily billing process.


Ian:I used to work in telecom so I know that daily billing process can actually be quite a complex-

Richard:There be dragons.


Ian:Quite a complex application. So there's something else here that we should probably talk about, which is a relatively new service we've got called AWS Step functions.

Matt:Ah. This was on my sheet.

Ian:Yeah. And this allows you to coordinate more complex applications that are built out of multiple Lambda functions. Your daily billing process might have a injest transform process step to it.



Ian:Well those need to run sequentially and actually you probably want some stop go logic across those. What's the point of trying to push the data through to the next phase if you failed the proceeding steps.


Ian:With Step functions you can define these state based flows for applications that have multiple sequential steps, might have parallel steps, might have logic gates with an execution, flows that you want to build. You can build it all visually using the AWS Step functions designer and then you can chain a collection of Lambda functions together with that right reliability characteristics to enable you to build more sophisticated versions of your daily billing process.


Ian:Which could be quite a complex thing to unpack when you look at it. So I mean it's probably beyond the scope of this to talk about it in detail but if you've got a use case like that, it's well worth taking a look at that service.

Richard:That's fantastic.

Matt:Yeah. That is.

Richard:Yeah, I just literally half an hour ago noticed that. Noticed that service I've never heard of it.

Richard:So I wrote must ask about Step function.

Ian:Yeah. There's some core videos about that on YouTube from AWS re:Invent last year, including one from a guy called Tim Bray, who you might know is the inventor of XML.


Ian:And also worked on that service as one of the principal engineers on that.

Richard:Really? Wow.



Richard:So a workflow around, so there would be lots of small Lambda functions that you're gathering together in a workflow.



Ian:And you can house a sequential, parallel, or logic based execution. I've got a function which exits. I might have a couple of different exit states. If it exits successfully, do this. If it fails, do that. And those can be two of the Lambda functions that you root to on the basis of exit conditions as well.


Ian:So you can build sophisticated logic flows using Lambda functions as building blocks.

Matt:Sounds very interesting.

Richard:And we have a graphical interface. Can we script that as well? Can we ...

Ian:Yeah. You can. Yeah.

Matt:That sound fascinating and I'm excited to actually go and have a look at it right after this call.

Richard:That's going to create me some work. I can feel it.

Matt:I certainly am. But actually now I mean I can exactly see that the billing example, yeah, I can really, because each individual customer is a very simple process of try and bill them and it either works or it doesn't, and based on who they are and what the error code is, is yeah what you do.


Matt:But actually, yeah, so to break it down until you have it running once per customer, and having that in a flow, I can see being a nice solution.


Matt:And of course because it's broken down hopefully easy to maintain as well. So if our credit card provider wants to change something at their end ...


Matt:Which should be a reasonably straightforward-

Ian:Just change that function and it performs that.

Matt:... process. Yeah.

Ian:Performs that action. Yeah. That's right.


Ian:And it also reduces the ... I mean one of the reasons customers are moving towards microservices is it reduces iteration time, it reduces the testing coverage that you require for that change. If that's a separate function, it stands alone, it doesn't have dependencies either intentional or unintentional dependencies on either part of code base. Or the only thing that you need to change is that, but also the only thing you need to test is that change.

Matt:Yes. Yeah. There's some interesting ... I mean one of the other things sort of just mentioning that is around some of the customer stories. I think it's fascinating some of the people we heard present and particularly the Train Line. Who were talking about ... Sorry. For those who don't know, the Train Line is, I thought it was a UK company, it turns out it's international. Providing train booking services to customers worldwide.

Ian:I mean it's a super interesting company. It's a super interesting AWS customer case study and one that is actually featured at a couple of AWS events. Chris Turvil is the head of Cloud at Train Line. He was on stage with our CTO, Werner, at re:Invent last year talking about their usage of AWS, and obviously re:Invent is in the US. And I can say there were surprised faces in the audience when Chris was talking about the scale of Train Line, how big it is. You know, it's the sixth largest retailer in the UK.


Ian:With revenues of around 2.5 billion pounds a year. And until quite recently they only had one product in one category which was train tickets. Now they also, I think, just moved into some other transport modes as well, but they were doing just train ticketing for a long time. Operating across Europe. And they have a really amazing service. I mean I travel by train every week for my role pretty much from Yorkshire down to London. I work a lot and I really love the product. It's so easy to use. They have integration with expense systems like Concur. You can buy a ticket and create a diary entry for the travel immediately so you know when you need to be at the station. They've even got this new feature called Busy Bot which will show you visually when you get to the platform, where abouts on the train there is empty seats. So where you know where to stand so you can get a seat without having force your way through a busy train.

Matt:Wow. Yeah. That sounds good.

Ian:It's a really great product, but they've also done a lot of change in their internal ... the way in which they deliver technology over the last few years as well. They've broken with applications you've described, moving to services based architecture. They've really increased the velocity with which they can move through their release and product iteration process to get new ideas out there.

Matt:They've done that very quickly as well. That was the surprising bit of the story for me. Is how could they have moved from a monolith to a microservice.

Ian:They have. They have and I didn't see Chris' talk at the summit this week. I don't know him but I didn't see him this week. But probably what he was talking about is moving from project based thinking to product based thinking.

Matt:Absolutely. Yeah.

Ian:So something that he talked about.


Ian:Once you've got that ownership and the people that own the different products that make up your overall, service have ownership of them. That in itself just naturally increases velocity. People have got more control. They've also got the tools that they need to move ahead more quickly and you sort of you're not only decoupling your application architecture, you're also breaking up the product and service that you provide into chunks that are more easily understood and more easily evolved.


Ian:This results in this flywheel accelerating I think where you're equipped with the right tools to make change quickly, so people are more motivated to make change quickly. If you see what I mean.

Matt:Yes. Yes.

Ian:Kind of accelerating flywheel. It's worked really well for them.

Matt:Yeah. Interesting. What's the ... So certainly just sort of thinking a bit more wider then, so definitely serverless is the big thing, or one of the big things at the moment. What does Amazon see are the other particularly big things that people are grasping and running with right now?

Ian:It's probably better to talk about new things that we've launched recently because obviously we've only launch products that customers tell us are important and valuable to them. So if you take a look at things that we've announced recently, it's quite a good indicator of what some of the big trends are that we see from our customers. The first is a continuing drive towards the data driven enterprise. Our customers want to get more value from data and they want to get more value from larger data sets; but at the same time be cost efficient and not have to run a lot of infrastructure in order to do that. We've announced a few new services for that.

One called Amazon Athena. This allows you to query data using an SQL based interface while the data remains in Amazon S3.


Ian:So there's no need to run an EMR cluster, Elastic map reduce, which you might have covered in some of your courses, no need to run Amazon Redshift, our data warehouse. You can map the data using a data description language into a relational format while it remains in S3, and then you can query it using a regular JDBC based interface.


Ian:What happens under the covers is Presto is running on the data within S3. So actually we're using Presto to create the SQL based query interface and to create the table based structure within S3 and allow customers to ask regular business intelligence questions using SQL of data while it still resides in S3. That's something we announced last year. Something similar on Redshift called Redshift Spectrum that allows you to use the Redshift engine. So our data warehousing engine and integrate data. Some of your data stored in Redshift clusters and then larger data sets still stored in S3, and you federating the query operations. The query planner is on Redshift, but some of the query operations takes place on the data whilst it remains in S3. It's very good for extremely large external tables that may be too big to load into a Redshift cluster.



Ian:That's pretty big data. There are still use cases like that.


Ian:So that's something new. Then we've announced an edge computing service called AWS Greengrass. It's in the IOT domain. It allows you to push some of the functions that are present within the AWS IOT service into edge computing devices. This is things like the device shadow, the AWS IOT rules engine, the authentication, and authorization capabilities that are present within out IOT gateway component. These can be run locally within the AWS Greengrass runtime. Which can run on either Intel, ARM. or on CPU architectures and it enables customers to build sophisticated IOT applications without having to have the environment permanently connected to the network.


Matt:Ah. Right. Okay.

Ian:Or permanently connected to the cloud.


Ian:So we see use cases for this is in resource extraction, in mining, in agriculture where our customers may have IT infrastructure that they want to turn into intelligent connected device infrastructure which is away from reliable network connectivity.

Richard:Right. Yes. Okay.

Ian:Maybe under the ocean or underground for example.


Ian:If you're thinking about resource extraction in mining use cases.


Ian:So IOT at the edge and sophisticated IOT capabilities, but running at the edge disconnected from AWS, disconnected from the internet.

Richard:Wow. Okay.

Ian:So that's something. And then a third area of innovation has been around our AI. We've been doing a lot in this area. We've announced a significant investment in the set of contributions into a deep learning framework called MXNet, which is now an Apache project. So Apache MXNet and it's a toolkit for developers that want to build neural network based applications for things like image recognition, document classification, and other applications of neural networks beside. That's something we did. Last year we announced that.


Ian:And we've also got some abstracted services that make it super simple for developers to access AI features. An image recognition service called Amazon recognition. Where you can give the service an image and we can do things like seam detection. Looking at this room that we're seeing here, I might see the LCD screens that are on these laptops, I might see laptop computer, or I might see coffee mug, I might see headphones. Getting metadata back about the image that I've provided which tells me what's in it.

Richard:And it's slightly ... I had a play with it. It's slightly scary.

Ian:It can detect faces and tell you how old you are, whether you're male or female, whether your smiling. It can do a lot on the facial as well. We also announced recently a feature for celebrity detection.


Ian:So if you have a photo of-

Richard:Which got a lot of press coverage didn't it.


Richard:It went down well.

Ian:If you've got a celebrity in your scene it will name them for you. So that's-

Matt:I've tried it on several photographs that I have.

Ian:Are you a celebrity?


Ian:No. Okay.

Matt:Very disappointed.

Ian:So that's something.

Matt:Am I?

Richard:Afraid not.

Matt:Oh well.

Ian:Yeah. There's in ... for that service in the console in the AWS Console you'll find there's an onboarding sort of test tool, where you can log into the console, browse an image on your local machine, push it and do the seam detection and celebrity detection directly within the console. Now we obviously think developers will use it via the API.

Richard:Of course.

Ian:But you can test using the console. You can get the funny stuff, but for those of you that aren't watching in person, which is of course all of you right now. I have white hair. Okay, and this is something that fools the system into thinking I'm a little bit older than I am. Okay, so yeah, that's not quite so funny.

Amazon Polly a similar service. This is for speech generation. So you give it-

Richard:Generation right.

Ian:You give it text and it returns back to you the spoken word. Okay.


Ian:27 languages. 42 or 43 different voices.


Ian:From English to Icelandic.

Matt:That's huge.

Ian:In terms of-

Richard:And obviously callable through an API I bet.

Ian:Yep. Callable through an API and you can either stream the audio or download an MP3 from the API. You can use something called SSML, speech synthesis markup language, to mark up your text, to control pronunciation, inflexion, have words spelled rather than pronounced, even switch language mid sentence if you're transcoding say a premiership football.


Ian:You might want to pronounce the names of those Spanish or Portuguese players in Spanish or Portuguese. You can do that with the service by switching language midway through the rendering process as well.

Richard:Wow. Gosh.

Ian:And then lastly, something called Amazon Lex. Which unbundles some of the technology inside the Amazon Echo and makes it available for developers to use. It supports both audio and text based interfaces, and it makes it much simpler for customers to build chat bots, or conversational interfaces.


Ian:So again, there's a really good console experience with this. If you log in to the AWS console, I think there are now three ... yeah there are three template bots there that you can provision. One for booking travel, which support airline and car hire bookings.


Ian:Or in detection of intent and the skeleton required to execute that type of transaction. Another one for ordering flowers, and a third one which is an appointment scheduler. So you can say something like, "I want to book a flight from London to New York," and the neural network behind the service will figure out what questions you need to be asked in order to complete the transaction. When do you want to travel, and what date, maybe which airline.


Ian:Okay. So dynamically builds the back and forth flow that is required to get all of the data required to execute whatever intent it's detected. Very sophisticated service. We integrate with Slack or provide direct integrations with Slack, with Facebook, and we also have these enterprise SAS connectors. You can put these interfaces on the front of Microsoft Dynamics, or Salesforce, or Marketo and build conversational interfaces into existing enterprise systems as well using the tool.

Richard:Fantastic. And these services are launched right here-

Ian:They're all generally available.

Richard:... in the old regions?

Ian:Yeah. They are. Not in all the regions.


Ian:So Lex is available in US East one. The other two services Polly and Recognition are available in several regions around the world.


Ian:And Lex only supports English at this point. This point in time as well.


Ian:But the other services I said, Polly, 42, 43 voices, 17 ... No. 43 voices 27 languages.


Ian:And Recognition obviously rather it's images so ...


Richard:I mean the problem with all of this, and it's a nice problem, is keeping up with it all. You know, we turn around and then look again and more new services. Obviously that's your daily problem isn't it.


Richard:How do you keep all this stuff in your head?

Ian:Yeah, so, I mean I spend a lot of time learning about AWS. It's part of my role and part of the role that my team have as well, is to be up to date. It's difficult to be a domain expert on everything, but we find that customers are pretty good at self selecting areas that are interesting to them.

Richard:Yes. Of course.

Ian:Obviously we have AWS blogs. We have the master, the main AWS blog which is written by one of my colleagues, Jeff Barr, and you can find that on

Richard:We'll add the link to the show notes.

Ian:Yeah. There's an RSS feed there. Which will every morning when you wake up, have three, or four, or five new things that you can find out about short form content. Actually there's a lot of contributors now, as well as Jeff writing there because there's such a volume of releases, it’s very hard to have one person to keep up with all that.


Ian:And then we have specialist blogs as well. DevOps, compute, big data, security. So if you're were a domain expert in one of the fields or want to become one, then you can subscribe and find technical content about particular areas of interest that you have as well. And then we have online video assets. So AWS re:Invent has hundreds of videos from re:Invent last year posted on our YouTube channel that you can dive into and learn more about these services.


Ian:Similarly the larger AWS summits around the world, we'll record a lot of the sessions and make them available online. So there's a lot that you can learn about AWS by using these online resources, as well as user groups, and in person events of course as well.

Richard:Great. So how many services is it now?

Ian:We have over 90.


Ian:Over 90 primary ... Over 90 we could call them primary services.


Ian:Or top level services, but the other thing is we have an iterative model. So as customers use services like Amazon Redshift or S3, which are very, very popular services, and overall are very, very popular service, we get a lot of feedback from customers about how they can be enhanced. And the more feedback that we get the more accurate and timely we can be in pushing new features into the service. It's one of the, I think one of the underappreciated benefits of using the cloud. It's great that you can access all of this stuff without having to build it yourself, but also everything improves over time.


Ian:Without you having to improve it yourself. Anyway, so if you're using a platform like AWS, you'll find that more and more features and capabilities get added as a natural sort of matter of course in running services.


Ian:That's why it's really a powerful tool for developers in my view.

Richard:I've been racking my brains to think do you ever remove services? I can't think of any that disappear.

Ian:We don't remove them or deprecate them because obviously customers depend upon the APIs that we provide. So it would be really disingenuous for us to remove a service, I think, that a customer is using. We'd always try to avoid doing that if it was at all possible to avoid it.


Ian:But what we do do, is when we launch new regions, we don't always retrofit-

Richard:I see.

Ian:... all the services into the new regions.

Richard:That's a nice way to do it. Yeah.

Ian:So if you look at some of the services that have been around a long time, you'll find that they're not, the ones that are no longer promoted but are still in use ... There are just one or two of those actually. They are not necessarily going to be present in new regions that we create.


Ian:There's also where we do have there are occasions where we have to make changes. Take the signature protocol that's used for API requests. Probably heard of Sig-V-4.


Ian:Is our current signature protocol. That obviously implies that there were previous versions, and those, some of them have been deprecated, and some of them are not being enabled in new regions that we create. And in that case, we try to give customers the maximum possible amount of notice. We can obviously see through our logging of platform usage which services are being used by which customers. The data that you store and process on S3 on Amazon Web Service's completely opaque to us, but we can see, obviously, we have to see for billing purposes who's using which services when API rates, requests, formats, etc.


Ian:And by doing that, we can then target customers that might be using these services that are about to be or need to be deprecated in the future.


Ian:And we can let that targeted group of customers know that they need to come off that particular signature version, because it's not longer going to be supported in the future.


Ian:And sometimes you'll get email from AWS saying, we've noticed you're using X or Y, can you please make this change, or we've noticed you're using this or that particular Amazon machine image, or a version of RDS, and you might get a security bulletin from us asking you to take some action to prevent yourself from becoming vulnerable for something. Yeah.

Richard:Lovely. And I got smacked by the fact... for the benefits of the listeners out there, you've spoken with no notes.

Richard:Yes. Absolutely no notes.

Matt:So have all of that in your head is ...

Richard:And we didn't prime any of this either. We didn't give you a briefing or anything.


Ian:No. No. This is truly live. Remember I just came off the back of talking about Lambda at the AWS summit this week.


Ian:So it's definitely fresh in my mind. It is a very popular topic with customers.


Ian:So ... yeah. Yeah.

Matt:The power though that in all that an ordinary developer today now has access to. It's just mind blowing for me. I mean some of those latest things you were just mentioning there, the speech related stuff, the translation, the multiple languages.


Matt:If I'd had that when I started 20 years ago, and as a business if you're a start up, you get so much of this for free.

Ian:Oh. There's never been a better time to start a company that relies on technology.


Ian:I mean you can get started for free with things like the AWS free-tier and the AWS activate programme that we have for start ups. But also you can grow big and remain cost efficient. You know?


Ian:As you get larger, your cost per unit of consumption will actually go down. Things like S3 we have volume breaks there, so the bigger you get the less you pay per gigabyte stored. So your cost are better than linear.


Ian:And it's not that with old school, old guard technology. It's not that way.

Richard:Yeah. We had ... Our story is we launched the business our first two courses, I think, were hosted on a server, and we realised that to launch course number three, I'm exaggerating a little bit, but it would almost not be worth our while to put a third course on that server.

Ian:Because you have a big lump-

Richard:The cost would grow exponentially. It would.

Ian:... per cap X that you need. You've got t0 buy that next machine.



Richard:And that's what forced us actually to go to S3 for the first time. So we're relatively early adopters, and it was a joy to do it. It was so easy. It took us a while to go over to EC2, but the move to S3 was a ...


Richard:A no brainer.

Ian:You probably look back on in now and think why would you ever do it any other way.


Ian:And then that's how I look at it. I just think if you're building apps today, there's really no better place to build them than in the cloud.

Richard:Yeah. Yeah.

Ian:It just doesn't make sense to me to waste your time. Not so much waste your time as you can prioritise other activities that are much more valuable, much more important if you don't do that heavy lifting. If you avoid those maintenance activities that you don't have to do if you're running Lambda.


Ian:You can spend the time you would have spent checking whether those operating systems are secure ...


Ian:On building new features that customers find valuable. So why wouldn't you do that instead of that? That just seems to be no other way for me.

Richard:Are there some areas, like my background was originally in defence but I've been out of that business now for about 15 years. So I have no idea how ... I guess it's all secret anyway, but there must be some businesses who would never consider going to the cloud and absolutely have to have their VMS deck servers there on premises.

Ian:I think there are. I think with any application that already exists, there's a constant assessment, isn't there of risk and benefit, or cost and benefit maybe, or whether or not it's worthwhile to re-platform an application.


Ian:There are some industries, some parts of government too that have specific regulatory obligations they need to act in accordance with; and actually this is one of the reasons that the AWS announced a region here in the UK. Which we launched in December last year. So we have a region now here in London with two availability zones at the moment. Our customers can run their applications locally in the UK but take advantage of all of these services or a vast, vast majority of these services we've been talking about from AWS in London. And that's really helped us with public sector customers here in the UK. Particularly in health, but also in other areas.


Ian:And if you were at the AWS summit this week, you might have seen Dave Perry. He's the CTO from the Driver and Vehicle Licencing Agency, the DVLA, on stage.

Richard:I noticed it, we didn't see it.

Ian:It was actually talking about how having an AWS region in the UK has made things easier and better for the DVLA's politically-

Richard:And I was surprised to see DVLA there. That was a, wow, that's the surprise.

Ian:Well we featured their sister organisation. DVSA, which is the driver and vehicle standards agency in the keynote last year.

Richard:Okay. Right.

Ian:The AWS summit.


Ian:Those are the people that run the driving test process for example.


Ian:Whereas DVLA is all about driving licences and all about vehicle records. And what Dave Perry was saying in his keynote, I'm paraphrasing him, he was saying really politically simpler because obviously less political concern about the UK government running its applications in the UK, then there might be about them running them in other parts of Europe. Such as Ireland for example. Marginal performance gains. Which are important, and then lastly, data sovereignty and data residency.


Ian:The data is on UK soil. So and it just makes it simpler for people in government that want to drive technology change to engage with stakeholders and convince their stakeholders that the benefits outweigh the potential cost and risks.

Matt:But I noticed in the market place isn’t the right phrase, but where you have your exhibition with lots of vendors there, actually certainly helping companies manage security of their cloud platforms and also general control of what could be a spiralling set of services and costs, and helping companies is also a massive growing market for that. Which I think must reflect that more and more of the larger companies ... I mean my background is banking.


Matt:I worked in IT in banking back a few years now. When I left, though, a few years ago I could never have imagined banks moving their infrastructures into the cloud. And yet, I guess, every bank these days has an app, and the app backends must be all cloud based.

Ian:Well it's quite a few banks that run a lot more than just their apps in the cloud. They're running core systems now in the cloud that you would have probably probably have considered a few years age immovable.


Ian:You probably think they'll never move that out of their own data centres, but actually quite a few of them do and quite a few of them are. And, yeah, I think the rise of these, the really complimentary tools that help customers get more value out of AWS, or accelerate adoption, I think in part some of the rise of technology providers of that type has been in response to the natural complexities that's grown up within enterprise IT over time. You know, you probably ... Nobody would set out at day one to build a complex system because anybody knows that complexity is difficult to build, but it's good and very effective at evolving.

Matt:Yeah. Yes.

Ian:Over time and what you look at if you've got 10, 15, 20, even 50 years of IT, is you've got 10, 15, 20, 50 years if evolved complexity in the IT.


Ian:And moving that in order to take advantage of this new technology delivery model, it's challenging.


Ian:And it can be eased through the injection of some of these tools that you've talked about, but also through the injection of skills from the other kinds of partners that were present at the event this week. Which are AWS consulting partners.


Ian:Who will bring in methodologies, experience, capability to help customers move existing application portfolios to AWS, and we see partners there. Claranet were sponsor on Wednesday, but also large multi-national systems integrators and professional services companies. Like Accenture, and CSC, and others are also operating in this space. Helping customers realise the potential, the benefits of the cloud without having to go through a large ramp up of hiring and training before they can start to deliver some of those benefits. That's where these providers really add a lot of value I think.

Matt:Lovely, well I'm not sure how we're doing on time,.

Richard:It's absolutely bang on time by look at it.

Matt:So it's been a fascinating conversation. Thank you again for coming in.

Ian:No problem. Thanks for the invite. Appreciate it.

Matt:And for allowing us to come actually to the summit day. If anyone gets a chance, hasn't been to one of these, and gets a chance to go, I'd absolutely recommend it. So ...


Matt:Interesting experience and a great opportunity just to find out about organisations that are benefiting in ways that you'd never think about. Which will inspire you to think about opportunities to improve your own business really.

Ian:Yeah. You can see the rest of the programme by the way at If you go there, you'll see what we've got left to run this year and you can register of course the free events. So we're in various locations around the world.

Matt:Free events. That's what we like to hear. Thank you again, Ian.

Richard:Yeah. Ian, thank you.

Matt:It's been great.

Richard:Thank you.

Matt:And if you've been listening to us, thank you for listening, and hopefully see you at the next one. I'll see you next time.

Listen via:

Be notified of new posts