Top tips for developing and deploying on AWS

I think we've making it to the end of the day. It's been a long day already, but a lot of fun. Hopefully those of you using Amazon will enjoy this talk. So a little bit about myself. So my background is on computational chemistry and cheminformatics, which probably doesn't resonate with any of you. Nor should it. It's a very specialist, but it's a lot of fun using chemistry to help design new drugs is the is the main part. I've been using Django for nearly five years now, which is slightly scary. Um but I picked up a few tips along the way and most recently how to apply them on Amazon. So you've heard about my employer OpenEye, but you probably have no idea what we do. We do molecular modelling and cheminformatics, just more of the jargon worse, keep throwing at you. But two interesting or important things are

is after attending a talk from Russell at the previous DjangoCon. OpenEye is now a Django Software Foundation corporate member. We're very proud to sponsor the Django Foundation. And in keeping, we also are a technology partner with Amazon. So, what does this open eye thing do? So here's uh one of our pieces of software. It's a 3D visualizer. That pretty picture in the middle shows you a protein and a drug and how they bind together. I'm not going to go into how we do all that, but that's sort of the science that we we look at doing open eye. So this is more the molecular modelling. And then we can use Camphematics to take that information which is notionally 3D and we project it onto 2D images. So the image on the lower right is how we show a protein binding site in a flat way

with a key and a legend and then the drug. If you want to talk about the science, grab me afterwards at the at the receptions or anytime during the conference, I happily go through that with you. Um, but I'm gonna stick more to the IT for the for the rest of the talk. Uh my previous employee before OpenEye was a pharmaceutical company known as AstraZeneca. Some of you may take some of the medications. If you ever doubt Django is used at enterprise, don't worry. AstraZeneca have revenues of over $20 billion a year and they use Django. First time of their discovery projects. So you can rest assured it's been using for really good stuff. So on the left you can see some of the chemists at work. This is from AstraZeneca's own library of images. It's not entirely true if you go and meet a real-life chemist. But it's not far off. And although this talk is about the cloud, more traditional enterprises prefer their own hardware.

So the big box on the right is an IBM Blaze Center. And that's one of the pieces of hardware we actually deployed Django on when I was at AstraZeneca. So who here is a user or knows about AWS? So yeah, pretty much at least half of you have used it, I'd say. So it's something that keeps coming up time and time again. Cloud's one of those big buzzwords, can't avoid it. So OpenAI, we've really embraced Amazon. Um and one of the reasons is it's crazy, crazy size. So this was um a quote from a year ago from the head of AWS. It's probably still true, to be honest. That the amount of capacity they have is five times more than all 14 major competitors, which we think about as just a huge amount of resource. And when you look at what

Amazon has been doing for the last six years, I've a pinch on their corporate slides, but you can see this is the number of features released every year. And as the years go along, the numbers go up and up. And the last column is this year. So we're not even halfway through the year and already they've almost matched the number of releases for last year. So how do you keep up with 280 release updates a year? That is a lot of changes to their services. And a lot of each of the bold services is a brand new product. So they introduced seven new products last year. It's a very rapid pace. So I'm going to just highlight some of the most useful products from their range. Some of them you may have heard of, some of them you won't. Apologies if that's all something you already know. But thinking specifically about making a website, first thing is how'd you get there?

You need a DNS entry. You need a someone to register your domain name Uh Route 53 is their service for this. Um traditionally just DNS, but since of last month, you can now register your domains with Amazon as well. Technically it's not Amazon doing it. They've got a contract with another company. But this way you can have your DNS and registry in one place so you can see when it expires you don't lose your domain, which would be quite embarrassing, I feel. Um and that DNS is incredibly handy because you control it through the API, which when you're deploying new software, it's really handy to change things over programmatically. Already you've heard about uh Redis and Memcache in other talks of the useful tools for deploying your website. One click of Amazon, you can have a Redis server. Another click, a memcache server. They're maybe not that hard to install, but you don't have to maintain another server in addition to your web servers

and your application servers and your databases. Alash to cache is the Amazon product that gives you easy access to these very popular technologies. Maybe you fancy a bit of NoSQL. Amazon offers a service called DynamoDB. So this isn't NoSQL in the same way like MongoDB. It's slightly different, but it's very powerful and incredibly fast. And if you want to use it at Python, you definitely want to check out one of my coworkers' libraries, which is PynamoDB, for a really easy way to access it, both in Python and using Django. Uh databases, talk of the day, Django 17 is now out. Those migrations are ready to roll, but you'll need a database to throw them at. So uh why I'm sure the four database servers there you all have your own personal preferences, I'm pretty sure no one wants to actually install a database service.

No matter which one you pick, they're not easy. Um all of these again, one click, running. So maybe you prefer to develop on MySQL, but your uh your client has to run Oracle. Maybe don't have the licenses. Amazon gives you a really nice way just to go and fire up an Oracle database, test it, when you're done with it, close it down. Nice and easy. So I'm gonna take a quick tangent away from the services after talking to people at lunch about um TLS. So you want to be having your communications securely between the different services you use within Amazon. RDS Uh just comes as default actually now. Same I remember doing a few weeks ago. Uh once you fired up your Postgres database, let's say, everything can be done through SSL, TLS communications.

You just need to make a small change to your settings. py under the options section to tell it to do a full verification of the SSL certificate on the path. and provide a location to the certificate that Amazon provide. This is the the public key that you can easily download. You can then also use TLS on ELBs, their load balancers. It comes as part of CloudFront, as S3, and on every endpoint. So it's really easy to ensure you're sending corrected communications without having to go up your way. So perhaps the most well-known service Amazon has is S3, the simple storage service, where storage really is unlimited. It's quite crazy. how much uh capacity they add on a daily basis to S3. It also has 119s of durability. So once it's in there, it's pretty much staying.

This is a great place for your static assets. You've already heard from other talks today, people like to use S3 to throw in their the assets there. It works ever so well. And it works even better if you couple it with CloudFront Which essentially gives you your own CDN. So Netflix pay crazy amounts of money, I'm sure, and so do Yahoo and everyone else. But you can get your own CDN for a really very small amount. Uh you can use edge locations provided for you. So when your customers go to your website, they get the assets from the closest geographical location. And as I was alluded to, TLS is available by default. The first time we were testing TLS for our own website, we found the bar was not green, it was still yellow. It's like, well, why is it still yellow? It turns out the images weren't coming from an SSL source.

Which is why you don't get the green, you have to have everything from a TLS provider. So one change to cloud front and that's done. Uh email, the or SCS, the simple email service, as the name says. Uh Amazon can send out email for you, very easy. And it's even easier with the Django SCS module, online. Uh one line in your Python settings, well two lines, install the app, add one line in the settings, and voila, your emails from Django being sent through Amazon's email provider. And the last one is VPCs. Virtual private clouds. This is part of EC2, so EC2 being the compute component. Virtual Public Cloud lets you carve out part of Amazon's network to enable you to have much more fine-grained control, which is great.

It's also much more secure by default. There's no public-facing IPs standard. However, it is famously complicated. I recommend you read the docs, uh, you read the white papers, read them again and again, and then you might understand what's going on. Uh the part of the reason it's so complicated is because it can integrate with your on-premise computers. So we have a VPN connection from our OpenI offices directly into Amazon. This is really handy, but it's not easy to set up. So you might need to find your network administrator to keep your hand with that. But once it's up and running, it's so so much better. Um and it's something that enterprise really, really likes. They like carrying their data, their machines, things carved away in a safe, secure place. So that's just a highlight of some of the services.

Um, but how do you get access to them? I'm sure you've all heard of Boto. Um Boto itself had a big announcement. Uh I think a few weeks ago that they've now moved on to Python 3 support, which is great. That was one of the sort of the top ten blockers of um biggest Python packages that didn't have Python 3 support. Um it also supports EC2 roles, which I'll cover in a few slides. The other thing Amazon was released, I think late last year, was the AWS CLI. So it's just a command line interface to access Amazon, which is great when you don't need an API. What you may not realize is it's also written in Python So once again, Python is being key to Amazon's um deliverables and two easy pip install commands and hey presto, uh you've got it. So if we think about a Django website, we need a database, we need some application servers, uh

load balance, uh, cloud front, all sorts of things. So it might look something like this. These are all little pieces which I borrowed from Amazon to put together a well-performing website that's scalable through scaling groups, has low balances, a failure of a database. So how long do you think that takes to set up? If you had to install all these pieces by hand. So a lot of work, a lot of effort. They just maintain all of it. Amazon have some quick, easy ways to set up this whole stack for you, as they call it. But it's a lot of work. So maybe you're more developer inclined than you are DevOps inclined. In which case, there is another product from our zone called Elastic Beanstalk, which might be very handy for you.

So this is sort of comparable to Heroku. If any of you have used that, it's much more about taking an app and deploying it And you can do it in literally three easy steps. So, step one: go to the page, press launch. It's not too hard. Wait for five minutes, and this page will load up, show you a running Uh instance, so you get a a temporary sort of URI. So the one in the top right is a little bit small. Um this has created a database for you. An EC2 instance for you, it's put in a scaling group, it's putting a load balancer, and you've not asked for any of these things, it's done all of it for you. And you can click through and you'll see a nice sample project they've given you. And if you want to put your own Django application on there, it is as easy as just clicking in the middle where you have running version, upload and deploy, upload your own files, and away it goes.

It redeploys and it throws your code out. And there's a small extension you can add like a git push as well to it. So when you push on your code, it sends a copy to Amazon, they put it in S3, surprise, suppress, and then upload it and redeploy. So we looked at this. It's very handy for small applications. Um but it's only sort of one particular way of doing it. You have to have RDFs, you have to have this and that. There's no way to do Redis easily and things like that. So if you need the rest of Amazon services and you probably need to use CloudFormation, well you have to write a JSON template to say I want an EC2 instance, I want a database of Oracle, I want Elasticash, I want this, all these things. Um but how many of you write JSON by hand? It's not much fun. I had a quick look. We have one of them which is 2,000 lines long.

I'm so glad we did not have to write this. There's another Python package called Troposphere, which lets you write Python and it will output the JSON for you. Which is hugely, hugely preferable, um since it is just so awful. So and one of the reasons you want to do this, because here is another architecture that Amazon talk about. This uses A few other services such as Hadoop and DynamoDB, this one's for sort of online gaming. And CloudForMotion can be used to very easily fire up all these different pieces. In minutes, opposed to you having to say install one machine, install the software, fire up another machine, install the software again. It makes it really powerful. And if you got it wrong, it doesn't matter, just destroy it and start again. So I'm going to shift gears a little bit to security.

So Amazon have a shared model. So they will look after everything sort of under the hardware, make sure it's secure, attackers can't get in, everything's patched But once you're out on the machine, specifically EC2, you know it's your responsibility. If you open every port on the firewall and wonder why you're being attacked. you know tough, you know, it's your fault. You've got to be careful and make um conscious and correct decisions. Likewise they have another product which is called IAM, which is identity and access management And there's an excellent uh slideshow they gave uh last year at their conference that covers the top ten things you should really do with IAM. I'm going to run through them very quickly. A lot of them you're gonna think, this is so obvious. Because it really is that easy and it makes your life much easier as well. Uh we didn't do them all at first, but um

I soon came around and have activated all ten of these much easier to use hints. So the first one is just making users. So if you used Amazon, you know you get an API key, a key, a user ID, and a key essentially. But you can have more than one per account. By account I mean something with a credit card attached to it. So OpenI, we have one account, one credit card, but like 30 users. Everyone has their own credentials. Everyone can see different permissions and they don't overlap. So that makes it far easier than having 30 bills appear at the end of the month. Everyone belongs to a group. This way, once you've got your permissions right, you can make sure everyone gets them and everyone has the same one. We had a few cases where users had sort of custom permissions. All of a sudden they could or couldn't do things and it wasn't clear why they couldn't do this.

So just get rid of those, get everything into a group. Amazon follow the uh least privilege rule in terms of security. So if you don't need access to it, you don't get it. A lot of their templates are quite restrictive as well in terms of security and that really does um work far better. No one's ever coming to me and said, oh Craig, you've given me too much permission. Please can you revoke it? I mean it's always the other way around. I'm not sure they ask for extra access. Then I give it by accident and they inadvertently delete every web server we have running because I'm not going to be happy, and nor will they. So you do get passwords as well, and you can set a really strong password policy, you know, symbols, length, things like that. But you don't actually need a password for the API. The password is purely for the management console. So if your users aren't allowed on the console, then don't give them a password.

You know, the best security policy is where there is nothing to break. Uh MFA multi-factor authentication, uh spinning around the news, you know. of ways of even MFAs get can be broken around. Um but you would definitely want to try and use uh an MFA. So the root account is the count that you get when you first create Amazon. An account with AWS as one of the credit card on. That has to have an MFA, a real MFA. That's the best policy that you can possibly think of. And then after that, power users, those that can do a lot with your account. So for example, myself. I can do anything more or less in my account. So I have an MFA as well, but I choose my phone. So it's much easier than having a physical token. And if other users we decide or deem them as being power users, we make sure they have MFAs as well.

Roles is something which attaches to EC2. So once your code starts to run, you know, using Boto or Django, you need your credentials to do anything. So all of a sudden you put Amazon credentials into your code on GitHub, plain text. This does not sound good. Um not to mention you need to change it software in any way, so how would you go about doing that? But a role is basically injects a credential onto the instance locally, so you never need to actually type any passwords in. When you boot up the instance, you sell it has a role. That role has certain permissions. It can then access S3 or do whatever it needs to do. And Amazon automatically rotate them three times a day. So this is really, a really good way to ensure your keys aren't public and they get changed all the time. Sharing is a great technique to share credentials between accounts.

So if you have two accounts, let's say the business group and your marketing group, and you just want to share access to S3 with the developers to marketing, you can do so using roles as well. And rotating keys is really important. So with the roles is automatic. But with users, whatever policy you have for like changing passwords, you should also do with API keys. So if every so often you should go through and reassign your users new API access keys, you can have multiple ones at once, so there's like a nice seamless transition. You can add conditions to your provisions as well. So for really sensitive things like you know terminate EC2 instances, you might want to say you can only do that if your username is Craig and you have an MFA. and you're using a secure TLS API point and your particular IP address, for example your office IP.

So you can do quite granular restrictions as well. And the root account, the one you get the first one you get, the general rule is just don't use it. It's too dangerous. So by default, Amazon now don't give you API keys with it. They've taken them away. It's such a security risk. You can look in the news, people have had their root credentials hacked, and all of a sudden they held up for ransom. Because you can do anything for those credentials. You can delete the data, you can terminate the instances. It's just too bad. Just Don't have them, then you can't lose them. Um definitely have the physical and uh MFA as well. So AWS support is a as a paid extra, uh, something that gives you email within 24 hours, um, although I find it's normally a lot less. And you can access the telephone and chat, which is pretty much instant.

It's been really useful for us. Amazon released a lot of new features, and very often they update the API and the website. But as I've talked about using cloud formation, they don't add cloud formation always straight on to a new feature. So an example is the ELBs have a timeout which you can now configure, but only manually. So I wrote in as an email and said, you know, this is super, but we really need it as client formation as a feature request. And Amazon are really customer driven, so you do have to be very proactive and you're saying, you know, this is important to us. And they do get around to slowly changing it. If you are serious about using Amazon, I'd recommend joining the partner network as well. It costs two thousand dollars a year, but they give you two thousand dollars credit. So it works out uh you know uh an easy easy win.

You get access to some training and things like that too. And if you're really serious, um get an account manager. They've been hiring like crazy, um get an NDA signed, and then they'll tell you things down the roadmap as well, as well as giving access to private betas. So some of the products you see today we had access to early Which is really good. Test them out, get feedback. Um and finding about roadmap features is very handy. Because it can go wrong where, you know, you might make a larger order of new network hardware and then find out the next day that that feature is now part of Amazon And your life always hard weighed down to deal with. So it's uh good to be in the know. So as I said, um keeping up is a tough part, but there's quite a few ways that I found that seems to be relatively successful. So there's the main Amazon blog that we're following. They have a few other blogs as well, which are like specific on topics like security, Java, big data.

There's a mailing list. Once you've joined, they'll soon find you. So they'll start mailing you anyway. Uh their Twitter account is very useful. And like the blog, there's some sub-accounts for IMA for their top tips. They do summits around the world, like one-day conferences in Tokyo, Singapore , London, San Francisco, places like that. And then reInvent is the annual customer conference. So that's also worth going at for three-day much like DjangoCons, a lot of information thrown at you. So when was the last new feature to Amazon? Well, this morning obviously. So I checked on Twitter this morning. Jeff Barr, their senior evangelist, um has blogged about and shared a quick tweet about a slight change to the interface. Support EC2 and how you can filter your instances. So it's only a small incremental change, but one day you might come in and find the future you've been waiting for for months

is now there. So uh just to conclude, um Amazon is really easy to prototype with. The services maybe they're not exactly for you, maybe you want Postgres in a slightly different flavor than they offer. But just to get going with it, it's so easy just to fire it up and use it. And then when you're ready to roll your own, if that's suitable, you know, for our PC2 and whatever you like. Get your IAM settings right from day one. It's really easy. There's top ten tips you can do in an afternoon, and you will be grateful. Um things do change, so what 280 changes last year? We're already well on the way to taking that over already this year. So you're gonna have to keep up. And just as they release new features, there's also price drops. So there's been over 45 price drops so far. So you'll get new features and your bill overall

is always going down. So it really is uh worthwhile. Um and if you're new to Amazon, there's a free tier, which is which lasts for a year, um includes lots of storage and all sorts of things, so it's worth trying that too. So just before I finish up, I'm going to do a shameless tag for another OpenEye presentation tomorrow. One of my co-workers is talking about OAuth 2, something we found very important for us at OpenEye. Again, I thank you for our attention at the end of the day. If you've got any questions, feel free to pin me on Twitter. If I'll be happy to take them there.