Merge pull request #359 from kristiperreault/main

2023.md

@@ -140,8 +140,8 @@ Or contact us via Twitter, my handle is [@MichaelCade1](https://twitter.com/Mich
 - [✔️] 👩🏿‍💻 71 > [Serverless Compute](2023/day71.md)
 - [✔️] 👩🏿‍💻 72 > [Serverless Storage](2023/day72.md)
 - [✔️] 👩🏿‍💻 73 > [Serverless APIs](2023/day73.md)
-- [] 👩🏿‍💻 74 > [](2023/day74.md)
-- [] 👩🏿‍💻 75 > [](2023/day75.md)
+- [✔️] 👩🏿‍💻 74 > [Serverless Orchestration](2023/day74.md)
+- [✔️] 👩🏿‍💻 75 > [Serverless & Well Architected](2023/day75.md)
 - [] 👩🏿‍💻 76 > [](2023/day76.md)
 
 ### Service Mesh

2023/day71.md

@@ -1,3 +1,5 @@
+# Serverless Compute
+
 Compute is one of the basic building blocks of building any application. What is your application aiming to accomplish? Where are you keeping your business logic? What are you _running_ and **how**?
 
 ![Woman at computer. Image via Unsplash.](images/day71-1.jpg)

2023/day72.md

@@ -1,3 +1,5 @@
+# Serverless Storage
+
 [Lambda functions](https://aws.amazon.com/lambda/) and [Fargate](https://aws.amazon.com/fargate/) serve a great purpose and might accomplish what you need for a very small, [hello world-type project](https://aws.amazon.com/getting-started/hands-on/run-serverless-code/), but chances are you want to do a bit more with your serverless applications. Maybe you have a subscription-based product and you have user profiles with data. Or maybe your application is an e-commerce site and you need to store sensitive information, like credit card details. Or maybe you're just trying to save some images or files. Whatever the reason, you clearly need a storage solution, and this is where our serverless storage options come in.
 
 ![Storage Solutions for every need! Image via Unsplash.](images/day72-1.jpg)

2023/day73.md

@@ -1,3 +1,5 @@
+# Serverless APIs
+
 If you're new to the application development world, [API stands for Application Programming Interface](https://aws.amazon.com/what-is/api/), an interface that offers a 'service' of sorts for applications to consume. [Google Maps](https://www.google.com/maps), for instance, has a [public API](https://developers.google.com/maps) that you or I could use if we're building an application to locate all of the restaurants in our town. They surface this, and many, many other data points via documented endpoints, and we can use things like [API keys](https://cloud.google.com/endpoints/docs/openapi/when-why-api-key) to access this data. If you're a developer, chances are you will build an API at some point in your career, if not several, and you will definitely work with them. As a key building block in application development, [AWS provides a few API solutions](https://aws.amazon.com/serverless/).
 
 ![Open laptop with code. Image via Unsplash.](images/day73-1.jpg)

2023/day74.md

@@ -0,0 +1,41 @@
+# Serverless Orchestration
+
+![Conductor. Image via Unsplash.](images/day74-1.jpg)
+
+Are you still with me? I hope so, because I'm excited to discuss some of the really cool services in serverless that go beyond the basics of APIs, storage, and compute. This is the space where you can really see the benefits of serverless shine, and, compared to on-premises or other cloud development spaces, where there has been a lot of innovation that may not compare 1:1 to what you're used to in application development. I've included these services under the broad umbrella of 'orchestration', because they really exist in-between the core services and help with your event-driven flow. You may not have a need for all, or even any, of these services in all of your applications, but they can be useful technologies to take advantage of, especially if your application is truly configured for [event driven architecture](https://aws.amazon.com/event-driven-architecture/).
+
+**AWS Step Functions**
+
+![A person walking up steps. Image via Unsplash.](images/day74-2.jpg)
+
+Is it weird to have a favorite serverless service? Because this one might be mine. [AWS Step Functions](https://aws.amazon.com/step-functions/) is a workflow orchestration tool that helps you manage your distributed application by breaking it down into multiple steps (the name should make sense now). Step Functions integrated with over 220 AWS services, but personally I have found it most useful with my [lambda functions](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), as it helps keep them small, concise, logical units of business code that are called systematically. It's easier to control and monitor your event as it flows through your application, so you can track which step your application is or identify where you may be running into issues. Step Functions also gives you more flexibility, as you can add in different '[states](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-states.html)' like PASS or WAIT, and you can even run processes in parallel, or give your application Choices to execute on different steps depending on what the input or parameters are.
+
+![Step Functions Workflow in Studio. Example via AWS Documentation.](images/day74-3.jpg)
+
+As with most of the AWS resources, you can provision and configure your step function however you choose. For me, this is typically using an [Infrastructure as Code](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) tool like [CDK](https://aws.amazon.com/cdk/) to provision in python or typescript, and then defining the actual steps - otherwise known as the '[state machine](https://docs.aws.amazon.com/step-functions/latest/dg/amazon-states-language-state-machine-structure.html)' - in a JSON file. Since its release in 2016, Step Functions have had a visual component in the AWS Console that allows you to see the steps of your application and the flow of your event through it, but in 2021 AWS released [Workflow Studio](https://docs.aws.amazon.com/step-functions/latest/dg/workflow-studio.html), which actually allows you to drag and drop the components you want to use into a visual editor, and it will auto-generate the code for you. Unfortunately working in a large enterprise this isn't something I can really take advantage of, but as a visual learner I think this is an awesome tool, and can definitely streamline your development.
+
+**Amazon EventBridge**
+
+![Large bridge. Image via Unsplash](images/day74-4.jpg)
+
+[EventBridge](https://aws.amazon.com/eventbridge/) has seemed to be a hot topic as of late, and I'm seeing more and more content depicting EventBridge resources. Somewhat similarly to Step Functions, Amazon EventBridge is a serverless orchestration service for your application events. Its three key components are an Event Bus, to handle interactions with your events, like sending/receiving and transforming, a [Scheduler](https://aws.amazon.com/eventbridge/scheduler/), to help you schedule tasks associated with your events, and finally [Pipes](https://aws.amazon.com/eventbridge/pipes/), which integrate directly with your serverless services "end-to-end" and optionally filter or transform your event as needed. EventBridge Pipes were only recently released at the end of 2022, but the seamless integration with your event producers and consumers have been a huge selling point for developers (which explains the recent uptick in EventBridge usage).
+
+![Illustration of EventBridge Pipes. Example from AWS Documentation.](images/day74-5.jpg)
+
+Similar to other services, you can define and configure your EventBridge instance to your application needs, with the security constraints, service integrations, and appropriate event transforms you need. I won't say never, but it is particularly likely that you will not have EventBridge and Step Functions in the same application, or at least microservices, since their service offerings are quite similar. When might you use one over the other? As always, neither option is 'better' and this comes down to some personal preference and your application needs. If you have processes that need to run in parallel and maybe have more states dependent on each other, where you may want to wait or skips steps or have different workflows, Step Functions is probably a better choice. If you are looking to integrate directly between multiple different AWS services, and need to do quite a bit of transformation or filtering on your event, EventBridge may be a better starting place.
+
+**Amazon SQS**
+
+![Queue outside of a store. Image via Unsplash.](images/day74-6.jpg)
+
+[Amazon SQS](https://aws.amazon.com/sqs/) is also known as the Simple Queue Service. Much like people waiting in line for a busy ride at a theme park, sometimes you have places in your application where events may get backed up, creating a bit of a bottleneck and harming your application's performance (and potentially your wallet, too). A queue service such as SQS will help you process and maintain your events and messages as they come in. SQS specifically is what is known as a [First-In First-Out or FIFO queue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html), meaning the first item in is the first item to be processed, just like the first person in line for our ride is the first person to get on. Sometimes with high volumes of messages waiting to be processed, there is risk that they get lost or skipped over in processing (disgruntled individuals leaving the long wait at the theme park ride) - having SQS in place prevents this problem from happening. It also means you do not have to worry about your other services being up and ready to handle incoming events, as SQS manages and stores the messages for you (the fun, roped off queue handles the people waiting and the order in which they arrived at our theme park ride). Just like our other services you can configure SQS, however this is a fairly 'Simple' service, so you'll find creating and maintaining an SQS queue to be uncomplicated.
+
+**Amazon SNS**
+
+![Email notification. Image via Unsplash.](images/day74-7.jpg)
+
+[Amazon SNS](https://aws.amazon.com/sns/) or Simple Notification Service, is less of an orchestration service and more of a communication service. I am going to deem this a utility service, since it is a small service you can utilize for sending and receiving messages. One of the most common use cases for the SNS service is to send email alerts - maybe to developers to monitor application status, or maybe to users, to communicate new features or send email confirmations based on something like a booking reservation. You can also send as SMS text messages or mobile pushes, and you can [customize your queue type and add encryption](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html). Like SQS, this service is definitely 'Simple' and can be configured in just a few short lines of code, or button clicks in the AWS Console.
+
+Although not what I would consider 'core' cloud services, the orchestration and communication services are key to event driven development and robust application design. If you are structuring your application to take advantage of event flow, these are tools you are going to want to be familiar with, and will be instrumental in your success by saving you time, money, complexity, and management overhead. This about wraps up what I want to cover with [serverless cloud services](https://aws.amazon.com/serverless/), though there is so much out there to explore. Tune in tomorrow as we start to put all of this together with best practices.*
+
+*This is part of a series that will be covered here, but I also encourage you to follow along with the rest of the series on [Medium](https://kristiperreault.medium.com/serverless-orchestration-d012aa7cae38) or [Dev.to](https://dev.to/aws-heroes/serverless-orchestration-3879).

2023/day75.md

@@ -0,0 +1,50 @@
+# Serverless & Well Architected
+
+![Pillars. Image via Unsplash.](images/day75-1.jpg)
+
+Over the last few days, we've discussed a number of topics in the serverless space, covering [storage](https://dev.to/aws-heroes/serverless-storage-50i3), [APIs](https://dev.to/aws-heroes/serverless-apis-5bdp), [compute](https://dev.to/aws-heroes/serverless-compute-3bgo), and [everything in between](https://dev.to/aws-heroes/serverless-orchestration-3879). We've got all the components to build a fully functional, robust application in place, but before you run off and create The Next Big Thing, we have to cover one more crucial topic: [Well Architected](https://aws.amazon.com/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc&wa-guidance-whitepapers.sort-by=item.additionalFields.sortDate&wa-guidance-whitepapers.sort-order=desc). The Well Architected Framework is a set of guidelines or best practices that AWS introduced a few years ago. The six "pillars" of Well Architected are [Security](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html), [Cost](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html), [Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html), [Reliability](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html), [Performance Efficiency](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html), and [Sustainability](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html). These concepts are not new, but by defining them in this way, AWS has established a reference that is easy to use and understand when evaluating your applications for best practices. In fact, AWS has created a [Well Architected Tool & Review process](https://aws.amazon.com/well-architected-tool/) centered around the six pillars, asking you questions about your application to review yourself or with your team. Before you start building your application, I would highly recommend you go through a formal Well Architected Review. You don't need to answer every single question, in fact some might not be applicable, but going through this exercise gets you thinking about how you want to architect your application, even highlighting key decision trade-offs, or potential issues that you haven't thought of just yet. In the subsections that follow, we'll talk about each of the pillars in a little more detail, and I'll briefly cover [Well Architected Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses.html).
+
+**Security**
+
+![Lock keeping items secure. Image via Unsplash.](images/day75-2.jpg)
+
+Simply put, how are you securing your app? Are you using authorization and authentication with [IAM users, roles, and policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) to limit access to your resources? Setting up [permission boundaries](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) and using [KMS keys](https://aws.amazon.com/kms/) for encryption? This can look like any number of measures, but the important idea here is, are you thinking about how to secure your app? Some of the questions in this space may not be applicable. This could be an app just for you, or one that isn't storing any data to worry about, or it could be wide open to the public and have no personal information to worry about. You don't need to have every single security measure in place for your application, but you do need to think about these things, and make conscious, defendable decisions about your [application security](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html).
+
+**Cost**
+
+![Jar of money with a plant. Image via Unsplash.](images/day75-3.jpg)
+
+This one is pretty straightforward - I don't know anyone who gets excited when their cost or bills go up in price. Obviously, we all want to optimize for a low-cost application solution, whether this is for personal use, your business, or the company you work for (you may not care about that one personally, but I can tell you THEY certainly care about the bottom line). Look at the [pricing model](https://aws.amazon.com/pricing/?aws-products-pricing.sort-by=item.additionalFields.productNameLowercase&aws-products-pricing.sort-order=asc&awsf.Free%20Tier%20Type=*all&awsf.tech-category=*all) and see if there are any ways to cut costs. Some easy ones could be to minimize the number of API calls you're making, or utilize [Lambda Powertools](https://awslabs.github.io/aws-lambda-powertools-python/2.9.1/) to optimize your lambda function for memory & performance. If you've exhausted every option here, that's okay. Cost is typically a trade-off; you may be ok spending more money to make sure your application is secure, reliable, and not hindered in performance. Again, the idea here is that you're actively aware of where your money is going, and you've [reviewed your optimization options thoroughly](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html).
+
+**Operational Excellence**
+
+![Group working at laptop computers. Image via Unsplash.](images/day75-4.jpg)
+
+One of my favorite topics to talk about is '[Clean Code](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)', or better known as best practices within your code. Although this could cover many of these pillars, it arguably fits squarely within [Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html). This pillar is all about building robust applications, code that is easy to understand, read, and maintainable, and having effective development processes in place. Creating small, logical code blocks, making small & frequent code changes, [reviewing code](https://about.gitlab.com/topics/version-control/what-is-code-review/#:~:text=Code%20reviews%2C%20also%20known%20as,developers%20learn%20the%20source%20code.) periodically, having ample error handling, logging, and monitoring, and so much more fall into this category. For me, this one is sort of like a "catch all" pillar; not because it isn't well defined, but because it encompasses so many parts of the application development cycle. Many of the pillars overlap, but it is very likely that this one in particular will have overlap with one or more of the other pillars at any given time.
+
+**Reliability**
+
+![Chairs relying on each other. Image via Unsplash.](images/day75-5.jpg)
+
+Is your application stable? Do you [backup your data](https://aws.amazon.com/backup/) regularly? Do you have [failovers](https://docs.aws.amazon.com/whitepapers/latest/web-application-hosting-best-practices/failover-with-aws.html) or other fail-safe measures in place? Can your application handle a large influx of traffic, or will any changes to the 'average' case break your current functionality? The key question this pillar asks is - are you prepared? Outages are never fun, especially when they significantly impact your customers, but they can (and they do) happen to the best of us. By reviewing the questions in the reliability pillar, you are thinking about your application's [disaster recovery plans](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html), backing up your data, and having processes in place for the 'worst-case scenario'. Hopefully by completing a [reliability review](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html), these things don't occur as often, or aren't as widespread as they might've been before a review.
+
+**Performance Efficiency**
+
+![Performance on the track. Image via Unsplash.](images/day75-6.jpg)
+
+Closely related to the Operational Excellence and Reliability pillars, the [Performance Efficiency](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html) pillar is, you guessed it, all about how well your application is performing. What I enjoy most about this pillar is if you're taking advantage of serverless architectures, you're already well on your way to having this one covered, as it's one of the [five design principles](https://aws.amazon.com/blogs/apn/the-6-pillars-of-the-aws-well-architected-framework/) to adhere to. This is about your application running smoothly, scaling effectively, and taking advantage of only the resources you need. This is another big "trade-off" pillar, since you may compromise your performance in some cases to comply with security or save on cost.
+
+**Sustainability**
+
+![Person holding a plant. Image via Unsplash.](images/day75-7.jpg)
+
+[Sustainability](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html) is a recent addition to the Well Architected pillars, and I think it's a good one. It was [introduced at the end of 2021](https://aws.amazon.com/blogs/aws/sustainability-pillar-well-architected-framework/), and even though it's a focus I love to see, it also means there has not been a ton of guidance shared to optimize for sustainability. If you're invested in areas involving hardware, AI/ML, large sets of data, IoT, etc., this is a bit more obvious to contend to - simply put, you want to use less resources, and more sustainable (or at least recyclable) hardware. WIth serverless, you are already scaling automatically, only paying for what you use, and optimizing for your [event driven architecture](https://aws.amazon.com/event-driven-architecture/), which makes it more difficult to find areas to cut down on usage. My best advice is to review your architecture early & often, and continually try to find ways to [lower your carbon footprint](https://www.nature.org/en-us/get-involved/how-to-help/carbon-footprint-calculator/#:~:text=A%20carbon%20footprint%20is%20the,is%20closer%20to%204%20tons.) with optimal architectural design, and if you haven't made the jump to serverless yet, maybe that's the first step!
+
+**Serverless Lens**
+
+![A pair of eyeglasses with lenses. Image via Unsplash.](images/day75-8.jpg)
+
+In addition to the six pillars, AWS Well Architected has this concept of [Well Architected Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses.html). Much like a pair of reading glasses, you can apply a specific Lens to your application to 'see' your application in a bit more detail. There are Lenses for [Machine Learning](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/machine-learning-lens.html), [Data Analytics](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/analytics-lens.html?did=wp_card&trk=wp_card), [Financial Services](https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/welcome.html?did=wp_card&trk=wp_card), and, of course, [Serverless Applications](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html?did=wp_card&trk=wp_card). These Lenses are simply a set of extra guidelines and questions for each of these six pillars relating specifically to the type of application you are building. They are 'optional', as is the entire Well Architected Review process, but again, if you are building a serverless application, I would highly recommend you complete a Well Architected Review with the Serverless Lens, as it will only strengthen your application posture in the context of these six pillars.
+
+If you'd like to learn more about Well Architected or hear about it in practice, I have actually given a [recent talk on the subject with Build On at AWS Re:Invent](https://www.twitch.tv/videos/1674539542?collection=T1passDrLhdY6Q). This is an area of technology I have been very passionate about, and I truly believe these pillars and Well Architected Reviews are well worth the time and effort. We're coming up to end of our team together this week (I know, already?!) so for our last day tomorrow, I'm excited to summarize what we've learned so far, and present you with some next steps for going beyond the serverless basics.*
+*This is part of a series that will be covered here, but I also encourage you to follow along with the rest of the series on [Medium](https://kristiperreault.medium.com/serverless-well-architected-b379d5be10ad) or [Dev.to](https://dev.to/aws-heroes/serverless-well-architected-40jn).