Python x AWS x Serverless Techniques for Beginners to Take the Next Step
I have been on the stage with the title. It's been a long time since I was on the stage outside the company and I was very nervous.
I managed to change the route from what I originally thought about, why people use the deadline so much, and so on, but I still say it when I think back on the composition and individual topics. I thought there was something missing, so I'll supplement it here.
The slides are available on SpeakerDeck.
It's a slide that introduces Tips in terms of content, so I felt that I might not be able to answer the question "Can I get out of the beginners with this?"
Of course, there is no intention of title fraud. I have a background (for the time being) in choosing this title and content, so I will write it down.
In my background, it is a skill set that I have some knowledge about AWS, but I do not have a solid experience in application development. Against this background, I was confused about the basic directory structure and how to design it because I wasn't used to it. Then, because I didn't understand, I was worried that there was something unique to serverless, and I didn't know what to do (although I wasn't aware of it, so I couldn't solve it). ..
After that, I realized that the idea of the application development part, even if it is serverless (as I said in this announcement), should follow the language practice normally. I hope that everyone who is going to be serverless will be informed that they will not be afraid more than necessary.
I myself used to experience a state of "I'm sick of not knowing what to do next" about serverless. We have announced that the information we wanted to know at that time was the material for this time.
This kind of introductory sharing is a very important part, isn't it? Because there is no appealing power in a presentation that does not raise a story or why that you can sympathize with. I regret that omitting this may have made it difficult to understand the message that appeals to the viewers.
This is the part that I missed the explanation in the section such as "Stage".
The Serverless Framework nicely names the AWS resources you deploy to avoid conflicts between stages. Therefore, the Name attribute is often not required if you are using the Serverless Framework.
However, I would like to say here that "Isn't it better to explicitly name the resource?" Actually, it appears a little on the slide, but the naming convention is like this ↓
# template.yml
# SQS Queue name
Name: ${self:service}-my-queue-${self:provider.stage}
With this kind of naming, it is possible to manage resource names that are easy to predict and do not have names between services / stages.
As a dissenting opinion, there is also the idea that "since all infrastructure is managed by code, do we have to worry about the name for humans to see?" If anything, I would like to support that.
You don't have to worry about resource name conflicts and character limits (eg lambda function names can be up to 64 characters), so it's easier not to name them strangely yourself. Naming convention management is also noisy as the description of the source (on the stack) increases. If possible, I'd be happy to leave the name to you.
So why should we give it an explicit name? There are two points that I personally like, each of which is as follows. I think that the situation of the project I am in charge of is biased. maybe.
Since I use Step Functions a lot, there are occasional scenes where I want to search logs across multiple Lambdas.
At the moment, CloudWatch Logs Insights is used for log search in most cases, but the name of the log group at that time is refreshing (if you have an explicit naming convention), so the search is a little easier. is.
Probably, I think that there are various ways to do log search by tag while using Datadog (without relying on naming convention), but this method is one of the choices I can make now. I think that it is a reasonable method because it is suitable for the operation scene.
I think that it is more advantageous to have a naming convention in order to write both the stack description and the application side description clearly to some extent (this is the merit I want to assert more).
If it is a simple configuration diagram, you can subtract the value with GetAtt or Ref of CloudFormation, so it is not a big problem. Naming conventions are useful when the block diagram is bloated.
For example, imagine a configuration with multiple SQS queues. In Python code, you need a queue endpoint, the Queue URL (identifiable by AccountId, Region, and QueueName).
You can refer to the URL of the created queue with Ref and pass it to the lambda environment variable, but personally I think it is enough to pass the account ID, region, and name attribute of the queue respectively. ..
Account IDs and regions are likely to come into play when using other AWS services. It doesn't seem to be a problem, and it's very easy to implement a utility function that builds a Queue URL, so I think it's best to choose the one that seems to work.
The management of Python as a code base is as described above, and now let's consider the management on the stack side (I think that the merit of the naming convention is rather large here).
I'll repost the definition of the SQS queue name earlier. The name of the queue was an image created by joining service and stage.
#[Repost] template.yml
# SQS Queue name
Name: ${self:service}-my-queue-${self:provider.stage}
The actual stack definition is like declaring the entire string of Name above (or the my-queue part) in the environment variable or custom section of the template.
This way you can write references from resources elsewhere (eg IAM policy definitions) relatively quickly. Since the name part declares that it can be referenced as a variable, ARN etc. are simply joined and assembled.
I think there is a point here that "No, there are Ref and GetAtt", but I personally don't recommend using them as a detour.
I feel that abusing these, especially around policies, can lead to cloudFormation circular references. This is a rule of thumb and I can't justify it in a clear sentence, but I don't want to use a function that directly references AWS resources. Instead, we're taking a strategy of relying on less harmful environment variables or variables in the custom section. Consciously ref, GetAtt (especially around IAM policies) is discreet.
Debugging CloudFormation is a pain, but I don't like it because I'm having trouble with circular reference problems in CloudFormation after the configuration grows ...? That's not something that human beings debug. ..
For this reason, I prefer to explicitly declare resource names (even if they are a bit verbose and annoying). What I wrote in this section is just a side effect, but I take it quite seriously.
For serverless material, if it is enough information to cover the outline materials and tutorials, it is rather sloppy, but in the end, I feel that it does not eliminate the itchy part in the actual development scene. So I applied because I wanted to fill that gap.
I think I've talked about what I want to convey now, but since the basic knowledge around AWS was a part that I could dig deeper into, it might have been good to apply in a 45-minute session (Python component becomes thin). I think it's TPO-like because it's going to happen)
On the other hand, unfortunately, the reaction was less than I expected, so I couldn't really get a feel for the story itself from this announcement (the counterprogram session was too strong). There are several possible factors, such as the fact that my presentation itself had room for improvement, and that it was difficult for the main participants of PyCon to meet.) It is unlikely that there will be no demand, so I will try to find out by changing the place and talking. The base material is ready.
I think it would be nice if I could write a little more systematic knowledge that is closer to practice. It may be good to try your best in the next technical book.