Launching a production app onto the cloud is a big task with a ton of tiny sub-tasks, and it can all be pretty overwhelming.
We're here for you. We've launched an app ourselves (Blue Matador, our cloud infrastructure monitoring software). In the coming weeks, we will walk you through everything you need to know and do to successfully launch your app—with the least amount of effort.
You've put a lot of time and toil into developing your app, so it's worth doing some prep work to make sure you cover all your bases before you push to production. In this first post in our series, we're gonna list out all the things you need to inventory and consider before you're ready to push to the cloud.
Other posts in this series:
Yes, you should deploy your app to AWS
Look, we'll get straight to the point: You were probably already planning on launching to AWS, and that's the right call.
There are a few other options out there, but they are dwarfed in size and capability by Amazon. AWS covers compute, database, IoT, analytics, DevOps, CDN, access controls, and more. It has over 175 services. And in terms of spread, it has 22 regions (with 5 more announced), including GovCloud, which is specifically for U.S. government software, covering 6 continents, 70 availability zones, and 205 edge locations.
That said, not all services are provided in all regions, and the prices vary, so choose carefully.
We're not going to go into a ton of details on competitors here since we're assuming you've already chosen AWS, but you can take a look at the 2019 Gartner Magic Quadrant for cloud infrastructure as a service to see how other options—like Microsoft, Google, and Oracle—compare to AWS.
If you're considering Azure or Kubernetes, keep in mind that AWS covers both of those platforms' main use cases: AWS supports all things Windows and all things Kubernetes.
What to think about when you assess your app for release
Now that you've decided on your cloud provider, the next thing to do is take stock of everything you need to deploy. Answer all of the questions below before you begin deploying. Having the entire layout of your application infrastructure will save time during deployment.
Answer these questions for each of your server-side applications:
- How is the application built?
- Is there a script to release and run the application?
- What ports need to be open?
- What services does this application rely on?
- What configuration does it need?
- Can it work behind a load balancer?
- What libraries or local packages does it need?
- Does it have cron jobs, background jobs, or scheduled maintenance?
- What compute infrastructure was it built for? Serverless, containers, or virtual machines?
- If EC2, does the operating system matter?
- Is there a minimum memory requirement?
- Are there any health checks or health endpoints to call?
- Are there any special release instructions from any other developers?
Other things to consider:
- What databases (type and version) do you need?
- Are there any static files to serve?
- What domain names and subdomains will you use, and where will they go?
- Do you own the domain names already?
- Is there already an AWS account set up?
How to choose your AWS services
Next up, it's time to think about what AWS services you'll need. AWS has over 175 services. Just looking at the full list can be overwhelming. To help you narrow it down, here are the services you'll most likely need, short of those specific to your application.
AWS services for compute
- Amazon Elastic Compute Cloud (EC2) / Virtual Private Cloud (VPC). These are your standard virtual
machines and the default option. In general, if you use one, you'll use both. EC2 is the compute for servers, disks, IP addresses, load balancers, and firewalls, whereas VPC is the networking layer for EC2. - AWS Elastic Beanstalk / Amazon Lightsail. Beanstalk is Amazon's app deployment service. Beanstalk is compatible with a wide variety of languages (Go, Docker, Java, PHP, Node.js, Python, .NET, Ruby) and servers (Nginx, IIS, Apache, Passenger). Lightsail is one of the easiest-to-use AWS cloud platforms, providing storage, databases, virtual servers, and more. It's best for devs who are just starting in the cloud or who have simple workloads.
- AWS Lambda / Application Gateway. This option is gaining in popularity, but to use this pair, you have to have built your application for it specifically, so if you didn't... well, you'll have to choose different compute services. Lambda is the place your code runs, and Application Gateway is your load balancer.
- Amazon Elastic Kubernetes Service (EKS) / Amazon Elastic Container Service (ECS) / AWS Fargate. To use these services, your application must have been built in containers. Container services are a good next choice if you don't want to use EC2—it's a lot easier to move your application into containers than it is to move to Lambda. ECS is the old-school container option, EKS is hosted Kubernetes, and Fargate is a mix of the two. If you’re using containers, and haven’t chosen which container infrastructure to run on yet, choose EKS. Kubernetes has already won.
AWS services for database
Amazon Relational Database Service (RDS). RDS is a fully managed cloud database service that supports MySQL, Postgres, MariaDB, SQL Server, Oracle, and the AWS cloud-native database Aurora. At this point, you should know which engine you need, and it’s probably not worth changing it. If you use MySQL, consider Aurora—it’s faster, built for AWS, and fully MySQL compliant.- Amazon DynamoDB. Globally distributed and available, fully managed NoSQL database. It has nuance, for sure, but is incredibly fast and built to scale. If you need NoSQL, this is probably what you’re looking for.
- Amazon Elasticsearch Service. Fully managed Elasticsearch cluster. If your application uses Elasticsearch, you could roll your own cluster or use this managed one.
AWS services for content delivery
- Amazon Simple Storage Service (S3). S3 is Amazon's cloud object storage service. You’ll use this one,
no doubt about it. It’s great for hosting HTML, Javascript, and CSS. Also great for getting file uploads, PDFs, and large documents out of your database. - Amazon Route 53. Another one you'll definitely use. Amazon Route 53 is your managed DNS. If you already bought your domain from some other provider, and they offer free DNS, switch to Route53. It’s $1 per month and integrates much better with AWS services (which stands to reason).
- AWS Certificate Manager. This one you might not have considered, but it's one you should definitely use. A couple years back, AWS started offering free SSL certificates. Yup, totally free. Certificate Manager is where you get them. It will do a validation check on your domain (easier with Route53), and then grant you a free certificate to use in your AWS services.
Other AWS essentials
- AWS Identity and Access Management (IAM). This is where you’ll secure your account and grant permissions. Whether you go there or not, it’s running and controlling your environment.
- Simple Email Service (SES). Email is so simple, but because spammers and spoofers ruined it, now you have to spend time to guarantee deliverability. Most AWS IP addresses are blacklisted by most ISPs and email providers as spam generators. Even if you went through all the right steps to whitelist your IPs, your emails still won’t be as deliverable as if you spent 10 minutes setting up SES. It uses SMTP protocol, same as your dev environment, it just connects to a different hostname and uses credentials.
Ensuring your app meets compliance rules
Yeah, it's something nobody likes to think about. Fortunately, at this stage, it's less crucial to worry about—but you should take an inventory and know what you need in case things take off.
Laws and regulations require compliance with the following. Assess what you have, what you need to be compliant with, and what you need to do to get there. Of course, we do not offer legal advice, and you should consult a lawyer to ensure full compliance.
Personally identifiable information (PII)
If you collect as little information as someone's name and email address, you must be compliant with data privacy rules. The same goes for if you collect additional information, including phone numbers, IP addresses, cookies, and even GPS location data.
Ways to get by for now (and that are just a good idea in general): specify a privacy policy, refrain from sharing and selling information, and secure all endpoints and access to PII using credentials.
Payment Card Industry Data Security Standard (PCI DSS)
Even though PCI compliance is not technically a law, it is mandated by credit card companies and overseen by the FTC.
Basically, anyone who handles payment should adhere to PCI rules.
Ways to get by for now:
- Avoid accepting credit card or bank information on your website directly, but go through a third-party processor like Stripe. If they handle all the payments, you're secure.
- Never give out payment information, even after identity verification.
- Train your team to never take payment over the phone, email, chat, fax, mail, etc. Always use either checks or a third-party payment processor.
General Data Protection Regulation (GDPR)
You may remember this being a big deal a few years ago when it first went into effect—something about the EU? Well, the truth is, while GDPR certainly applies to companies based in the EU, it also applies to any organization if it "offers goods or services to or monitors the behaviour of EU data subjects," according to EUGDPR.
Considering its broad scope and potential fines (up to $20 million for small businesses), it's smart to keep GDPR in the back of your mind.
However, since it's entirely dependent on having users from the EU, if you don't anticipate that happening anytime soon, you can address this one in the future.
Health Insurance Portability & Accountability Act (HIPAA)
HIPAA was created to protect patients' personal health information (PHI), which is the combination of PII and health information. Thus, you only need to be HIPAA compliant if you handle PHI specifically for a health services provider. If you don't, then you don't.
You also don't need to be HIPAA compliant if you handle PHI for individuals. For example, a fitness app is exempt, unless it was commissioned by or purchased by the Departments of Health and Human Services (HHS).
If you fall into the "needs to be compliant" group, there are services out there you can outsource health information to for a relatively low fee.
Privacy policies and terms and conditions
Even though these aren't always mandated by law, you should 100 percent have them in place, as they may still have legal implications.
There really are no good shortcuts here. To minimize risk, you should create these yourself with the help of an attorney, then post them and require acceptance from your users. It's worth it, as having them just might save your bacon.
Conclusion
Hopefully this gave you a good list of things to consider as you prep to launch your app to production. When you have a thorough knowledge of all the elements of your app, which AWS services you'll need, and any compliance rules you need to comply with, you're already off to a great start.
Coming up next in our series, we'll go over the myriad decisions you'll need to make before you launch.
