Things to Consider Before Building a Green Field Application in AWS

A guide on streamlining the process of building an application in AWS.

Even though the picture sounds rosy this is a really intimidating statement. The number of different combinations of services in AWS is staggering, and it’s hard to know where to start if you’re creating something from scratch. You’ll have to answer questions like:

1. Should I use a serverless platform or EC2?
2. Should I use RDS or run my own databases?
3. Should I use NoSQL like Mongo or a relational database?
4. Should I store static content in S3 and present it with CloudFront, or just put it on a server?
5. Will I need to do analytics? Should I worry about a data lake?
6. Should I use Terraform or CloudFormation or CDK?
7. What should my pipeline look like? What build platform should I use?
8. What testing framework should I use?
9. What monitoring framework should I use? CloudWatch? Datadog? Newrelic?
10. Do I need to use all of the fanciest app management tools right away? Do I need tracing, metrics, and structured logging?
11. Should I use ECS or Kubernetes?

And the list goes on and on. All of these questions can be relevant, but I’m going to argue in this post that you don’t have to answer them all right away.

Consider your infrastructure to be an MVP

When you’re designing a product you use the concept of a minimum viable product to simplify your plans. It’s a tool to force you to think through the most important features and aspects of what you want to release so that you can do it quickly. An MVP asks the questions, “What’s the core of what my customers need, and can I provide them with a simple solution that adds value?”

You should use the same technique with your infrastructure. Rather than take everything to the 9’s and create a fully CICD, 100% automated, fully traced, logged, modernized application focus on solving a business need in the simplest possible way that doesn’t trap you in a corner in the future.

“How do I keep from getting stuck in a corner?” You ask. There are two guiding principles that will help make this simpler for you

1. AWS is loathe to deprecate services
2. Any service you need is just an SDK call away

AWS is loathe to deprecate services

Any service you pick in AWS is likely to be around for quite a while. Elastic Beanstalk is a great example — released 10 years ago now and as of the time of this writing, it’s still seeing active development with new products being announced.

So even though it’s good to spend some time thinking about what service you should use, and what services will support your long-term use case you don’t need to stress over picking something that will go away in short order.

The one caveat to this I’ll add is that if you go the classic EC2 route you should have a plan to update your AWS drivers either through an AMI update or Systems Manager.

Any service you need is just an SDK call away

The AWS SDK gives you access to anything you could need to do in AWS. Even if you pick a service and then outgrow its features any other service you could need is just an SDK call away.

That’s another reason you don’t have to stress too much about the specific service you choose. You have an easy ability to expand out of where you start.

So how do you get started?

There are a few things you should consider

1. Do you fit exactly into an example?
2. What’s your team familiar with?
3. What’s trendy

Do you fit exactly into an example?

AWS CodeStar is a great example of this. When you take a look at the project templates they have examples of things you can create almost instantly out of the box. If you read about one of these templates and think to yourself, “That’ll work to start with!” You’re on the right track, you’ve found something you can use.

If you look at that list and think, “Well that’s close but I wonder if I can….” spend <5 minutes googling the problem. If you can’t find anything about the problem online, you’re likely an edge case and you should choose a more general platform.

Elasticbeanstalk is another great example. If you fit exactly into one of these environments, then great! Use it!

If you don’t it’s a good idea to take a step back and accept that you’re going to need to do some work yourself to get a solution in place.

What’s your team familiar with

The two domains this applies to the most are database and language. If you have a team that’s familiar with NoSQL, or you have a project that’s small enough to try something new go for it! But if you have a large project, and a team that’s only familiar with RDBMSs, then stick with that. There’s a reason those technologies have been around as long as they have — they work and you can build functional products on top of them.

When you’re starting a new project it’s important to remember what you’ve already got momentum with and take advantage of any experience you already have.

The same goes with languages. Even if everything you read online is that functional languages and NodeJS are the only way to go if your team is familiar with python, or java, or ruby and nothing else take advantage of that experience. All of them are flexible enough to get you started and build the products you need.

What’s trendy

I wrote a post contrasting the experience of getting started with chef recipes vs docker in 2019. The punch line was that the chef recipes I was using had stagnated, while the docker containers and examples were being well maintained and improved upon.

The punch line is that even if you want to respect what your team is familiar with you should spend a little time figuring out what’s getting attention from larger technology companies and the open-source community. If you pick something that’s been abandoned you’ll have a harder time getting started.

Cover the basics

You don’t need the world's fanciest, easiest to run the application out of the box, but you do need something workable. Here are my recommendations on the basics to cover

1. Pipeline — I’d recommend Codepipeline in most cases
2. Structured logging — if you put a little time into json logging, CloudWatch insights will make your life much easier
3. Set yourself up for tracing and metrics, even if you don’t instrument everything immediately
4. Infrastructure as Code — avoid creating things manually as much as you can

Good luck building!