There are a great many reasons your application can benefit from moving to the cloud, but enough requirements for retraining, uncertainty around cost or complexity and just plain worry about what can go wrong to delay or prevent such a move. When my business moved to the cloud we learned that there are ways around many of these challenges, allowing you to move your application in a way which might not be best practice but which works and gives you a solid platform from which to advance and improve your cloud implementation. In this tutorial we'll look at key building blocks to put a LAMP application onto AWS, what might cause problems for your individual use cases and how to mitigate these. As well as basic plans to get you started we'll look at pathways to modify your application and train your team to take more advantage of cloud native features and adhere to infrastructure and security best practices in a way which allows you to keep running your team and your business.

Comments

Comments are closed.

Sorry, if i`m not wrong you were using `jq`, but AWS provides `--query` parameter you can use instead. F.e.:
```
ec2 describe-security-groups --query='SecurityGroups[*].GroupId' --output text
```

Great workshop overall!

Mike Lehan (Speaker) at 12:24 on 25 Feb 2019

@serhey

Thanks for the feedback. You're right I was using jq and you're also right that AWS has the --query parameter. I think the average developer may be more likely to know jq syntax than Jmespath, and also jq has nicer highlighting for the final result. However for more interesting queries I think Jmespath probably scales better and so it's worth a developer learning that too. Overall the example wanted to do something people would recognise but you're right that also exposing more native AWS functionality would be smart as well!

Piers Beckley at 13:14 on 25 Feb 2019

A very good talk, hobbled by the fact that a lack of bandwidth held everyone up from being able to follow along on their computers. I'm not sure what the best way of solving that problem would be, though - perhaps a torrent?

Mike Lehan (Speaker) at 13:31 on 25 Feb 2019

@Piers

Thanks for the comment and yes I agree, the wifi did let us down. The issue was not so much the speed of it but in fact was the number of simultaneous HTTP requests that Terraform attempts to make during even small builds. I didn't see that causing problems (or at least assumed they'd be quickly resolved as the requests went through) but it seemed the whole network jammed at that point.

I hope to have the chance to run this again and my consideration would probably be to provide everyone with shell into a remote machine from where they could set up AWS creds and run the tools - this would reduce to 1 SSH connection per laptop and also avoid mac/Linux differences.

Thanks again and do message me any time for tips or advice with either my AWS example repos or the system in general!