Building apps from the "inside out"

Jeremy Mason — Sun, 23 Aug 2020 05:26:38 +0000

Before I begin, I want to give credit to the following post for my inspiration. If you have a few minutes, I highly recommend you check it out:

https://dev.to/afonsopacifer/how-you-can-stay-motivated-to-work-on-personal-projects-565a

We've all been there... you're performing a routine task, or staring at a spreadsheet or database, and suddenly, it hits you. You think to yourself, "If only I had a way to... [insert idea here]" - and from that point on, your whole day is ruined. It's just like the description in the movie "Inception" - you're consumed by the seed of an idea - every time you perform that same task, you're distracted by the notion that there's a better way. Not only that, you think others might have the same problem you do, and you should build an app to solve it for you (and everyone else).

So, what now?

If you're like me earlier in my career, you start mapping out the steps, and you start building out the app in your head from left to right. First, you need a login screen, but before that, you need a way to track users. Before you can do that, you'll need to pick a framework, do you use raw Express, or pick up something new like Nest.js? What about the front-end, React of Angular? REST API or GraphQL? ... and where will I deploy it? Do I bother with CI/CD, or just ship it?

Before long, fatigue starts to set in, and you haven't even started yet. You decide to put the idea back on the shelf, along with a dozen other ideas you never really started.

So, what went wrong?

This is a trap I call building from "left to right" instead of from the "inside out". It's a trap I fell into many times, which forced me to change how I approach these moments of inspiration.

The Answer

Now, when I feel this itch, I focus on the thing that caused the inspiration in the first place. Then, I build just enough to scratch the itch, which might just be to load a spreadsheet into a database and run a simple query, or create some custom visualization to display the data in a new way. Whatever the reason, I just focus on scratching the itch. Then, once the itch has been scratched, I can take a step back and ask myself, "How motivated am I to continue?"

If the answer is "not very", then I can walk away with a sense of accomplishment, but also a sense of relief that I just saved myself hours of building an app I didn't really want to build. I recommend taking a few extra hours to share what you've built so others can benefit, which might come in the form of a new GitHub repo, a new website, or just a post to share with your friends or co-workers. Not only will others be able to benefit from your hard work, but it will also maximize the sense of satisfaction you get, making it easier to start on the next one.

On the other hand, if I'm not ready to let it go, I can keep going, focusing on the next itch, and the next one, until I run out of things to do. Then, I wrap it up and move on with nothing but a smile on my face.

Summary

Before we wrap up, I want to take a moment to compare this process of "scratching the itch" to what Agile enthusiasts call the Most Viable Product (MVP). Oftentimes, when designing an MVP, we still get caught up in all the "must have" details like a login screen, user management, along with a laundry list of other not-so-exciting features.

This approach of building apps from the "inside out" works great for side projects because our time is valuable, and we don't want to waste it, but I encourage you to bring this same mindset to your next design meeting. Because when it comes to your work, your time is still valuable.

For more ideas on how to avoid this trap when building new products, I recommend reading the Innovator's Solution by Clayton Christensen. This books provides some great examples from companies that have had huge success starting small, failing fast, and adapting quickly.

Do you have any tips on how you stay motivated working on side projects? Please leave your thoughts in the comments!

Using sub-accounts in AWS

Jeremy Mason — Sat, 22 Aug 2020 05:15:09 +0000

Overview

There's a lot of best practices when it comes to cloud computing, and they seem to change almost daily. I'm here to tell you about one simple change that can have a huge impact.

AWS Organizations is a service provided by AWS that allows you to partition your cloud resources across multiple accounts, and organize them by "Organizational Units" (OUs). We'll discuss later the finer points of OUs, but more importantly, this service also allows you to create multiple sub-accounts that roll up under a single "master" account.

While there are many reasons why you might choose to partition resources across multiple accounts, here's a few that come up most often:

Security / Authorization

By separating resources into different accounts, it is easier to apply Principle of Least Privilege (POLP) across AWS resources by granting Developers and QA access to non-production accounts for development and testing without risking exposure to production data.

For example, let's say you host a web application in AWS, using resources such as EC2 instances, Lambda functions, RDS databases, S3 buckets, etc. You want to empower your team by granting them full access to AWS for a shared development environment. However, you also want to reduce the risk of a human or script accidentally making changes to the production environment that could result in downtime or data loss. You could create fine-grained policies, that only allow developers to perform actions on specific resources, but that will require constant maintenance as the environment changes over time.

By using separate AWS accounts, you can move the development environment to a separate account, and simply create a "SuperUser" or "Developer" role that grants full access to any services relevant to your system, knowing that this policy will be limited to only resources within the sub-account, so team members cannot accidentally make changes to the production environment.

Cost Management

AWS provides multiple resources to manage costs, including AWS Trusted Advisor, Cost Explorer, the AWS Calculator for estimating costs, and pages of documentation detailing how costs are calculated for individual services. Despite these resources, it can be still be very difficult to predict or track monthly usage and costs across your environments.

Using AWS sub-accounts, it is really easy to track costs across different segments, depending on how you've partitioned your accounts. Using the AWS Cost Explorer, you can use Linked Accounts to apply Filters or Group By operations to see how costs are distributed across your account. This makes it trivial to see how different workloads compare month-to-month so you can quickly spot anomalies.

For example, let's say you want to spin up a new website as part of a campaign your company is running for a new product. You will host the site on an EC2 instance with a MySQL instance running in RDS, and a CloudFront distribution. When you launch the application, you misconfigure your retention policies, resulting in a "trickle up" effect as you continue to pay storage fees for stale snapshots and log data. If you deploy this configuration alongside other resources, it would be really difficult to determine which costs are associated with your new website, and which are coming from your other products. However, by creating a new sub-account, you can see really easily how your usage costs change over time, including the upward trend caused by the unnecessary storage, and quickly make changes to fix the issue.

Organization Units

So far, we've mostly been talking about the benefits of multiple accounts and how they can help organize workloads within AWS so you can manage them effectively. Next, we'll discuss briefly the concept of Organization Units (OUs) and how they can provide an extra layer of administration on top of your sub-accounts.

Simply put, OUs allow you to add structure to your AWS sub-accounts. You might choose to create OUs, to group accounts by:

Company / Subsidiary
Department
Product / Line of Business
Environment (Production vs. Non-Prod)
Customer

OUs are more than just a visual aid to organize accounts into groups, they also allow you to apply policies to all accounts assigned to the OU. For example, you might create an OU for all "production" accounts, and apply a policy that restricts the ability to disable or modify AWS GuardDuty for those accounts.

Considerations

Before you go tell your boss that you want to migrate all your resources to sub-accounts, there is one important thing to consider first. Sharing resources across accounts can be a bit tricky. In general, support for this continues to improve as the use of multiple accounts becomes more widespread, but in my experience, it requires a non-trivial amount of effort to configure resources that must be shared across accounts.

If this is something you need to support, such as storing artifacts in S3, or deploying containers from a single ECR registry, you should take a moment to review how to achieve your objective across multiple accounts, in case the solution turns out be more complicated than you anticipated.

Summary

Prior to AWS Organizations, we used Tags and other tricks to try to keep track of resources across multiple environments. With the ability to partition resources across accounts, it's easier to configure "catch all" rules, such as Budgets, Cost and Usage Reports, IAM Policies, and others.

How are you using AWS Organizations to help keep track of your resources? Share your stories in the comments!

DEV Community: Jeremy Mason

Building apps from the "inside out"

So, what now?

So, what went wrong?

The Answer

Summary

Using sub-accounts in AWS

Overview

Security / Authorization

Cost Management

Organization Units

Considerations

Summary