Forem: Kristi Perreault

Serverless - Beyond the Basics

Kristi Perreault — Fri, 17 Mar 2023 22:50:42 +0000

Well folks, it appears the Serverless week for 90DaysOfDevOps has (already) come to an end. We have covered a ton of topics in serverless to get you started, and hopefully you're already well on your way to building your first serverless, event-driven application! We've defined what serverless means, we've talked about everything from lambda functions, to DynamoDB tables, Step Functions, EventBridge, and so many other core & supporting AWS services to aid in your development journey. Although it's been a very high-level overview, I truly hoped you have enjoyed our week together, and have learned a thing or two about serverless development. Even if you've left this week with more questions than answers, I would say I've done my job - which is, made you interested and curious enough about serverless to want to explore it even more!

Instead of going into a ton of depth on various topics in serverless on our last day, I thought it would be much more useful to provide you all with resources where you can go to learn more. The problem is, there is so much content, so many well-formed opinions, and tons of sample projects out there, I don't even know where to begin! I know that if I start to list out individuals or blogs, I am going to forget so many, and not give proper credit where credit is due, so instead, I will provide you with some places or projects to get started, and let you explore on your own and form your own thoughts & opinions. The only ask I have for you is this - please do your best to support and encourage diversity & our minority content creators. Too often I see folks share lists of their favorite people, accounts, conference talks, blogs, or open source projects, and there is no diverse representation. There are tons of incredible content creators (or to-be content creators!) of all different backgrounds and identities that never get enough credit, and if all of us can help in any small way, it can make a huge impact. I encourage you to take advantage of the comment section below to promote some of your favorite diverse individuals - I'd love to add them to my network too!

Thanks again for taking this serverless journey with me this week, and please enjoy this list of more resources to explore. Until next time, my serverless friends!*

Resources to Learn More

Medium - Blogging platform with tons of great content
Dev.to - Blogging platform with tons of great content, specific to developers
aCloudGuru - Video learning platform, great for certifications
ServerlessLand - All things serverless, resources & announcements from AWS
AWS Twitch - Space for podcasts, walkthroughs, and casual conversations with AWS employees
AWS Docs - Official documentation for all things AWS serverless
AWS Certifications - Explore getting certified
AWS Youtube - Great deep dive talks & features on AWS services from years past
AWS CDK - Infrastructure as Code tool, popular in serverless development
AWS SAM - Infrastructure as Code tool, specifically for serverless development
AWS User Groups - Get involved in your local community!
AWS Hero Program - Learn more about our community evangelists
AWS Community Builder Program - Keep this bookmarked for the next round of applicants

….and so much more out there for you to explore!

*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 90DaysOfDevOps.

Serverless & Well Architected

Kristi Perreault — Fri, 17 Mar 2023 00:48:53 +0000

Over the last few days, we've discussed a number of topics in the serverless space, covering storage, APIs, compute, and everything in between. 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. 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, Cost, Operational Excellence, Reliability, Performance Efficiency, and Sustainability. 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 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.

Security

Simply put, how are you securing your app? Are you using authorization and authentication with IAM users, roles, and policies to limit access to your resources? Setting up permission boundaries and using KMS keys 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.

Cost

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 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 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.

Operational Excellence

One of my favorite topics to talk about is 'Clean Code', or better known as best practices within your code. Although this could cover many of these pillars, it arguably fits squarely within Operational Excellence. 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 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

Is your application stable? Do you backup your data regularly? Do you have failovers 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, backing up your data, and having processes in place for the 'worst-case scenario'. Hopefully by completing a reliability review, these things don't occur as often, or aren't as widespread as they might've been before a review.

Performance Efficiency

Closely related to the Operational Excellence and Reliability pillars, the Performance Efficiency 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 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

Sustainability 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, 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, 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 with optimal architectural design, and if you haven't made the jump to serverless yet, maybe that's the first step!

Serverless Lens

In addition to the six pillars, AWS Well Architected has this concept of Well Architected Lenses. 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, Data Analytics, Financial Services, and, of course, Serverless Applications. 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. 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 90DaysOfDevOps.

Serverless Orchestration

Kristi Perreault — Wed, 15 Mar 2023 19:50:55 +0000

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.

AWS Step Functions

Is it weird to have a favorite serverless service? Because this one might be mine. AWS 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, 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' 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.

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 tool like CDK to provision in python or typescript, and then defining the actual steps - otherwise known as the 'state machine' - 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, 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

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, to help you schedule tasks associated with your events, and finally 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).

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

Amazon 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, 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

Amazon 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. 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, 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 90DaysOfDevOps.

Serverless APIs

Kristi Perreault — Tue, 14 Mar 2023 21:04:57 +0000

If you're new to the application development world, API stands for Application Programming Interface, an interface that offers a 'service' of sorts for applications to consume. Google Maps, for instance, has a public API 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 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.

Amazon API Gateway
Let's say you have a travel website - you have your frontend application, and you have your backend application that has some lambda functions to handle users creating, updating, and deleting their vacation reservations, which interacts with a DynamoDB table that is saving all this information for you. Your frontend application, however, needs to be able to communicate and pass information back and forth with these lambda functions. This is where an API Gateway comes in. An API Gateway is typically a REST API (Websocket is also an option) that manages different endpoints for your application. For instance, when a user creates a reservation, the frontend application may hit a POST endpoint on your API called 'createReservation', and you can configure your API to directly integrate with your 'createReservation' lambda function, where you might do something like create a new reservation ID and save it to a DynamoDB table.

This is just one fairly straightforward example; you might already be able to see how this can get very complex very quickly. It helps that API Gateway has tons of configuration options, allowing you to set up your level of application monitoring and logging, set concurrency and throttling on your API calls, directly integrate with multiple services, and, of course, your authorization and access levels. With API Gateway, you pay for the calls you receive and the data you send out. When you define a REST API, the API Gateway is actually made up of three different resources - the API itself, a Stage resource for each environment which can aid in version control and other configuration options per environment, and a Deployment resource, which is essentially a 'snapshot' of your API for the Stage to use. In addition to these resources, you also need to define each of your endpoints as a new route on the API Gateway individually. API Gateway is a very powerful and useful tool at your disposal, but it can grow quickly and easily get fairly complex, so make sure you are designing your application to account for your specific needs.

AWS AppSync
I'm keeping this section a bit shorter for you all, since AppSync is not something I have actually used personally, but have heard great things about. AppSync is another API option AWS has made available specifically for applications that want to take advantage of GraphQL or a Publish/Subscribe model. The GraphQL model may be of interest to front end developers that need to query multiple sources of data from one API endpoint, like databases or microservices. The Pub/Sub model I am more familiar with in the IoT hardware-communicates-with-software aspect, however this is also powerful for frontend developers looking to take advantage of real-time updates with serverless WebSocket connections. With AppSync, you also have caching, offline data synchronization, and real-time updates. You can learn more and check out the developer docs on the AWS Website.

As with all of these short, daily articles, there is so much more that I could dive into here, but my purpose this week is to provide you with a little taste of what the serverless space has to offer, and get you started as a newbie to serverless. I'd highly encourage you to read up even more on effective API Design, and even get started with a tutorial, workshop, or even your own project (feel free to try out the travel website and let me know how it goes!) Believe it or not, there is still more to explore in the serverless space, so in my next post we will continue on with some really helpful integration & orchestration services.*

*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 90DaysOfDevOps.

Serverless Storage

Kristi Perreault — Mon, 13 Mar 2023 20:33:53 +0000

Lambda functions and Fargate serve a great purpose and might accomplish what you need for a very small, hello world-type project, 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.

Depending on what you're storing, how frequently you access stored items, and how you want to interact with them, you have a number of choices regarding file & image stores and serverless databases. Over the years, AWS has released a number of choices (some, may argue, aren't necessarily within the 'serverless' category even when named as such) but the number one choice in its humble beginnings was Amazon S3.

Amazon S3
Amazon S3 is a popular abbreviation for 'Simple Storage Solution' and is known as object storage. You can store any number of items in S3, from various documents, to images, videos, entire file systems, and so on. In order to store these resources, you provision your own storage space, known as an S3 'Bucket'. The easiest way to describe a bucket is to compare it to a folder on your computer. Your 'Documents' folder, for instance, may contain all of your Word documents, and you may have sub folders within it, say for 'recipes' or 'projects' or 'schoolwork'. S3 buckets operate similarly, and just like your Documents folder, you can include sub folders and all different resource types. S3 is also a very popular choice for hosting static websites, and just like any other cloud offering, there are also plenty of security constraints in place for you to take advantage of, like bucket encryption, read-only access, and more.

Of course, there are tons of other great advantages to using S3 buckets. Many of AWS's other great resources, like Lambda, have direct integration with S3, making it easy to access and read/write directly to your bucket. S3 also has different types of storage classes, like Intelligent Tiering and Glacier, that are more cost-effective for items that are accessed infrequently or for very large storage amounts. S3 is a global storage solution though, meaning that the name of your bucket must be unique across all AWS accounts within your regional partition (so yes, it is likely 'test-bucket' is taken). Whatever your storage need may be, S3 can be an effective solution, and one that is significantly cheaper and more secure than your on-premises solution or office filing cabinet.

Amazon DynamoDB
As developers, sometimes we are working with larger, very structured datasets that involve schemas and specific access patterns. For these, a database solution makes much more sense, and luckily we have a serverless option for that too! DynamoDB is a NoSQL database solution that offers lightning fast performance, 'near unlimited' throughput and storage, and backup, restore, and multi-region replication to ensure your data is always available and secure. You can interact with your database using queries, scans, read/writes, and more, all from the AWS console or the comfort of your favorite programming language.

DynamoDB is a powerful service, but you really will not be able to capitalize on all it has to offer unless you structure your data for Single Table Design. I will admit, mastering the art of Single Table Design (I just tried to abbreviate that, and I will never do that again..) is not easy; I would go so far to say that it is probably one of the most difficult parts of serverless development (if you're having trouble, the resources Alex DeBrie puts out for this are unparalleled). You really need to have a good grasp on your dataset, understand ALL of your access patterns up front to plan your Primary Keys (PKs) and Global Secondary Indices (GSIs) accordingly. I don't want to go too in-depth into this topic, since there are literally full books on the subject, but just know that although I think the advantages you have when using DynamoDB to its full potential are well worth it, this can be a steep learning curve and isn't going to be the database storage solution for everyone.

Amazon EFS, Amazon RDS Proxy, Amazon Aurora Serverless, Amazon Redshift Serverless, Amazon Neptune Serverless
This is my serverless database catch-all section. In my opinion, S3 and DynamoDB are really the storage solutions you need for serverless development, however, you may find some use cases for these remaining serverless storage options. EFS is the Elastic File System, which automagically sizes for the number of files you have (S3 covers many file storage situations, but if you have something specific in mind, you may want to use EFS). RDS Proxy makes relational database connections more secure. Aurora, Redshift, and Neptune Serverless are basically the serverless versions of these three AWS service offerings. Some of these are up for debate in the serverless community as to whether or not they really constitute as serverless offerings, but since they are not databases I have had a use for in my short career, I will abstain from weighing in here.

Well, this about sums up the serverless storage solutions available. As always, there are definitely equivalents of these resources in your cloud provider of choice, and you can't go wrong with any service you choose, as long as you're evaluating based on your specific application needs. Join me tomorrow, as we take another step further into serverless with API design.*

*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 90DaysOfDevOps.

Serverless Compute

Kristi Perreault — Mon, 13 Mar 2023 00:32:38 +0000

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?

The key compute resource everyone immediately associates serverless with is AWS Lambda. I want to be clear here - AWS Lambda is a large part of the serverless ecosystem, BUT Lambda ≠ serverless. Just because you include a lambda function in your application does not automatically make you serverless. Likewise, just because you build a service completely out of lambda functions also does not mean you have a serverless application. Serverless is a mindset, a new way of thinking; there are tons of tools and services out there that will help you build serverless applications, but implementing them does not mean you have a serverless application. We need to be intentional with our design, and where & how we use these resources.

AWS Lambda
If you're in Azure, your equivalent service is Azure Functions. For Google, this is Google Functions (yes, AWS just HAD to be different). Regardless of its name, all of these services fulfill the same purpose - a small compute building block to house your business logic code. An AWS Lambda function is simply the code you want to run, written in your language of choice (I preference Python, but Typescript and Java are popular options). In your infrastructure code, you specify some lambda function basics, like name, path to the business logic code, security role, and what runtime you're using, and optionally have the ability to control more parameters like timeout, concurrency, aliases, and more. Lambda even has built in integrations to other AWS services, such as S3 and SQS (we'll get to these) to make application development even easier. Additionally, lambda functions are priced based on the number of times they're invoked and the duration of time they run, making them exceptionally affordable.

Of course, there are cases where lambda functions may not be the best option for compute, if you have long-running, highly complex computational processes, lambda functions may not be the best fit for your application. If you're migrating an application to serverless, it's also very likely that this is not a 1:1 changeover. Throwing all of your code into one lambda function is not optimizing for serverless, meaning that your monolith architecture may need to be written into microservices to take full advantage of everything lambda and serverless has to offer. Whether you're migrating or building something brand new however, lambda functions are (dare I say) the choice for serverless compute as they're lightweight, easy to provision, and cost effective.

AWS Fargate
AWS defines Fargate as a 'serverless compute engine', but I prefer to define it as a serverless container. Containers are an entirely different topic of discussion so I won't dive into them too much, but they do fall under the same "modern applications" umbrella that serverless does, making them a sort of sibling option. Containerizing an application is a fancy way of saying you are bundling all aspects of your application into a more portable service (ie, basically sticking your app into a box for ease of movement and use). This makes containers very popular for migrating applications, batch processing, AI/ML, and more.

Fargate stands sort of in the middle as a container service that offers many of the same serverless benefits that lambda has - no need to manage your infrastructure, built-in integrations to other AWS services, and pay-as-you-go pricing. What makes you choose one compute option over the other then? In my experience, this really comes down to what you want your end product to be, what time you have, and what experience you have. Personally, Fargate is more of a 'lift-and-shift' solution for applications that you don't want to change much of, but need to move quickly and easily while wanting to take advantage of serverless benefits. It definitely has its place as part of other applications as well, but it also comes down to the level of comfort you or your teams have with serverless or containerization. Containers may be quicker to adopt, whereas serverless requires more of a mindset shift, and typically comes with some rearchitecting. I believe this does pay off tenfold in the long run, but given your particular use cases and time constraints, Fargate may be a better option.

These two options pretty much sum up serverless compute, believe it or not. When it comes to your business logic code in AWS or other cloud provider, these two services cover most, if not all, serverless application needs. As we continue on in this series, you'll realize there are a ton of other 'supporting' serverless services for storage, APIs, orchestration, and more to dive into. I hope this has given you a good preview on serverless compute and what's to come, tune in tomorrow where we'll discuss the various serverless storage solutions available to us. See you then!

*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 90DaysOfDevOps.

What is Serverless?

Kristi Perreault — Sat, 11 Mar 2023 13:57:57 +0000

The term "Serverless" has become quite the buzzword over these past few years, some folks today even arguing whether or not the term still holds weight. You may or may not have heard about serverless technology up to this point in your journey through development. But what exactly is serverless? What does it mean to design applications in a serverless manner? What constitutes a serverless service or offering? I hope to answer all these questions and more over this series of blog posts.

As an AWS Hero and a Principal Software engineer at a large Fortune 100 enterprise, I have been focused solely on serverless technologies and enablement over the last 3 years. I have spoken quite extensively about our serverless journey, what serverless means in a large enterprise, and how to be successful in a corporate setting. Everything I have learned has been through experience, on-the-job. The serverless definition I resonate with most states that serverless is event-driven, your resources scale up and down without you needing to manage them, and follows an "only pay for what you use" model. Let's break this down a bit further:

Event-driven architecture is exactly how it sounds. You build your applications following the flow of your events. When x happens, I want to trigger y, to run service z. We write our serverless applications with this flow in mind.
Automatically scaling up and down as your service demands is a key component of serverless functionality. I fault the name "serverless" here a quite a bit, because contrary to popular belief, serverless does in fact include servers - you just don't need to manage them in the same way you would with your on-premises ecosystem or other cloud resources. You still need to provision the resources you need, and some configuration is required, but gone are the days of estimating exactly how much storage and processing power you need - your cloud provider handles this for you. This frees the developer up for focusing more on business code, and less on physical infrastructure.
With automatic scaling, this also lends you to only pay for exactly what you are using. You no longer need to buy and maintain a physical server you may only use to half its capacity, save for the one time of year your traffic hits its peak, for instance. You don't need to pay for all the storage and processing power you have to have "just in case" - you pay exactly for what you use, exactly when you need it. No more, no less.

I am a large proponent of serverless, and I believe these are huge benefits to adopting serverless, but that does not mean it is for everyone or every architecture. I talk quite a bit about the concept of "serverless-first" design, meaning that you approach every architecture in a serverless manner first, and if that is not the most optimal design, you move on to other solutions like containers, relational databases, reserved compute instances, and so on. Equally as important, especially in a large enterprise, is to evaluate your time constraints and areas of expertise. Serverless is not going to be for everyone, and depending on your background, there can be a large learning curve associated with adopting it. The trade off is worth it, but if you do not have the adequate time or drive to dedicate to this transformation, you will not be successful.

That being said, I hope to provide you with a strong starting point for the land of serverless. Over the next few days, we will be exploring serverless resources and services, from compute, to storage, to API design, and more. We will keep our discussions high-level, but I'll be sure to include relevant examples, resources, and further reading from other leading industry experts. No prerequisites are necessary, I just ask you approach each and every article with an open mind, continue to ask questions & provide feedback, and let's dive in!*

*As a quick disclaimer - as I am an AWS Serverless Hero, most of the examples and explanations I give will reference the AWS ecosystem since that is where my expertise is. Many of the AWS services and tools we will discuss have equivalents across Azure, GCP, or other tooling. I will do my best to call these out going forward. This is part of a series that will be covered here, as well as part of a larger effort on 90DaysOfDevOps, which I highly encourage you to follow along with.

Is This Thing On? Giving an Effective Talk In Person

Kristi Perreault — Fri, 20 May 2022 05:03:34 +0000

It seems funny to be writing this, considering how many articles are out there discussing how to better engage with virtual audiences, but if you're like me, you may find yourself in this unique position where your speaking career STARTED over the pandemic, and you've never actually had to speak to large audience in person. Or maybe you have, but the 2+ year hiatus has left you lacking confidence, motivation, or just feel like you may've been out of the game too long. Or maybe you have yet to start at all, in which case, you can take this as a sign…

These last few weeks I have been fortunate enough to travel to multiple conferences in the United States speaking about Liberty Mutual's current state of serverless in person. I know not everyone is keen on public speaking, but I wanted to take a moment to share some of my experiences as someone who has had to transition from virtual webinars and conferences to giving a talk live and in person. First, however, a quick summary of my latest travels.

We kicked off the speaker tour at the AWS Summit in San Francisco, where I gave the very first dev chat at the community lounge in the expo hall on Day One. Since this is a developer community talk, it is unfortunately not recorded, but please enjoy this photo of me accidentally matching the backdrop perfectly.

Next stop on the speaker tour was back at my home base in Denver for DevOpsDays Rockies. A fantastic venue, great food, and even better people, I would happily speak or attend a DevOpsDays again. If you missed it, you can catch the recording of my specific talk on YouTube, right at the 2:21:00 mark. Thanks to some really awesome audience members and the power of Twitter, we've also got another great speaking shot!

Last but not least, I headed back to San Francisco to speak at Serverless in the Park, part of this year's Reactathon conference. I am thrilled to have had the opportunity to speak at the Serverless in the Park debut, and honestly, if you get the opportunity, speaking on stage outside was an absolute dream. This was my favorite venue to speak at by far; if you missed it, see for yourself in the photo below, or check me out at the 5:00:00 mark in the recording.

Now that we've established that I clearly love to speak on a stage, I want to pass on a few tips & tricks I've learned over the past few weeks to help improve your in person speaking engagements, or at least give you a glimpse into the mind of a conference speaker.

Engaging with the Audience
If you've presented in a video call, you'll know that it can be one of the least engaging mediums to give a talk in. Everyone is muted, no one has their camera on and even if they do, you can't see everyone to gauge interest or engagement. It's like speaking to an empty room, and aside from the occasional comment in the chat or virtual hand raise, you have almost NO feedback from your audience. In person, however, your audience is right in front of you, clearly present, and - perhaps the most important thing - reactive! If you crack a joke, you get laughter and see smiles, instead of absolute silence and a blank screen. As you're speaking, you can clearly tell who is engaged and what is resonating with folks through body language you miss out on in video format - eye contact, head nods, note-taking, etc.

Which leads me to my actual point of discussion here…stage presence. In person, on a stage, it matters. Make eye contact. Utilize the space you have on the stage - you want to be comfortably in between standing completely still behind the podium and pacing rapidly back and forth. You can gesture, point, and narrate with your hands, though if you're Italian like me you may need to reel it in a tad. If you're an anxious speaker, maybe find something to fidget with to keep your hands occupied or to keep in your pocket. Oh, and don't forget, we're back in public now, so you may want to leave the sweatpants at home…no need to break out a 3 piece suit or your nicest heels, but dress to impress! Be expressive, professional, or theme your outfit to your talk for a fun twist! When all else fails, you can never go wrong with the classic tech t-shirt and jeans.

Speaking without a Script
One might call this a downside of speaking in person, but I actually quite enjoy the off-the-cuff speaking style. When you're presenting from home, it's so easy to have a script or very thorough notes right there in front of you to read from or reference while you're talking. On stage, unless you're somewhere fancy enough to be using a teleprompter, your slides are typically your only reference point - and you don't want to write everything word for word on them. You want the audience listening to you, not reading the words on the projector behind you.

This is why I think it is very important to speak on a subject that you are passionate and knowledgeable about, because you'll know it like the back of your hand; and preferably, it tells a nice story. Crafting a narrative is, in my opinion, easier to remember, provides for a natural flow, and hooks your audience. If you leave your slides generic enough, you can also make changes on the fly, and easily adapt to the audience. Practice this a few times out loud to yourself, or maybe your dog if that helps, but make sure to not overdue it. I have definitely run through my slide decks one too many times, and end up completely boring myself since I know it all too well. It's a balance.

An Ongoing Q&A
This one might be my absolute favorite thing about speaking in person - the conversation is ongoing! If you give a virtual presentation, sometimes you get a few folks that will come off mute and ask a question or send it in the chat, and maybe if you're really lucky, you get an email or DM follow up. The thing that I find really cool about speaking in person is that your talk really doesn't end after that 30min time slot.

With meals, breaks, and open spaces, you're provided with opportunity after opportunity to organically engage in even more conversation. I can't tell you how many times I've stepped off the stage and two hours later someone in line for coffee with me or sitting down at the lunch table asks me a follow up question or comments on one of the points I made on stage. It really allows for open two way conversation, much more than a virtual environment does. If you think of a question later, you have to go out of your way to find & follow me on social media and reach out, but in person, you could easily just find yourself sitting right next to me, a great opportunity to spark up a conversation (and you can - I swear I don't bite).

I'm sure I can think of plenty more tips that have helped me out these last few weeks speaking in person, but these are the top three that come to mind. If you enjoyed these ones and want to hear more, or if you have other tips & tricks I neglected to mention, comment below or reach out to me. If you're interested in my upcoming speaking engagements or recordings to some of my other events, make sure to give me a follow on Twitter or LinkedIn; clearly I love to talk ;) Happy speaking!

The Great Migration: Upgrading CDK v1 to v2

Kristi Perreault — Wed, 30 Mar 2022 23:56:07 +0000

At long last, CDK v2 is here and ready for import! Announced at Re:Invent 2021, CDK v2 boasts a single package import, stable APIs, and up-to-date API reference documentation.

If you have no idea what the heck CDK is or what I'm referring to, take a step back and read up on it. If you are just getting started with CDK, you can stop reading here; I'd highly recommend you jump right into v2, no need to bother with any of this v1 nonsense.

If you're like me and you've been living, breathing, and loving the CDK since its v1 days (or maybe you just have a few CDK v1 projects you casually maintain, no need to be a guru) then this post is for you! I've spent the last few weeks migrating my enterprise projects from v1 to v2, and today I want to share the process for updating - both python and typescript, we keep things inclusive here on my blog - the "gotcha's" I ran into, and highlight some of the new key features of v2 along the way.

A quick note here - in my expert opinion, the v1 to v2 migration is not highly complex. I do think the migration guide provided by AWS provides you with a great starting point, therefore I will not go into all the intricate details since it is included there for you. Instead, I am hoping to leave you with some anecdotal evidence in what I hope to be simple and straightforward language. Let's dive in!

Initial Setup
I'll preface this by saying python is my bread & butter, so it stands to reason that most of the projects I have been updating are in python. Sincerest apologies to my node friends.

If you're a Typescript developer, you need to make sure you are on 3.8 or later. For all languages, you will need to bootstrap your account with the new modern toolkit stack, which is backwards compatible, in order to take advantage of v2. This should be pretty easy to do, however do make sure to review the permissions and bucket encryption for the modern toolkit as they have changed to specified permissions and a customer-managed key.

Additionally, just make sure to run your npm or yarn install commands to install the new v2 dependencies. Reminder you can specify versions by explicitly stating @2.x.x.

Upgrading your Python & Typescript Projects
The biggest change you will notice from v1 to v2 is the package import. Instead of having to individually bring in each construct you want to use into your requirements.txt or package.json file, all STABLE constructs are now included in the aws-cdk-lib package.

# CDK v1 requirements.txt
aws-cdk.core
aws-cdk.aws_iam
aws-cdk.aws_s3

# CDK v2 requirements.txt
aws-cdk-lib==2.18.0

//CDK v1 package.json
"devDependencies": {
    "@aws-cdk/core": "^1.150.0",
    "@aws-cdk/aws-iam": "^1.150.0",
    "@aws-cdk/aws-s3": "^1.150.0"
 }

//CDK v2 package.json
"devDependencies": {
    "aws-cdk-lib": "^2.18.0"
 }

Along with this, your import statements will also change. You can see examples of what this looks like for python and typescript in the migration guide.

The next biggest change you may see is in your cdk.json, which is luckily the same in both languages. Most of the feature flags you may have been using in v1 have been removed, so for most folks the context in your cdk.json file can be removed. Your json file in v1 may have looked something like:

{
  "app": "python3 app.py",
  "context": {
    "@aws-cdk/core:enableStackNameDuplicates": "true",
    "aws-cdk:enableDiffNoFail": "true"
  }
}

Removing the feature flags for v2 we are left with:

{
  "app": "python3 app.py"
}

If you need backwards compatibility, you can still take advantage of one of the four remaining feature flags.

Gotcha's
Do not forget to check and update your tests! I fall victim to this every time; I update the code and the package files for v2, make sure the documentation is updated and then…forget to double check and run the tests. You will need to update the imports in the tests just as you did in the code. If you are taking advantage of the assertions library, @aws-cdk/assert, this is still required as a separate package, it is NOT part of the aws-cdk-lib package.

You are also welcome to continue using experimental constructs just as you might have in v1. As of this blog post release date, you will notice quite a few of these constructs in alpha, most notably for myself was the language-specific constructs like the python and go lambda function constructs. These can easily be identified in the AWS CDK v2 documentation with the legacy @aws-cdk package prefix followed by an -alpha tag at the end, and will need to be brought in as single packages as in v1; they are NOT included in the aws-cdk-lib package. Also note that there is a separate construct package for your Construct, Dependable, and Node classes, so if you need these makes sure you include the construct package.

What has tripped me (and several others, as I have come to learn) up is it is not always clear which v1 constructs are experimental, and which ones are stable. For instance, I was using the GlueDB resource in v1 and when I moved to v2, I realized the construct was experimental. There are some Glue resources that are stable and some that are experimental in v2, so I had to find and bring in the appropriate glue alpha package separately to utilize GlueDB. Unfortunately, I do not have the time to compare side-by-side every single CDK construct that has or has not changed, so I would recommend that you reference the AWS CDK documentation and the CDK Construct Hub for your specific use cases if you have any concerns.

All in all, my experience upgrading from CDK v1 to v2 was a fairly smooth one, and I'm hoping it was the same for you! If you've been migrating your projects, let me know if this helped, or if you ran into anything else I didn’t cover. If you jumped on this shortly after I posted it, I'd also love to hear your story at CDK Day 2022 on May 26th. CFPs are open until April 20th, please reach out to me if you're interested in presenting or need help with a topic idea. Happy migrating!

Overcoming our Biases & Supporting Women in Tech

Kristi Perreault — Fri, 04 Mar 2022 15:25:24 +0000

In honor of International Women's Day and Women's History Month, I wanted to cross-post this women in technology article I wrote a few months ago, sharing my software engineering story for the Dev.to audience and #shecoded community. Please enjoy, and remember we're in this together, let's keep moving forward!

At age 16, I took my first engineering class in high school. As one of only two girls, I was met with whispers of “she only took this class to meet boys, and have the attention all to herself.”

At age 17, I sought out an AP Computer Science class online and only made it halfway through. I was told that maybe programming wasn’t for me, and I should explore other options.

At age 18, I applied to college for computer engineering, and I was met with questions like “are you sure you want to do this? It’s going to be really hard, are you up for it?” and “You know you’ll probably be the only woman in most of your classes, right?”

At age 20, I was told I could have any internship I wanted because “all tech companies are looking to hire women.”

At age 22, I drove 12 hours to Michigan to compete in an autonomous vehicle competition with a vehicle I had led the autonomous algorithm development of. Again, I was greeted with a myriad of “wows” because no way was I in software.

At age 23, I was asked to work front-end development on a project because “I’d have a much better eye for it” than any of the men on the team, and the back-end development was “pretty complex”.

At age 24, I was told our “this could have been an email” meeting had value because the only two other women on the call had “made a connection” and were now friends because they were the only two that spoke up.

At age 25, I removed my job title from my dating profile because I was sick of being told that I was too pretty to be an engineer or too smart and intimidating to be with.

At age 26, I have mentored dozens of female college students, interns, and new hires, and every single one of them has told me they have wanted to give up and have asked me how I handle it.

A few weeks ago, I was on a flight to a large tech conference, and the men next to me were not only surprised that I was attending but also that I was attending as a senior software engineer in serverless and could hold my own in a technical conversation.

I share these stories not to shame and look for pity but to raise awareness and understanding. The funny thing is, I look back on all of these moments (and many others that I did not share here) and think about how lucky I am. How lucky I am that it wasn’t worse, like the stories I’ve heard from dozens of other women. How lucky I am that, for every bad comment, there were a dozen good ones telling me to keep going.

A few days ago, I was asked to join Serverless Office Hours. At minute 7:50 in the video recording, Julian Wood asked me about my experience as a woman in technology, and he asked what others can do to help support women. Honestly, I wasn’t satisfied with my answer, and after taking some time to think about it more, I’ve decided I can do better. So, if my journey in tech thus far has left you frustrated, confused, or just plain curious, and you’re wondering what you can do to help, I encourage you to read on.

Build women up
It could look like a number of different things, depending on the person (or people) you’re helping and the role you hold. If you know of a job opportunity that’d be perfect for them, share it. If you know of a podcast looking for a guest, pass their name along. If they wrote a book or a blog post or contributed a feature you like, share it with your network. The possibilities here are endless, and it’s so easy to stand up and spread the word. Don’t underestimate the power of your voice and the weight of your word.

The flip side of this — and it’s something I am guilty of — is many of us tend to compare ourselves to others and downplay our achievements. If you want to help, hype us up, even if it’s just to our face. The women I know are achieving great milestones every day, but they are too humble or too quiet or too scared or just honestly don’t think it’s impressive enough to share out when it very much is.

Watch the water cooler talk
Yes, I know most of us are no longer near water coolers, and we aren’t socializing as much as we used to, but it is still important to create an inclusive environment, even in the virtual world.

I love the recent focus on using more inclusive language, like asking for pronouns and choosing to use “you all” or “everyone” over “you guys”. We need to continue giving women a platform to speak, whether in a team meeting, a presentation, or another medium (unintentional pun). It’s important to know when to speak up for women and when to step aside and let their voices be heard.

I have heard frustrations from many women about some of the “water cooler” talk in the tech scene. Many feel like they are being criticized for having more “feminine” interests and not always talking about sports or [insert another primarily male-dominated interest here]. And honestly, I can see where they’re coming from. Yeah, I am the commissioner of my Fantasy Football league, and I am also anxiously awaiting the next season of The Mandalorian. But I’m also watching The Bachelor on Tuesday nights, and don’t you dare dismiss me for that. Be conscious of your audience, and don’t make assumptions based on gender.

Educate yourself so that you can educate others
Earlier, I mentioned my frustration with this phenomenon of women in technology needing to be the best of friends. When I noticed this in a meeting I was in a few years ago, I pointed it out to a trusted colleague. He was shocked when I explained my perspective and apologetic that he didn’t notice it before. I very much understood, brushed it off, and moved on with my day. About a week later, he called me, saying it bothered him so much that he went out and bought a book on unconscious bias and had read it cover to cover over the weekend and asked me if I would hold him accountable going forward. It moved me to tears and still does today. When I say educate yourself, THIS is what I mean.

Pick out your gaps, find your blind spots, be honest about the things you don’t know, and work to improve them. Hold others accountable, too, even if you’re still learning. If someone is posting sexist remarks, call it out. If you’re part of an interview team and the candidate pool severely lacks diversity, speak up. If you see something — a snide comment, rude behavior, any sort of harassment, etc. — say something. Your word holds more weight than you think it does.

Ask them what they need
When all else fails, just ask us what you can do to help. We’re all different people with different needs and perspectives. What bothers me may not bother the woman standing next to me.

I share these tips as general guidelines that I have found to be most helpful in my tech journey, and I’m sure it will evolve and change over time (and hopefully for the better). Chances are, if you’re reading this, you’re already way ahead of the curve, so be sure to share with a friend, colleague, or probably most beneficial, the Worst Guy You Know.

For those that may be concerned or worried or just plain mad about some of the anecdotes I shared above, don’t be. Despite all the adversity and frustrations, I graduated first in my engineering class with summa cum laude. I went on to get a Master’s degree in Electrical & Computer Engineering while working full time.

I continue to push the envelope and work towards excelling in my career every day, in any way I can. I have found such an incredible support system throughout my journey in tech so far, and as much as I hate the whole #NotAllMen hashtag, I have found some pretty phenomenal and supportive male colleagues, mentors, and friends along the way.

We’re making strides, but we still have a long way to go. I’ll pay tribute to the old adage, what doesn’t kill us makes us stronger, right?