AWS Community Day

Background

I attended the AWS Community day in SF on 6/15, and in exchange for the day off I took a bunch of notes and tried to summarize the experience for the dev team at work. Here's the email I sent out.

Hi all,

Last Thursday I attended the Amazon Web Services (AWS) Community Day event in SF, and thought y'all might like to hear some of what went on there.

Here's a brief overview of those talks:

And You Thought You Knew EC2

Background

EC2 is the AWS Cloud-based virtual server, and their flagship service. They can be provisioned in minutes, and can auto-scale to handle surges. There are a few types including IO focused, CPU focused, and GPU focused.

Talk Highlights

• They've added a couple new types, including a Field-Programmable Gate Array (FPGA) server, and elastic GPU servers.
• The Systems Manager is a neat tool that can help automate system administration/maintenance tasks. It also allows granular permissions so a user could have access to run commands on the server without requiring shell (SSH) access. It also includes a parameter store so secrets can be accessed from an encrypted store rather than being saved in plain text on the server.
• Combined with AWS Lambda ("serverless" code execution) and cloudwatch (server instance monitoring), very cool things can be done including provisioning and configuring servers automatically based on cloudwatch triggers, then returning the results in JSON so they can be easily parsed.

Overview

The level of control and flexibility available to AWS EC2 users is pretty amazing. It's easy to see how these tools have helped allow the startup scene to explode due to reduced labor costs and instantly scalable infrastructure. Auto-scaling, auto-healing web and database servers, sidestep a huge number of possible problems, constraints, and time-sinks. Add the latest management tools and even managing a massive farm is greatly simplified. I probably would have gotten more from this talk if I actually did know more about EC2, the items got pretty deep into the weeds at points, but from a system architecture POV I could see the value in a lot of it.

Introduction to the Amazon AI Series

Background

In recent years Amazon launched Machine Learning, which is simply common machine learning tools and compute power on demand. This year they've launched Lex, a lexigraphical parser, Polly, a text-to-speech service, and Rekignition, which can make precise identifications within graphical images.

Talk Highlights

• You can use any source (EC2 instance, API calls, Cloudwatch, etc) to trigger Lambda functions to activate the AI tools.
• Setting up Lex includes training it on several types of commands, questions, etc, and allowing it to 'learn' to recognize similar inputs.
• Polly can be programmed with SSML (XML-like) which has tags for the entire Linguistic International Phonetic Alphabet set. So you can tell it to whisper, shout, or emphasize a word. It has other tags that include common issues like speaking a number (such as 530 478 1137) as a human would read a phone number, rather than saying "Five Billion, three hundred and four Million, seven hundred eighty-one thousand, one hundred and thirty seven"
• Rekognition is super cool, I wish we had it when people kept posting dick pics to Sargeslist. Not my favorite thing to see at 7AM on a Monday. It can classify images as SFW, or NSFW, which woulda been perfect.
• Rekognition is also very good at recognizing people, even from different angles. It can also asses the mood of a person based on their expression.
• It's scary that anyone with a couple bucks can use rekognition.

Overview

The big companies have had this stuff (and been using it on us) for a long time now. It's nice/scary that it's all available as a service. I could see quite a few new startups popping up as a result of the democratization of AI, and powerful AI as a cheap, scalable service without the need to hire experts or manage infrastructure.

Lessons Learned After 1 Year of Lambda

Background

Amazon Lambda is very cool. Think of it as Functions as a Service Without provisioning a server, you can create functions (currently Python and Node.js are supported) that are available to be executed from a variety of sources (API, CLI, console, SDKs). They scale automatically to handle any load, and require little to no maintenance. People are starting to use this service to create micro-service based architectures for their applications.

Talk Highlights

= Cloudwatch logs are the best way to monitor Lambda functions. The nice thing about that is you can create triggers in cloudwatch to call other Lambda functons.

• Debugging should be done locally. Since there aren't step-through debuggers available, all you have are logs and output. The problem with this is that you have to kind of replicate the Lambda environment to do so. The speaker, Matt Billock's company 'Backand', had a service that was an attempt to help with this step.

Overview

Matt Billock seemed to be mostly promoting the service his company Backand provided to Lambda developers, so most of his examples involved issues they ran into while setting it up, not issues that most developers would face (IMO).

Open Source: What Works and What Doesn't

Background

• The speaker, Mike Barrett, has several very successful open-source projects, and had a lot of advice and observations to share about both starting and maintaining them. I was very excited to see this talk.

Talk Highlights

• Starting a project begins with several very important questions to answer: Why start, and what will make it "successful"? Are we willing to stay engaged to this forever if it does succeed? What problem does it solve, and is it a common problem? What's the scope? (directly relates to level of effort)
• Other key items include Documentation for getting started, contributing, code of conduct when contributing, and a license (check http://opensource.guide for COC advice and http://choosealicense.com for license help)
• A major boon to community acceptance is the availability of attractive, helpful usage documentation, and tutorials that guide the user through common tasks.
• Promotion is key. Twitter, HackerNews, Reddit, and Medium are all places where developers look for new tools and engage with the developers. Also good are joining/creating a Slack account for the product or related projects, and attending/hosting meetups, conferences, and talks.
• Support is key. Create a Slack chatroom and be involved in the conversations. Slack is the way nearly all new OS projects communicate with eachother and help users. Gitter is also good, but less common. Be kind and helpful, always. Encourage feedback. Make all support resources EASY TO FIND on the project website.
• Regarding contributions, maintain your focus and vision. So no gently to pull requests that get too far off track. Encourage discussion upfront to avoid embarrassing refusals like this.
• The first pull request may take a long time.
• Maintenance is key, and attracting a strong team of likeminded developers is instrumental for this. Nobody can do it all alone.
• Be publicly involved in other projects. This will attract people to you and your projects.

Overview

Be where you'll be seen, and always be available to help. Answering support requests and pull requests quickly is key for adoption and engagement. I noticed that he didn't mention Facebook or Linkedin at all, but it wasn't very surprising to me - I don't look for development/sysadmin ideas in either of those places, so I doubt anyone like me is either. He also mentioned that a lot of upvotes from the same IP address will get your post banned/devalued by a lot of services since it looks like astroturfing, so try to avoid that. I was surprised that Slack has become such a key part of community project, but it kinda makes sense - it's like IRC on steroids and makes sharing non-text items pretty simple, if that's important.

Happy Hour notes

People are excited by Lambda, but it seems like most of the folks I talked to are forcing projects to fit it because they're excited about it rather than choosing it because they had a clear need for it. Honestly, microservices appear to only be valid once you get to Netflix scale, but I could also see super small projects or one-off use cases for Lambda. The AWS community is very helpful, and unafraid to suggest other services if it makes sense. "Google's AI is better", one dude said, "but if all your data is already on Amazon, it will be a lot cheaper to use their stuff". A few offered advice on how best to use AWS without making your application dependent on it. Everyone was excited about the AI stuff, and mentioned that they'd be studying it in a lot more depth after the conference.

Hit me up if you want to know more about any of this stuff, I found it all pretty fascinating and spent a large part of the weekend learning more.