DEV Community: Stephen Sennett

Does Scale-to-Zero Redefine Aurora’s ‘Serverlessness’?

Stephen Sennett — Sun, 24 Nov 2024 15:29:29 +0000

Amazon Aurora Serverless v2 now supports scale-to-zero, allowing you to stop paying for your database when it isn't in use.

Sounds great - but what does it mean, and is it really serverless?

🖥️ What is Aurora Serverless v2?

First, some basics: Aurora Serverless v2 abstracts away the management of individual underlying database instances, and replaces it with "Aurora Capacity Units" (ACU's).

Each ACU is equivalent to about 2GiB of RAM (plus corresponding CPU, networking, etc.), and Aurora can seamlessly scale up or down to meet demand according to your configurations.

You incur a cost (about $0.12 per hour) as long as the ACU is provisioned. So at the previously cheapest level (0.5 ACU's), you're running up a $43.80 monthly bill, even with zero requests.

👻 Defining "Serverless"

Serverless is a technology with a problem: There's no universally accepted definition of what 'serverless' is. Ben Kehoe captures this perfectly in The Meaning(lessness) of Serverless.

For this scenario though, we need a framework to assess this against:

The team at Momento came up with their Litmus Test for Serverless, which I'll use as our gold standard of 'pure serverless'.

⚙️ How it Works

The official launch blog by AWS does its usual good job at covering the key information. Here's how scale-to-zero works in a nutshell:

With 0 ACUs, Aurora Serverless v2 DB instances can automatically pause after a period of inactivity. Aurora pauses an Aurora Serverless v2 instance if it doesn’t have connections initiated by user activity within the speciﬁed time period. For the paused duration, there are no charges for compute as the database is at 0 ACUs.

This is a change from previous releases, where you needed at least 0.5 ACU's - incurring a permanent minimum cost. If the database isn't used^*, you won't be paying for it. When new connections are received, it'll start up again.

Documentation also refers to this as auto-pause, which is very descriptive of the underlying mechanism. It's effectively pausing the database instance, since it's not in use.

👀 Caveats

There's a lot to know about what counts as being "used". Again to their credit, AWS lays it both in their blog post and much deeper in the Aurora docs; but to capture a few very interesting points:

Any open connections prevents pausing
Use of Replication and/or RDS Proxy also prevents pausing
Any connection attempt will cause the instance to resume
Resuming instances takes up to 15 seconds

These make sense given the underlying mechanisms, but this might be a surprise and remove a few use cases.

Update: Originally I'd mentioned that this effectively prevented use with Lambda Functions due to RDS Proxy. AWS Serverless Hero Michael Walmsley pointed out that this is still possible with the Aurora Data API! 👀

There's also a lot of specific recommendations depending on your cluster design, so as always the documentation is worth digging into before taking this to production.

🥶 (Very) Cold Starts

Cold starts are a persistent challenge of serverless, usually very solvable within the service. But for this case, we get positively arctic.

Instances take up to 15 seconds to resume, and ensuring a long-enough connection timeout will be necessary to prevent unhappy consumers. This has been discussed plenty.

One thing nobody seems to have talked about though is the Deep Sleep.

If an Aurora Serverless v2 instance remains paused more than 24 hours, Aurora can put the instance into a deeper sleep that takes longer to resume. In that case, the resume time can be 30 seconds or longer, roughly equivalent to doing a reboot of the instance.

Yikes...

This might not be the death-blow you'd expect - there are plenty of systems using SQL that aren't sensitive to long connection times; primarily system-to-system communications. But using it on human users would not be pleasant.

So let's try exactly that!

🧪 Experimenting with WordPress

First thought, how viable would this be to run a WordPress instance? Spoiler: Not very.

The cold start times make it a painful experience. Page load times aren't just a fluff metric either; poor loading times do impact conversion rates, so while you're saving money on infrastructure, you're probably losing exponentially more from lost revenue.

Any time you're not paying for the ACU's, you will pay with a guaranteed future cold start.

One thing I notice is that while you can configure it to shut down after 5 mins for maximum savings, you might choose to set that far longer just to avoid those cold starts.

Periodic reporting databases, where you might have many internal users slamming an application for a few days a month, but otherwise sits virtually unused. Set to a full 24 hours, most users would never see the difference.

For a typical solo WordPress site though, it'd be cheaper and more consistent to run both web server and database on a single EC2 instance.

🤔 Conclusion

tl;dr: It's definitely more serverless, but not "pure serverless". And I don't think that's a problem.

Databases are complicated, and "just making it serverless" is a hard problem. And while some solutions like CockroachDB make huge strides - check out this video where they explain how they scale.

"The right tool for the right job" is the motto of the wise architect. In similar cases, I'd also consider a single-table DynamoDB or even SQLite.

Even if this isn't 'pure serverless', this is a huge improvement that might make it just the right tool for your use case.

GenStack - Bring PartyRock apps to your place

Stephen Sennett — Wed, 17 Jan 2024 12:17:17 +0000

Update: By request of Amazon's legal team, the original name 'PartySmith' has been changed to GenStack.

Amazon PartyRock is a really cool concept, allowing you to build Generative AI applications using a clean visual UI, and removing all coding from the process, except the key parts of handling prompts. But it's had one problem - you can't take it with you.

As part of Developer Experience month, I've built 🔨GenStack (formerly known as PartySmith) - a platform that enables you to take the applications you've built with PartyRock, and host them yourself, on your own platform.

🚦 How it Works

First, go to genstack.ssennett.net. Drop in the URL of your public PartyRock application, and that's pretty much it! You can download a ZIP file with your application ready-to-go.

Inside you'll find the application, built on SvelteKit, which can be readily deployed to AWS using SST, or even other providers like Vercel with other SvelteKit adapters. There's even a README file with all the details built right into the template.

That's it! In fact, you can see the Demonstration App built around the Costume Theme Designer PartyRock app by AWS Community Builder Nadia Reyhani

For engineers who want to experiment with Amazon Bedrock that they can host themselves, but skip having to build a whole application, this is a handy intermediate step.

🧠 How it REALLY works

If you're a technical person, you probably want some of the inner-workings. So, let's talk details:

🗺️ Defining the Application

When you build an application on PartyRock, everything you've setup is defined into a JSON file, which looks something like this.

{
    "result": {
        "data": {
            "appId": "<uniqueAppId>",
            "username": "ssennettau",
            "creationDate": "2024-01-01T00:00:00.0000",
            "definition": {
                "version": 1,
                "widgets": [
                    {
                        "x": 0,
                        "y": 0,
                        "type": "text-input",
                        "title": "Input Thing",
                        "width": 12,
                        "height": 5,
                        "placeholder": "Write stuff here with the placeholder",
                        "defaultValue": ""
                    },
                    {
                        "x": 0,
                        "y": 5,
                        "type": "inferred-text",
                        "title": "Summarized Thing",
                        "width": 12,
                        "height": 5,
                        "prompt": "Summarize the following thing:\n\n[Input Thing]\n",
                        "parameters": {
                            "model": "bedrock-claude-v2"
                        }
                    }
                ]
            },
            "title": "Random Testing App",
            "lastModifiedDate": "2024-01-01T00:00:00.0000",
            "version": 10
        }
    }
}

The widgets lists all of the different components you've added to your PartyRock app. In this case, it accepts a text input from the user, and uses Claude to output the summarized results.

This is the basis of how the app works, using this as a blueprint for the various widgets.

🎨 Styling

GenStack apps come with a stylesheet built on Tailwind CSS, so it's very easy to adapt both to a similar theme to PartyRock, but also to whatever you'd prefer to use for your application.

Tailwind CSS does result in a lot of really lengthy class names, which can be a pain to work with.

<div class="z-10 max-w-5xl w-fit items-center justify-between text-3xl font-bold lg:font-semibold pb-16 lg:flex lg:text-5xl">

To solve this, I've used @apply rule's to consolidate the Tailwind Features into a single CSS stylesheet so we can use shorter and more meaningful class names.

<div class="party-header">

Another bonus is if you want to modify the way your app looks, it's a simple update in one place in the CSS. There's probably more best-practice ways to do this, but this is what happens when you let an ex-sysadmin write a web app - be glad I'm not using <table> tags. 😅

Looking forward to seeing some of the things people are able to dream up!

🌆 State Management

Unsurprisingly there's a lot of passing information back-and-forth in these apps, so I've had to try and plan the best way to do that. And my experience in front-end development isn't extensive, so if you have thoughts on my approach, please drop them in the comments!

Typically you want to keep state management at the highest-level possible, leaving your components stateless, just populating the contents being passed to them.

This doesn't work so well here...

The components in our app aren't quite as simple as they appear. Between tracking the different dependent inputs, calling Amazon Bedrock, and passing the data forward to any other components, there's a few things going on. In this case, I've flipped the concept around, with the state almost exclusively being managed within each widget.

This means each widget completely keeps track of what inputs it's expecting, how it should be processing it, making the call to Amazon Bedrock via our backend, displaying the result, and storing it for other widgets to use.

This made development a constant game of whack-a-mole when dealing with complex apps, trying to track what was causing any particular type of problem.

The main reason I opted for this approach was because of it's intended use for different applications. If it was a single-use app, I could code all the logic at the parent, per usual. But since this could be used with any PartyRock app, the design has to be a lot more flexible than usual.

🛠️ Building the Builder

This project really turned into two projects - first building the prototype target app which runs a PartyRock definition, and secondly the app to build those apps. Let's talk about the latter.

Code Generators aren't anything new, but it was something I haven't done before. Breaking the problem down into pieces, apps are generated effectively in layers.

The primary layer is the basic app in SvelteKit, absent the app definition file. In any app, first a copy of this template layer is taken and copied to a temp directory, and a copy of the definition file from the PartyRock source app is loaded into the necessary folder.

The additional features, like stylesheets or SST being baked-in have their own template layers, which will be copied in over-the-top of any existing files.

// Get the templated package.json
const packageJsonFile = path.join(tempPath, 'package.json');
const packageJsonContents = await fs.promises.readFile(
    packageJsonFile, 
    'utf8');
let packageJson = JSON.parse(packageJsonContents);

// Add the necessary packages
packageJson.dependencies['postcss'] = '^8.4.32';
packageJson.dependencies['tailwindcss'] = '^3.4.0';

// Commit the updated contents of the file
await writeFile(packageJsonFile, JSON.stringify(
    packageJson, 
    null, 
    4));

Finally, any files like package.json and README.md will be updated to reflect the necessary updates. This was less intensive than I'd expected, and often accomplished with some simple regex and file manipulation.

All of the code is wrapped up in builder.ts, with buildGenStackApp orchestrating the steps of the process. I had plans to refactor this code to make it a bit cleaner, but this project has taken far longer than I'd planned, so it's not been as high on the priority list.

🐌 Limitations

Unsurprisingly, this doesn't give the whole PartyRock experience that you know and love. Namely:

🖼️ You can't do any visual editing - Everything is down to the code.
📦 Layouts aren't retained - Just a single column layout by default.
🌏 Source app needs to be public - Unable to handle private apps.
💰 Amazon Bedrock isn't free - Your costs are your own, so take care.

Partly that's by design, because PartyRock is an awesome platform and I don't want to take away from that - this is just a bonus. The other part is that it'd take a long time to build, so I'm not going to re-invent (hah) AWS's perfectly good wheel.

For the layout, keeping it to a single column makes the code a lot easier to follow and modify. I'm sure there's ways to build it a lot more flexibly, but my attempts made the code a lot harder to follow.

Since the apps will run using Amazon Bedrock in your account, you will also need to ensure Model Access has been setup for the necessary foundation models.

🫵 Wrap-up

The goal is to take your experiments to the next-level with minimal friction. Here's a few things that came to mind:

Deploy an internal-facing corporate app in a VPC
Build an MVP for a more extensive public app
Highly customized personal productivity apps
Add payment processing and auth for monetization

PartyRock is an awesome creation by the team at AWS, and I hope this fills a niche to make it even more useful. And if the team want to take this as an idea to build an official version, I call that a win.

Lastly, this was also a chance to stretch my skills deeper into frontend development, something I'm not the best at. If anyone wants to make improvements, forks, or branch of a whole separate version into React/Next.Js or whatever, please do so, and let me know so I can follow along!

The Optus Outage: Business Continuity Lessons for Organizations

Stephen Sennett — Thu, 09 Nov 2023 04:53:43 +0000

Yesterday in Australia, huge portions of the country were left without phone or internet access when a massive telecommunications outage by Optus impacted over 10 million customers, including thousands of organizations of all sizes across the country.

What are some key lessons about Business Continuity that organizations might take away from this event?

What will fail?

First, we need to consider what might go wrong that could impact our business.

Okay, how could anyone plan to deal with a national telecomm provider breaking connections for 10,000,000 customers, and knocking their business offline? The good news is you don't have to. The bad news is the scale doesn't matter as much as you think.

So let's think about the biggest categories of hazards business face:

🤖 Technological

Losing your internet connection is a problem for a modern organization of any size, in any sector. Whether it was a whole country being knocked offline, or just your business, the impact is the same to your bottom-line.

Beyond that, technology risks extend through everything from other service providers going down, the iPad powering your POS suddenly not turning on, or a tradie accidentally knocking out all electrical power to your premises.

⛈️ Natural

Natural hazards have some obvious causes with extreme weather, like storms, heatwaves, blizzards, and many more. And of course, we've all just lived through a global pandemic. Your exposure ultimately depends on your work.

Retail and hospitality will see demand reduced by severe weather, and events may need to be cancelled entirely. Logistics businesses can be extremely exposed by transport challenges. Even geological risks like earthquakes became a huge concern for many organizations - especially governments and large building-owners.

🤷 Humans

Surprising nobody, humans are our own risk category. Consider the three categories already covered, even due to accidents: If extreme weather blocks the roads, employees can't get the work, illness requires them to take time off, or an accidental mistake causes a technological problem.

But the most terrifying human risks are the intentional ones. This could be internal, like insider attacks or criminal acts, or external risks like cybersecurity breaches or regular theft.

What happens when it fails?

Your organization has critical systems and business processes that it relies on. After thinking about what could happen, we need to think about how those events would impact our business processes.

Start by identifying your core activities, and what's necessary to make them work. Let's go with some common activities in most organizations:

Rostering staff for shifts
Delivering service to customers
Handling customer payments
Receiving goods from suppliers
Processing payroll to staff

Any of these processes failing would be a major problem for our organizations, and how they work will be different for every business.

What should we do when it fails?

No matter what, eventually something in our organization will break. It's just a matter of what will break, when will it break, and when will it happen.

"Everything fails, all the time"
Werner Vogels (CTO, Amazon.com)

Fortunately, even if a single system or process fails, the actual activity that we need to deliver often isn't completely prevented - there are alternatives we can explore.

But we need to explore them before the incident occurs, so we have a plan for how to react. We also need to exercise these scenarios, to see where they may not work as intended, and so people are familiar with what to do.

Let's look through a few scenarios:

💳 EFTPOS Terminal Failure at Local Café

Most people don't carry cash in 2023, and EFTPOS is vital to retail and hospitality businesses. When these machines break, it's a big problem. In this case, we don't know what's gone wrong - just that it's stopped working.

There's a few steps we could try. With hindsight and context, we might consider them "obvious", but that's never something we should assume, especially in a crisis situation.

Attempt the transaction a second time
Reboot the EFTPOS terminal
Try another EFTPOS terminal (if available)
Check for an internet outage
Enable S&F offline mode (if supported)
Use manual EFTPOS vouchers (if available)
Contact the bank/provider

There's also things we might need to consider ahead of time in our planning, such as whether our business has additional EFTPOS machines, or whether we'd be comfortable with enabling Store & Forward on our terminals. If we use manual vouchers, our staff would also need to know how to use them.

This doesn't mean you must take time for every staff member needs to be deeply familiar with the least-likely circumstances of writing the vouchers. But would it be reasonable that the duty supervisors are at least familiar with them?

⚠️ Cloud Outage at Global SaaS Software Provider

Most of my regular audience are cloud computing experts, and we're all very acquainted with the fact that stuff breaks a lot.

Let's take a look this time at the mitigation aspect, and what we can do before an incident takes place:

Ensure the application has been architected for fault-tolerance
Consider cross-geographical global deployments
Develop rigorous regular testing conditions (chaos engineering)
Ensure inter-service dependencies are well-mapped and understood
Deploying warm or cold standby's that can be activated in case of failures

All of these can be useful, but all come with risks, costs, and trade-off's. Standby's, even cold, are going to cost money, depending on the RTO/RPO required. Deploying solutions globally may not be possible, depending on infrastructure availability and data sovereignty requirements.

We're not just talking about Disaster Recovery or Fault Tolerance either - that's just the technology. These need to be incorporated within the holistic continuity of the business itself too.

Final Thoughts

Business Continuity isn't a simple topic. In fact there's a whole field associated with it. Even if you're not looking at developing a full Business Continuity Plan, it's worth looking at the basics of the topic for your organization, no matter your industry or scale.

Mitigating risks has costs, in both time and money. The question is whether a risk is likely enough to occur that it's worth the costs to offset.

AWS Data Engineer Associate Certification - Coming Soon

Stephen Sennett — Wed, 27 Sep 2023 04:14:36 +0000

The AWS Certified Data Engineer - Associate has been announced with the beta exam is opening in Q4 2023, with the final release due in Q2 2024.

Let's break down the new certification, analyze what it's going to look like, dig into what it means for AWS professionals.

📋 Knowledge and Skills Covered

AWS Certification Exams categorize skills and knowledge into distinct domains, each focusing on key concepts of the subject.

Here's a quick overview of some prominent services within each domain, providing insight into the certification's scope. They focus heavily on the Analytics service family, although it really does cover services across all steps of the data cycle.

Interestingly, AWS CDK and SAM are both explicitly mentioned. While CDK broadly addresses Infrastructure as Code, SAM is highlighted for its role in developing serverless data pipelines - a hugely underrated concept.

For more details, check out the DEA-C01 exam guide available from AWS.

🗺 Certification Pathway

This certification opens a new pathway to broaden expertise in AWS's data services; great news for those with data-centric backgrounds.

This serves as an ideal stepping stone for individuals without data backgrounds aiming to delve into advanced Specialty topics. Conversely, for data professionals, this certification provides an excellent opportunity to expand their AWS knowledge within a familiar context using specialist services they're likely acquainted with.

While it was always possible to acquire these skills without certification, the introduction of a structured pathway incentivizes learners to pursue certification and encourages training providers to fill the skill gap.

💻 No Practical Assessments

The AWS Certified Data Engineer - Associate exam reverts to the traditional Multiple Choice format, devoid of any practical hands-on assessment.

Since first introducing exam labs in 2021 for the SysOps Associate exam, AWS has temporarily suspended the lab component as of March 2023, pending changes to the platform.

This removal of exam labs is temporary while we evaluate the exam labs and make improvements to provide an optimal candidate experience. With this change, the exam will consist of 65 multiple-choice questions and multiple-response questions, with an exam time of 130 minutes.

This is disappointing, especially at the Associate-level where testing practical skills adds a lot to the value of a certification. But from experience with other vendors, a bad experience is far more damaging. Still, I am hoping we see this feature return in 2024.

📚 Preparing for the Exam

Right now in September 2023, there are no courses yet available for the exam since it's just been announced, although I'd expect some to be available around the time of the final release. The beta exam will be available soon, but I have a big tip:

Wait until after March 2024 to sit the exam.

Beta exams are notoriously tough and prone to issues. Plus, you have to wait for weeks or even months for your results. Unless you're a trainer or otherwise just extremely eager, it's generally wiser to wait for the final release.

Conclusion

Certifications are strategic tools for vendors, directing attention to specific subjects. Given the current data and AI landscape, an Associate-level certification focused on Data is a logical step.

However, AWS's persistent focus on role-based certifications at the Associate and Professional levels, such as "Data Engineer", is a point of critique. It might be more constructive to center these certifications around broader disciplines or knowledge areas. This approach not only lays a solid foundation for advanced skills but also minimizes confusion about job roles (looking at you, Solution Architect - Associate).

If you're considering furthering your AWS knowledge, this new certification is worth contemplating, and its creation is a positive move by AWS.

Sorry future-golden jacket holders.. But at least this has more universal relevance than the SAP Specialty 🙃

AI Coding Companions: My Experiences in 2023

Stephen Sennett — Tue, 26 Sep 2023 06:22:28 +0000

One moment, it's like having your thoughts magically transcribed into code right before your eyes. The next, it's like a monkey with a typewriter belting out the whimsical rhymes of Dr. Seuss. Welcome to the wild and surprising world of AI Coding Companion tools!

Over the last year, I've been using Amazon CodeWhisperer, GitHub Copilot, and ChatGPT in various ways to make my hacky coding easier and more effective. With that, I've condensed my experiences into some key reflections that have definitely made my life easier.

✅ Writing Boilerplate Code

One of the things AI solutions excel at can best be described as "making the boring stuff go faster". We're already familiar with this, but instead of going through the vendor docs or Stack Overflow, we can skip a few steps.

This is great for things like API calls (like writing out an S3 Object Upload call), writing out some logic flows, and a lot of the proforma that isn't necessarily challenging, but just takes time.

These suggestions can include errors which may not be immediately obvious. That isn't much of a problem when you're familiar with the topic, but when you're not...

❌ Handling Unfamiliar Concepts

Nobody is an expert at everything, but when writing code, you should definitely have some understanding of what you're trying to accomplish. AI tools let us shortcut this a bit, but it also magnifies the problems.

Recently I needed to build something with Python and FFmpeg. And while FFmpeg is amazingly powerful, it can also be incredibly complicated.

Trying to troubleshoot these errors was next-to impossible without knowing more about how FFmpeg actually worked, so I ended up going back and writing everything by hand. That said, even this process can be made easier.

🧠 Troubleshooting Code Issues

Writing code can be hard, and especially when dealing with new languages, you can just get things wrong. And surprisingly, one of the best tools to help with this has been ChatGPT.

Because of the extensive capabilities of the GPT4 model and the gargantuan corpus that powers it, ChatGPT is actually able to help pinpoint why some chunks of code didn't work as expected. Case in point, it was very helpful when I was trying to get some Flutter/Dart code working in an experience I posted about on LinkedIn.

Uploading a code snippet for a personal side project to ChatGPT isn't much of an issue, but it does speak to a lot of concerns that people have around one very major relevant topic...

🔐 Security Implications

Uploading highly sensitive code into an unknown API that is given full access to your hard work is unnerving, and does come with risks. Especially in the corporate context.

Amazon CodeWhisperer, GitHub Copilot, and ChatGPT can all be configured to prevent it from learning from your inputs (check the links for more info). And while you’re probably already trusting these organizations with storing your data anyway (especially AWS and GitHub/Microsoft), but the risks of it being given to other customers is where the danger lies.

Whether your organization deems the use of AI coding tools acceptable depends on a lot of factors (legislative, compliance, regulatory, etc.), but if there's PII or commercially sensitive information, I'd err on the side of caution.

🖊 Documenting Code

This was a surprising little gimmick. While we can use comments as placeholders for natural language to prompt the tool to generate code, we can also do the same in reverse too.

By starting a comment above a block of text, you can prompt the model to write a description of what the function is doing within the context of the file.

This... is actually pretty cool. It's not infallible, and so far they can only read within the context of the current file. But I could see this being useful in navigating an unfamiliar codebase.

😒 Fighting the UI

Integration with the IDE makes using some of these tools incredibly easy, but not always for the better. The autocomplete suggestions can be remarkably quick while writing code. Sometimes too quick.

Coding often requires a focused, uninterrupted thought process, and interruptions by autocomplete suggestions can disrupt that. Likewise, occasionally the multi-line suggestions will cause unexpected behaviour when navigating or manipulating the code you've already written.

These tools are great, but often it can be useful just to hit the Pause button for a while. Though I hope future updates can make these experiences more seamless.

Conclusion

Generative AI supported development is here to stay. It's an inescapable fact, and will continue to change the nature of the industry. It's not perfect, and can create its own headaches, but it's also very much worth exploring.

If you're tried some of these tools, share your thoughts in the comments! If not, I encourage you to give them a try.

Building a Serverless AI Content Detector

Stephen Sennett — Thu, 29 Jun 2023 02:10:46 +0000

One remarkable byproduct of the AI proliferation boom bought about by ChatGPT is the amount of AI-generated content out there on the internet. Recently I've found a need to be able to identify them at scale, so I decided to tackle two problems at once.

The AWS Community Builder Program's Machine Learning Team recently started a Hackathon around Generative AI and the Hugging Face Transformers Library, so this could be a fun experiment. If you'd like to know more about the program, check my other blog post.

So, I decided to build an AI Content Detection solution, and document my journey.

📦 The Solution

The goal was to build an API which could receive a text, and provide an analysis on whether it was likely to be written by a real human, or generated by an AI.

Additionally, I wanted to leverage a serverless architecture so I could easily embed it into a future event-driven solution, and to scale it effectively with minimal cost.

For the Hackathon, I also wanted to provide it as a synchronous API that could return a result in a reasonable period of time, so single-second latency was important.

With that, let's get into the journey of building this thing:

🤖 Part 1) Exploring the `transformers` library

First thing was to learn how the library actually works, and use it in a simple Python script. It was... amazing to get working. How simple?

from transformers import pipeline

pipe = pipeline("text-classification", model="roberta-base-openai-detector")

print(pipe("Hello! I'm ChatGPT, a large language model trained by OpenAI. I'm here to assist you with any questions or information you may need. How can I help you today?"))

...I gotta say, I'm impressed how the transformers library abstracted away all of the stuff with tokenization, inference, and pytorch. Once the libraries are installed, it's a breeze to work with. Success!

🔨 Part 2) Getting `transformers` into Lambda

AWS Lambda excels natively with many different workloads. Machine Learning inference isn't one of them... Between the libraries and model totalling up into several gigabytes of dependencies, we can't exactly just toss it all into a ZIP file. At that size, even Lambda Layers aren't going to cut it.

First I thought I could use some sneaky-jutsu by building a ZIP file of the packages which I could host on S3. At initialization, I'd use the increased ephemeral storage capacity to download and unzip the package.

But that didn't work quite so well. Between some issues with the packages, and the amount of time it took to unzip... it just wasn't worth it. So I refactored back into using EFS to host the packages and model files.

This did mean I needed to build a whole VPC to come along for the ride. Really just writing a bunch of extra resources for the SAM Template and some minor costs like a NAT Gateway. Still, building a whole VPC just to make a Lambda function run better isn't ideal.

There's always some reason to keep VPC's...

⚡ Part 3) Orchestration with Step Functions

Since I want to extend the functionality further, I chose to build this around a Step Function Express Workflow to orchestrate the solution.

Okay fair enough, that's not very interesting. Instead, let's make this smarter by adding some caching functionality. API Gateway does have caching, but we want to do something more ambitious than just simple strings.

By keeping our individual Lambda functions short and single-purpose too, it also makes it far easier to rip out components and replace them. With the native integration of the AWS SDK, working with DynamoDB is incredibly easy too.

Getting API Gateway to perform a synchronous execution also doesn't integrate quite as smoothly, but one of the articles in the Serverless Land Pattern Collection solved that.

🌐 Part 4) Downloading whole pages

Analyzing individual strings is nice and all, but let's make this thing more powerful - I want to be able to give it a URL, and let it go do it's thing. So we just get requests to download it, bs4 to strip the bones off, and viola, we have a page! Easy days...

Umm, okay - maybe this is a bit more complicated after all.

Webpages have a lot of elements, and not all of it is relevant. After some poking, I've stripped it back just to look at the contents of the <article> tags. This could be made to support custom targeting with parameters to the request, but didn't have a particular need in this case. But there are other problems.

The model can only handle up to 512 tokens at once, which is a bit of a challenge. Splitting up the payload to be processed in reasonable sized chunks that processed to produce meaningful results was surprisingly hard. No joke, I rewrote the damn thing about a dozen times, and it made me deeply question my skills.

Eventually, I came up with a solution that mostly works. Using the RoBERTa tokenizer and breaking it down per line works pretty reliably (don't check the TODO I left behind in the code).

Also, first time using Amazon CodeWhisperer on a full project too, and it was a helpful little thing!

👀 Part 5) Observability & Optimization

So, everything's done and working now, right?! Sure!

Except for one problem... It takes quite a while to run. Like, stupidly long execution times, even for simple workloads.

In my eventual use case, this is minor since it'll be run asynchronously, and can take as long as it generally pleases. But that's not as great for our synchronous demo API. So it's time to enable AWS X-Ray to run the distributed tracing over the whole thing.

No surprise, but our detection function is a pure chonk (technical term), and slow as hell - especially in initialization. The invocation itself is actually relatively quick.

There's many ways to tackle this problem. After a few hours looking at the underlying code, tuning the resourcing, and exploring the possibility of implementing my own snapshot system (roll on SnapStart for Lambda), I settled on one solution...

Provisioned Concurrency means AWS will keep several instances of the function warm and ready for invocations, bypassing the slower start times. Along with Reserved Concurrency setting an upper-limit, we shouldn't hit any bottlenecks caused by long init times.

This does come with a much higher cost, but for this case, it's a worthwhile trade-off. Eventually Lambda SnapStart for Python would let me work around easily being a stateless workload, but for now I'll work with what I have.

💪 Try it yourself!

The API is available for use at the path below!

https://hackathon.api.ssennett.net/run

If you'd like to try it out yourself (including the curl/Powershell commands), or even fork your own copy, check out the code on GitHub under my serverless-ai-content-detector repository.

✨ Building a Custom Model

The roberta-base-openai-detector model isn't infallible, which they make explicitly clear in their model card. It was also trained on a dataset by GPT-2, which while being a technological marvel is also relatively old as hell, while the globally proliferous ChatGPT runs on GPT-3.5 and GPT-4.

I did try building my own model on RoBERTa using Common Crawl and the open-source Falcon-40B model, but it just wasn't reliable enough to warrant implementation. Not for lack of trying though:

Thank goodness for free AWS credits 😅

🎉 Conclusion

In the end, this is a high-level of the solution I ended up with:

This was a really fun project to build.. The Hugging Face Transformers Library was surprisingly easy to use, and once I got over the hurdles, it was a breeze to use with native AWS Services.

Nothing will ever detect AI generated content with complete reliability - that's a fact of the modern world. But this kind of solution can drive signals for us to investigate.

Let me know in the comments if you end up trying it out, and how accurate the prediction was!

Developers Journey to AWS Lambda

Stephen Sennett — Sun, 09 Apr 2023 13:25:56 +0000

AWS Lambda has a surprise learning curve. You create a new function, write your code, and it executes. Easy, right? Then you discover just how deep the rabbit hole goes. Deluged by so many topics, it's hard to know where to go next.

By this point, you've started using Lambda, but have now fallen off that mountain. In this post, we'll break down five steps to get you moving along your Lambda journey.

1) Improving your Code

AWS Lambda seems simple enough - write whatever code you want, and it runs it. That's true, but not all code is created equal, and there are some important ways to elevate your code in Lambda functions.

Foundational to using AWS Lambda is understanding the execution environment it uses so we that can understand behaviour like cold starts, and how our code impacts them.

The Best Practices for AWS Lambda is an excellent read, but to highlight the most significant points about code:

Remove your logic from your handler

Keeping your code as simple as possible removes headaches. When we start writing Lambda functions, they get lengthy, and we may keep them in the handler function.

This complicates our testing since our unit testing is inextricably linked to how our function is invoked. Use your handler function to control interactions with other solution components, while your business logic is held in separate functions within your code.

import requests

def check_inventory(check):
    response = request.get('http://apiurl/inventory')

    if check in response.text:
        return True
    else:
        return False

def lambda_handler(event, context):
    data = check_inventory(event['itemId'])

    return {
        'statusCode': 200,
        'body': json.dumps(data)
    }

In this case, the logic for checking our inventory can be tested easily, regardless of how it's integrated into Lambda. Likewise, our handler focuses solely on how to pass the information to and from the business logic, making it easier to maintain. This is a very basic example, while AWS Chief Evangelist EMEA, Danilo Poccia has a brilliantly succinct gist, GreetingsAPI.js, that shows a more complex integration

Configuration outside code

Trying to handle configuration inside of our code is always a horrible mess. How many times have you made code that looks something like this?

# apiUrl = "https://prod.my-tenant.customersystem.net/v2/res/item"
apiUrl = "http://127.0.0.1:3000/mock"

Or even worse...

apiToken = "QmFzZTY0IGlzbid0IHJlYWwgZW5jcnlwdGlvbg=="

Okay yeah, me too... ✋ Fortunately, AWS gives us a few options to get around this with Lambda.

Environment Variables are familiar to most developers and work identically between your local machine and AWS. But for anything secure, or that needs to be used across multiple Lambda functions, it's worth checking out AWS Systems Manager Parameter Store, AWS Secrets Manager, or AWS AppConfig. It removes many future headaches, and helps your security team sleep at night.

Leverage environment reuse

When a new instance of your function is spun up, the Init phase will run any static code outside of your functions.

If you need to perform any long-running tasks before handling requests, or instantiated before receiving requests, this can make your code much more efficient. Make the most of this where you can, making things quicker for your end users.

import pymysql

try:
    connection = pymsql.connect(<DetailsGoHere>)
except pymysql.MySQLError as e:
    logger.error(e)
    sys.exit()

def lambda_handler(event,context):
    with connection.cursor() as cursor:
        cursor.execute("SELECT * FROM USERS WHERE userId='" + event['uid'] + "'")
        data = connection.fetchone()
        return data

Ensure that data leaks don't occur between invocations when handling stateful data. And even though something has been instantiated, there should still be checks, especially for database connections, to ensure they're still alive.

AWS Serverless Hero Jeremy Daly's article on Reusing Database Connections in Lambda from 2018 covers the concept well, although new options are available for database connection management.

2) Leveraging CI/CD and Frameworks

If you're still editing and saving your code live in the AWS Console, chances are you've run into this situation:

It's 2023, so you already know why you should be using a CI/CD Pipeline. But you can spend more time building and troubleshooting your pipeline than actually writing valuable code. And that's just for deploying one simple Lambda function.

Fortunately, we have many frameworks and tools to help us build and deploy our serverless solutions. Each Framework has different strengths, but all aim to reduce the friction between development and deployment.

AWS SAM (Serverless Application Model) smooths the deployment of serverless applications for AWS
Wing has built an entire language around cloud-native primitives that compiles it into another provisioning provider (currently only Terraform)
Serverless Framework is the original framework for building serverless apps, and still a solid choice
Ampt is currently in private beta, but is going deep into building a fully integrated developer platform. I'm excited about what this means for developer experience!

If you're familiar with CloudFormation, I'd suggest AWS SAM as a starting point. Once Ampt exits private beta, I will start to experiment with that.

3) Easy Observability with PowerTools

We're all guilty of using print('boop') or console.log('hi!') for debugging. This doesn't scale well in Production though. Implementing custom logging for the myriad of outputs, plus generating and handling custom metrics, involves a whole mess of extra work. Not to mention supporting distributed tracing.

Enter Lambda PowerTools - a solution that takes only a few minutes to install in your code, and makes it incredibly easy to handle your logging, metrics, and distributed tracing, all familiarly handled in your language of choice.

Observability is the difference between your solution being a big box of production mysteries and a brilliant symphony of many working parts where you can understand and address issues proactively. This is the single most straightforward and significant uplift you can give a serverless application in AWS.

Highly recommend checking out the Tutorial for Powertools for Python, which covers both Powertools, plus some AWS SAM as well!

4) Tweaking your Deployment

"Any sufficiently advanced technology is indistinguishable from magic" (Arthur C. Clarke). Lambda is an advanced and powerful technology, and its magic has created some common misconceptions.

Lambda will scale your functions infinitely
Lambda execution environments will start immediately
Lambda changes everything immediately when you update your code
Lambda will use as many resources as it needs

Let's take a closer look at how we can configure our Lambda functions.

Function Scaling with Reserved Concurrency

Lambda does have a scaling limit. By default, that number is 1,000 concurrent executions per account. Since all Lambda functions in your account share that concurrency limit, you can reserve a maximum amount for each function with Reserved Concurrency.

Reserved concurrent can also be used to set those upper limits to prevent overwhelming downstream services that your Lambda function may be sending requests to, like API's. After all, your local coffee shop with a single barista could handle infinite orders. That is if you are okay with waiting an infinite amount of time for your coffee.

You can request quota increases for your account's concurrency limits - but it's worth considering other limitations first.

Cold Starts and Provisioned Concurrency

We know from our exploration of the execution environment that Lambda doesn't start new execution environments immediately - it takes time to spin them up through their Init phase. Provisioned Concurrency is how we can ensure that a minimum number is ready for use at any time.

It might be tempting just to use Provisioned Concurrency to work around cold starts, but there is one huge drawback: it's not cheap. Having execution environments on standby incurs an ongoing cost of about 25%. This sounds cheap but it adds up quickly.

A Lambda Function with the standard 512MB memory and 10 provisioned concurrency instances running adds up to about $54 USD per month. That's without even adding the costs of each request and their running compute time. It's always worth optimizing before jumping to Provisioned Concurrency.

Managing Changes with Versions and Aliases

One of the great things about Lambda is quickly updating your code and having it reflected in your Production compute environment. That's great, but often you need a bit more control. This is where versions and aliases come in.

Lambda has built-in versioning capabilities. When doing live editing, you're working with the $LATEST version. Creating versions lets you lock your code to a specific state, which can be executed independently by its unique ARN.

Aliases take this to the next level, where you can have a dynamic reference to a particular function version. If you had an alias for prod, this could be the target of your invocations from your API Gateway. When you've finished testing a new version, you can just update the alias to point to the updated version instead of updating your API Gateway.

Tuning your Resource Configuration

You've probably seen the concept of a GB-second mentioned in the Lambda pricing. Essentially, you get charged based on how long your Lambda function runs, and how many resources you give it; and despite being named a "GB-second", the memory also directly relates to the apportioned CPU and network resources.

The more memory you allocate to your function, the faster it works. But the more memory you allocate, your cost also increases. So it's worth finding a sweet spot between memory allocation and function duration. As a general rule:

If you're performing lots of calculations, allocate more memory
If you're waiting on external calls, allocate less memory

The AWS Documentation's Memory and Computing Power page is a good starting point. To avoid configuring it manually, it's worth checking out AWS Lambda Power Tuning, which will help you find the sweet spot.

5) Architecting for serverless

By this point, your AWS Lambda skills have matured enormously. But there's still much to learn in the world of serverless computing. There are a lot of places to get started, so I'd suggest checking out some of these awesome videos from AWS re:Invent 2022

Get started building your first serverless, event-driven application (SVS209) by Emily Shea
Building next-gen applications with event-driven architectures (API311-R) by Eric Johnson
Building Serverlesspresso: Creating event-driven architectures (SVS312) by James Beswick

These give you a much deeper exposure to the development and architecture of serverless solutions. Since you already know Lambda, it's far less about the code, and more about the patterns and architectures.

Wrapping-up

The learning with Lambda does not stop here. There are still many areas of the service and development to be further explored! You can find answers to almost any problem between the Developers Guide and Operators Guide. AWS has made it truly possible to become an expert at their services by being able to navigate their documentation, and Lambda is no exception.

To dive deeper, check out some of the fantastic content on the AWS Events YouTube Channel, with dozens of incredible talks from re:Invent across all serverless topics. You don't need to spend thousands of dollars to learn from industry leaders, and they are truly worth exploring.

Lastly, check out more of the content published by members of the AWS Community! You can bet that whatever you're building, someone has done something similar before.

Keep safe, and happy clouding!

AWS Melbourne Region - Launch Analysis

Stephen Sennett — Tue, 24 Jan 2023 00:46:20 +0000

Local AWS Melbournians woke up to some exciting news today with the long awaited launch of the new AWS Melbourne Region (ap-southeast-4)!

The official announcement has lots of general information, so I'm going to focus in on some of the more technical implications for builders.

Special credit to AWS Melbourne User Group Leader Arjen Schwarz who picked up on it a few hours before the official announcement!

Grab your fancy latte, and let's get started ☕

👍 Benefits of a New Region

Using new regions requires a lot of work. Beyond simply enabling the new region, we need to extend our architectures, deploy our infrastructure, and do a lot of testing before bringing a new region to production.

So, what's the upside? Well, there are two major ones:

🏃‍♂️ 1) Performance

We want our services to be as close to our customers as possible to enable better performance. When new regions (or local zones) come online, we leverage them to achieve single-digit latency.

After first discovering the S3 endpoint coming online back in November 2022 (they bring the DNS records online early), I'd started to run some simple ping tests from my home in Melbourne to get a general idea of latency. This is the result (dumping to a text file meant no date numbers for the X-axis - oops!):

If you have a significant customer base in Melbourne, especially for latency-sensitive applications, this is very useful. We have had Edge Locations in Melbourne for a while, so if you're using solutions like CloudFront or Lambda@Edge, this doesn't change much.

💪 2) Resilience

Multi-regional architecture is a big selling point for the cloud. We can deploy our solutions to be way more resilient, building across large geographical areas and minimizing the effect of major outages.

Data Sovereignty and other requirements usually mean we need to keep our data in a single country, or group of countries. For Australia, Microsoft Azure has had multiple local regions for nearly a decade. This has given Microsoft a significant advantage in Australia for companies that really crave this resilience.

Architecting for multi-region resilience isn't easy though, and it requires effort to get right, and comes with additional costs. But if you're needing that additional assurance, it's worth checking out. The recently released AWS Multi-Region Fundamentals Whitepaper is an excellent resource to get started.

☑ Service Availability

New regions always start out with a smaller subset of services, before adding additional support over time.

As of launch, AWS has 47 services running in the new Melbourne region. This compares with 194 in Sydney (ap-southeast-2). All of the standard services you'd expect are there, with EC2, Lambda, S3, DynamoDB, and the like. But there's many services still missing. Here's a short list of some key ones:

Some services also aren't fully featured yet, like AWS Lambda lacking support for the arm64 architecture powered by Graviton yet.

If you're extending your solutions from another region like Sydney, this might not be a problem. But the current lack of some services like Transit Gateway may slow down many customers looking to extend their operations across the regional divide.

For the full comparison of supported services at time of launch check out my Google Sheet for more information.

🖥 Instance Family Availability

As with services, so too with Instance types. Having a newer region means we're dealing exclusively with newer hardware, so you may not have access to the same instance types as you're expected.

Obviously we're not getting our beloved t2.micro's back (😥), but this is an opportunity to update to the latest instance (and usually cheaper) types as well. Given the list, most types of workloads can be accommodated. Though, there's a few omissions.

The biggest gap I notice is there's currently no GPU-powered Accelerated Computing instances available. Aside from the m6gd family, we also don't have many Graviton-powered instances yet (explaining the situation with Lambda).

The AWS Management Console will only show you what's available, so don't worry too much there. But if you're deploying solutions with an IaC solution, keep an eye out for any weird deployment bugs with your compute solutions where the instance family may need to be changed.

The Google Sheet also contains a list of the all of the supported instances compared against the Sydney region.

🎉 Conclusion

One thing should be clear: The launch of the Melbourne Region is a really good thing. There are some gaps, but that's because it's a new region, and these things take time to roll out.

Keep an eye on the AWS news as they announce the new releases; it'll pick up pace now that the region is online. Start your planning now, and you can take advantage of these new capabilities once they're available.

GPT-Powered chatbot over the phone - Try it, and see how it was built

Stephen Sennett — Fri, 23 Dec 2022 07:18:21 +0000

ChatGPT has sent the internet into a frenzy. For developers, it's just the tip of the iceberg. OpenAI's API allows us to leverage the power of the GPT Models in as many ways as we can imagine.

Today, I hacked together a cutting-edge AI chatbot that you can call from any phone, anywhere in the world. What's more, you can try it yourself! See the end of the article for more details.

🗺 Architecture

Amazon Connect is a powerful solution that lets us set up a phone number, build contact flows, support call centre agents, and everything in-between. It's not exactly a leader in this space, but it's smooth integration with other AWS Services makes it a breeze for this scenario.

Amazon Lex, AWS's natural language conversational AI service. With Amazon Connect, it seamlessly leverages Amazon Transcribe to understand what is being said (speech-to-text), and Amazon Polly to provide the verbal response (text-to-speech). We aren't really using the Natural Language powers of Lex, but it has other uses for us:

AWS Lambda handles the call to OpenAI's API. The function itself is quite simple, although the supporting Lambda Layer was significantly larger. Since OpenAI's API costs money, I've leveraged AWS Secrets Manager to keep my API Key secure. To make debugging less nightmarish (we'll see why!), Amazon CloudWatch provides a simple way to store my basic log files, and Amazon API Gateway gives an ability to retrieve them!

🛠 Deep Dive into Services

Knowing the architecture is great, but it doesn't help build everything out in detail. Let's dive into some of those services in some more depth:

☎️ Amazon Connect

Connect is a powerful service, but it can feel counter-intuitive if you've never managed a virtual contact centre before (lucky you!). Like Quicksight and a few other services, Amazon Connect has its own control panels outside the AWS Management Console.

First, you need to setup your Amazon Connect instance in your chosen region. You'll need to setup a DID number (Direct In-dial number; fancy word for your inbound phone number) for a country of your choice, but make sure it's available in your region on the Connect Pricing page, and that you meet any necessary regulations.

Building your Contact Flow is the cool stuff happens. You can use the editor to build out a workflow that meets your needs in a huge number of works, including logic, prompts, and an ability to trigger Lambda functions, making it hugely extensible!

💬 Amazon Lex

Lex (v2) is an immensely powerful service for building natural language experiences. The name isn't a coincidence either, since it also powers Amazon Alexa. But we aren't using any of those features; it's just a convenient way of handling the processing between text and speech with our Lambda function! Lex developers, look away now!

After we create our bot, we need to configure it. Normally we would create multiple intents, with their respective utterances. Instead, I create a single intent (I called it campingInTents, because childish humour) with a random utterance (pancakes; I was hungry). Neither mattered in this case, since both the created intent and the default FallbackIntent are going to be doing the same thing.

After enabling the Lambda code hooks for initialization, and configuring the bot to use my Lambda function, it will always behave the same, sending the message through to OpenAI, regardless of what's been said. This is an incredibly hacky way of doing it, and I'm sure there are many better ways. But I'm a hacky dev, building a hacky solution today.

🧠 AWS Lambda

Lambda functions are best when kept simple. This one sends the request to OpenAI, outputs some information for logging, and passes the information back to Lex. More info about the code down below.

Since it relies on an external API call, it does take a while to execute (1.285 seconds on average), which is very inefficient, and despite throwing Lambda Power Tuning at the problem, it's purely an external dependency issue, and can't be resolved by resources. You could make it more cost-effective using AWS Step Functions to handle the OpenAI API call asyncrhonously, but I didn't worry for this project.

The openai-python library makes interacting with the API a breeze. Although at 112MB fully installed, including requests, numpy, and pandas, it's pretty beefy. Consolidating it into a Lambda Layer made it simple and easy to manage. numpy didn't appreciate running in Lambda after being loaded for my Windows machine, so you may need to specify the right package before building the layer.

After some incredibly nonsensical replies to my queries, I added some basic logging which is output to CloudWatch logs. The reason is that Amazon Transcribe is ~~awful~~ still leaving a lot to be desired, especially with my accent. So, I wanted to capture what Transcribe thought I'd said, leading to some interesting insights. This has to be my favourite:

What I said:
What's the key difference between Alexander the Great, and Julius Caesar?

OpenAI's Response:
The key difference between Alexander the Great and Reseda is that Alexander the Great was a Macedonian king and conqueror who reigned from 336-323 BC, while Reseda is a city in Los Angeles, California.

What Transcribe thought I said:
What's the key difference between alexander great enjoy reseda

⏱ How much coding?

For a fully-fledged chatbot which comes close to passing the Turing Test, powered by some of the most incredible AI models in the modern age, that runs on the worlds most ubiquitous communication medium, surely there'd be some pretty significant coding required.

Just 49 lines of code. That's all of the Python code, including comments, which I had to write for Lambda to make this work, all available on GitHub. Everything else was configuring the existing services. In fact, it can be compacted down into less than 10 lines of code, though substantially harder to read.

Modern solutions built around cloud computing, microservices, and API's means you can leverage a surprising amount of power by simply tying solutions together. Reading the code, there's virtually no custom logic involved, except for the prompt. Everything else is arguably just glue code.

On the pricing dimension, it costs all of 9.7 cents per invocation, which is pretty impressive.

📞 Try it for yourself!

Here we go, the US phone number that hosts the chatbot. OpenAI is expensive, so this will disappear eventually when either it runs out of credits, or gets excessively misused. Give it a try, but be reasonable!

~~+1 (445) 202-5802~~

Update: Number has now been taken down

It does take several seconds for the API to return the response, so don't be surprised if it takes a little while.

Stay safe over the holiday season, and best wishes towards 2023!

Troubleshooting AWS Application Composer Errors

Stephen Sennett — Wed, 21 Dec 2022 02:29:27 +0000

AWS Application Composer was released to Public Preview during re:Invent 2022. The Developer Guide Documentation covers the basics of how to use the service, but currently there's limited guidelines on troubleshooting bugs.

When loading an existing SAM Template, the following error may appear:

Incompatible template
An incompatible or malformed template has been detected, which means it is not accessible in Composer. Load another file.

The front-end provides no further details, but they are output into the browser console. For this error, the INITIALIZE_PROJECT_FAILED event offers insight:

My error appeared to be related to the concurrent release of Step Functions Distributed Map, which changed some language definition in ASL around the Map state, and may not yet be reflected in App Composer's validator.

AWS Application Composer is still in Preview, which means it's still undergoing active development, and things constantly shift about in AWS. If you find a similar error, it's worth sending feedback to the Service Team using the link in the AWS Console.

AWS Serverless Badge: Value and Potential for Cloud Professionals

Stephen Sennett — Sat, 10 Dec 2022 04:43:39 +0000

During re:Invent 2022, AWS announced the release of their new AWS Serverless digital learning badges. For context, Digital Badges are issued as part of the AWS Skill Builder platform as part of completing an assessment at the end of a learning path. Similar concept to certifications, except that they're free to attempt, and aren't proctored.

Having experience with serverless tech and having previously written about the need for an AWS Serverless-oriented certification, I sat the assessment, and now it's time to share my thoughts.

Process

The badge comes as part of the Skill Builder Serverless Learning Plan, where you can either start at the beginning with the courses, or jump straight ahead to the Serverless Learning Plan Badge Assessment.

The assessment has 50 questions, and no time limit. Score to pass is 80% (40 questions correct), with a one-day waiting period to retake the assessment if you fail an attempt. Upon passing, you'll receive a link to your Credly badge within up to five days, but in my experience, it's usually within one business day.

Difficulty

The difficulty level would be similar to an Associate-level ceritifcation, with substantial overlap with the AWS Certified Developer Associate certification.

The Learning Path seems to cover all of the topics you'd need to pass the assessment, so even if you don't know all the answers yet, you can find them between the courses and the AWS Documentation.

Badges vs Certifications

The main difference between a Digital Badge and a Certification is that the assessments for Badges are not proctored. Where a Certification Exam must be taken within a controlled environment, like at a testing centre, or under very strict conditions at home, the assessments for Badges can be undertaken in your web browser, without restrictions or time limits.

Since there's no restrictions, the candidate can research any answers for the Digital Badge assessment, like an open book exam. This means the candidate doesn't need to prove their knowledge in the same way as with a certification exam.

Being able to reference documentation is a critical timely skill. But that doesn't count if and when brain dumps of the assessment begin appearing online, and people use them to bypass the need for knowledge entirely.

Worth it?

It's a great starting point both as a personal benchmark for your own knowledge, and a means to show employers that you're deeply interested in serverless technology. For Hiring Managers, take it as a good sign that there's a baseline level of knowledge, and that the candidate has been interested enough in the topic to pursue it.

Digital Badges have been around for nearly a year, with the first ones being released in February 2022. More people are taking them up, but it's still slow going, and with a limited range of topics. I believe the Serverless Digital Badge is the first one that will see more consistent adoption.

Have you sat the AWS Serverless Badge assessment? What were you impressions?

Viewing Cost Explorer Usage with AWS Credits

Stephen Sennett — Tue, 21 Dec 2021 08:54:41 +0000

When you have AWS Promotional Credits applied to your account, by default your usage will be hidden from the Cost Explorer.

AWS Cost Explorer is primarily concerned with showing you what the impact is to your billing & payments. Since Credits have already been applied to your account, you don't need to pay for it in an upcoming invoice.

Some charges for Ineligible Services not covered by AWS Promotional Credits may still show up, like Domain Registration, upfront RI costs, etc. For the rest, you'll need to change the Cost Explorer filter.

To show all usage in your AWS Account, including those covered by Credits, select the filter on the right-side of the Screen for Charge Type, change it to Exclude Only, and check the box for Credits.

Once applied, all charges on the account will be visible. Including any that may have been forgotten.

Just an alternative education expensive.

DEV Community: Stephen Sennett

Does Scale-to-Zero Redefine Aurora’s ‘Serverlessness’?

🖥️ What is Aurora Serverless v2?

👻 Defining "Serverless"

⚙️ How it Works

👀 Caveats

🥶 (Very) Cold Starts

🧪 Experimenting with WordPress

🤔 Conclusion

GenStack - Bring PartyRock apps to your place

🚦 How it Works

🧠 How it REALLY works

🗺️ Defining the Application

🎨 Styling

🌆 State Management

🛠️ Building the Builder

🐌 Limitations

🫵 Wrap-up

The Optus Outage: Business Continuity Lessons for Organizations

What will fail?

🤖 Technological

⛈️ Natural

🤷 Humans

What happens when it fails?

What should we do when it fails?

💳 EFTPOS Terminal Failure at Local Café

⚠️ Cloud Outage at Global SaaS Software Provider

Final Thoughts

AWS Data Engineer Associate Certification - Coming Soon

📋 Knowledge and Skills Covered

🗺 Certification Pathway

💻 No Practical Assessments

📚 Preparing for the Exam

Conclusion

AI Coding Companions: My Experiences in 2023

✅ Writing Boilerplate Code

❌ Handling Unfamiliar Concepts

🧠 Troubleshooting Code Issues

🔐 Security Implications

🖊 Documenting Code

😒 Fighting the UI

Conclusion

Building a Serverless AI Content Detector

📦 The Solution

🤖 Part 1) Exploring the transformers library

🔨 Part 2) Getting transformers into Lambda

⚡ Part 3) Orchestration with Step Functions

🌐 Part 4) Downloading whole pages

👀 Part 5) Observability & Optimization

💪 Try it yourself!

✨ Building a Custom Model

🎉 Conclusion

Developers Journey to AWS Lambda

1) Improving your Code

Remove your logic from your handler

Configuration outside code

Leverage environment reuse

2) Leveraging CI/CD and Frameworks

3) Easy Observability with PowerTools

4) Tweaking your Deployment

Function Scaling with Reserved Concurrency

Cold Starts and Provisioned Concurrency

Managing Changes with Versions and Aliases

Tuning your Resource Configuration

5) Architecting for serverless

Wrapping-up

AWS Melbourne Region - Launch Analysis

👍 Benefits of a New Region

🏃‍♂️ 1) Performance

💪 2) Resilience

☑ Service Availability

🖥 Instance Family Availability

🎉 Conclusion

GPT-Powered chatbot over the phone - Try it, and see how it was built

🗺 Architecture

🛠 Deep Dive into Services

☎️ Amazon Connect

💬 Amazon Lex

🧠 AWS Lambda

⏱ How much coding?

🤖 Part 1) Exploring the `transformers` library

🔨 Part 2) Getting `transformers` into Lambda