Hello and welcome to the Getting Started with an AWS Solution: Real World Practices course from Cloud Academy. My name is Adam Hawkins, and I'm your instructor for this lesson. This lesson walks through the AWS portfolio to help you decide what to pull into your stack. We'll take an overview of the different services and end with a simple pass, hold, adopt recommendation for the following services: ECS, RDS, ElastiCache, DynamoDB, SQS and SNS, Elasticsearch and finally a Grab Bag of different smaller AWS services.

We have a single objective in this lesson. Decide which AWS services that make the most sense for your application. You should have a clear picture of what your stack looks like by the end of this lesson. Let's start by looking at the decision making criteria for evaluating the different AWS services. First off, build versus buy. Choosing hosted solution usually comes down to cost. Cost may be measured in money or time. Remember to consider you and team's expertise in a particular area. I asked myself this to answer this question.

Will I get more value from delegating this? If the answer is yes, then you're best off delegating this to more knowledgeable parties. If the answer is no, then you maybe better off learning, owning and operating that service yourself. Services may be more or less costly depending on your perspective. Some services are generally more expensive than others. All these hosted services generally come down to money versus time argument. You can mitigate the monetary cost by applying the practices discussed later in this course. You also want to consider automation. 

The more AWS services you have, the more automatable your final solution becomes. CloudFormation can do just about everything you can do with AWS console. You need to decide how much automation you want and how much of that do you want to write yourself. Continuity sort of speaks to the ergonomics of your overall solution. The more AWS services you have, the more similar practices you can use across the entire stack. Here's an example. You can use an IAM to control access rights to pretty much anything running in AWS. If you start to delegate out to other providers, then you'll lose that kind of continuity. You should also consider the portability of your overall solution.

Hosted services are great because they offload responsibility. You may rely on a hosted ready service without tying yourself to that particular service because you may run it yourself or move to another service if you need to. AWS, just like any other cloud provider offers proprietary services with their own unique upsides. This trade-off should be considered before selecting any of these services. Finally consider your development environment access.

Remember that you do not want your development environment or test suites dependent on AWS. This is primarily due to cost and reproducibility reasons, and also you don't really want to be dependent on the network just to do some basic things. Luckily DynamoDB has a local version you can run. However, things like SQS, SNS or Lambda do not. You can mitigate this with strong boundaries in your application layer, but it'll only go so far. I'm going to consider these factors and my own professional experience working with these services to give you simple pass, hold and adopt recommendations. I'll also weave in some use cases to help you understand the best fit. Let's dive right in by looking at the newest player, ECS. ECS or the Elastic Container Service is a container orchestration tool. It builds a pool of easy EC2 instances and uses AWS APIs to schedule, scale and run docker containers.

You provision the instances and install the ECS agent and the ECS API takes care of the rest. It's designed for containerized applications, but not really as fully featured as other open source orchestration tools like Kubernetes or DCOS. I recommend you opt for a different solution like Kubernetes, DCOS or even Docker Swarm if you're looking to deploy mainly containerized applications. Overall, I think you're best passing on ECS unless you have a hardware requirement in this area. If you must use ECS, then I suggest using a wrapper like Empire. RDS or the Relational Database Service is host to MySQL, PostgreSQL, Oracle, Microsoft SQLServer and more. RDS provides you a hosted service with easy upgrades, replication setups and automated backup.

It's a perfect fit for any application using an RDMS. The best part is that some databases are open source. So, you have the option to run the database yourself if you're into that. I recommend that you do use this especially if you're not a DBA. ElastiCache is hosted Memcached and Redis with HA and non-HA flavors. It does pretty much what you expect from a hosted service. You get upgrades and automated backups. The HA features really stand out here. You can build multiple known clusters and ElastiCache will automatically rotate in a new node if something fails.

Like RDS, it uses open source data stores so you can run it yourself if you outgrow the hosted solution. ElastiCache fits perfectly with any application using Redis and/or Memcached. I recommend you pull ElastiCache into your stack. It's just better than running these services yourself. Also, make sure you follow the instructions on proper set up to ensure your backups function correctly. Know that the backups happen once every 24 hours and restoring from a backup creates a new cluster. So, I advice to not treat Redis as a 100% available data store. Stick to transient data and you're golden. DynamoDB is a unique offering in the data store world. It's a guaranteed performance NoSQL Datastore. You declare your required rewrite capacities up front and DynamoDB ensures you get them. DynamoDB requires some structure for performance queries. Thus it makes sense for applications to sit somewhere in between the completely structured relational data and completely unstructured document store use cases.

AWS also provides a local version you can run for your development environment. This is a must because there's no equivalent open source offering here. If you choose DynamoDB, then you're locked to AWS. DynamoDB is one of my personal favorite AWS services because it just works, and you'll not have many performance problems as long as you maintain your read write capacities. There is one drawback though. DynamoDB cannot add certain types of indexes which are required for performance queries after you create the tables. My advice is to spend time understanding DynamoDB's data model, constructing your tables, indexes and application queries before going all in on DynamoDB.

If you're prepared with well designed tables, then DynamoDB is a clear win. Also, it may come out cheaper than RDS in some scenarios. SQS or the Simple Queuing Service gives you one-to-one pub-sub and first in first out queues. SNS or the Simple Notification Service gives you push notifications integrations with SES for email, SMS, SQS, Lambda or even HTTP servers. They're really used for a simple pub-sub and sending notifications. They're simple, reliable and highly integrated into the AWS services.

Cloud Watch actually uses SNS to send alerts for example. SNS can also pipe things back into SQS or fan out messaging, but beware these are AWS specific products. So, if you adopt them, then you're tied to AWS. My recommendation is that SNS is great for internal AWS plumbing and its advertised uses. SQS works well for simple messaging applications, but don't expect to find complex broker rule like you would find in AMQP or time-based replays you'd find with Kafka. My recommendation is to adopt SQS understanding limitations and build specific interfaces into your code to replace SQS or SNS in your non-AWS environments. You do not want your tests or development work dependent on an external web service. The Elasticsearch Service is a hosted version of Elasticsearch for all of your full text search needs. You might also need this for complex query faceting such as counting all of the items in a category within an entire result set or even running the ELK stack.

The Elasticsearch Service actually includes Kibana so it's a natural fit for ELK. Again, since Elasticsearch is open source, you can run it yourself if you outgrow the hosted solution. Check this out if you need Elasticsearch. You may want to consider the official hosted offering from Elastic.co if you would want faster version upgrades. Don't expect AWS to stay on the bleeding edge if Elasticsearch is your primary business focus. This service may be great if ELK is your primary focus. Okay, time for the Grab Bag. The Grab Bag rounds out the full spectrum of AWS offerings. Let's start with S3 and CloudFront. Odds are you'll need S3 in any AWS application.

Even if you don't use it yourself, some other services will use it to internally dump logs or restore back up to even transfer things back and forth. EC2 and S3 form the backbone of AWS. S3 can be a great simple web server with its website mode. You can also extend that even more with CloudFront for a CDN. CloudFront works well for basic use cases, but it may be costly compared to service like CloudFlare or Fastly. Elastic Beanstalk is AWS' platform as a service offering. It can run all sorts of applications from Java, Node JS, Ruby and even Docker as web applications and cron style workers.

My experience with Elastic Beanstalk has been a mixed bag. It's not as mature as a dedicated platform as a service product like Heroku. So, don't expect that level of fit and finish. If you're already using Docker, then you're better off considering ECS. If you're working cron style applications, then I recommend you use a Lambda with a Cloud Watch scheduled event tricker. If you're building a web applications, then you may consider a combination of API gateway and Lambda functions. If anything build a prototype, see if it Elastic Beanstalk works for you and you like how it works.

CloudFormation is your AWS automation Swiss Army Knife. Odds are if it's offered by AWS, then you can automate creation and configuration with CloudFormation. It sits in a curious niche because it can do infrastructure as code and also simple configuration management. I recommend you spend time looking into CloudFormation if you're going all in on AWS. Lambda is another AWS Swiss Army Knife. You upload individual functions and AWS runs them for you in a completely serverless model. Lambda is highly integrated into many AWS services.

It may be used in combination with services like SQS, Kinesis or DynamoDB. Here's an example. You can process SQS messages with a Lambda function or listen to changes in a DynamoDB table and process them with Lambda. You can also put Lambda functions behind an HTTP API gateway to create entirely serverless applications. However, I recommend you adopt Lambda for the first use case and hold on the second.

The second area is not fully baked and your experience is largely dependent on the framework you use to build the application. Thus, I recommend you hold on this use case and do your own research before trying to build an entirely serverless application. That concludes our tour the AWS portfolio.

Let's recap the services in a simple pass, hold and adopt model. I'll leave you with a few other recommendations before you move on to the next lesson. Here's my definitions. A pass is something you're best off skipping or looking for alternate solutions. A hold is that I can't give you a strong recommendation, but you should do your own research and decide if it fits your particular use case, and adopt means this is a clear win for most applications with little to no downside. ECS is a pass. There are more mature offerings and odds are you'll be happier with an open source solution. Elastic Beanstalk is another pass. Try the alternatives I mentioned earlier before trying Elastic Beanstalk.

Hold on SQS. The SQS model works well for simple applications. It's best to leave this one on hold because its users are quite application dependent. Hold on CloudFront. CDNs can be tricky as their fit really depends on the application. Elasticsearch Service is another hold. This may not make sense if your core business requirements depend a lot on new versions of Elasticsearch. However, I give this one an adopt if you're primarily targeting ELK.

My recommendation for Lambda depends on your use case. So, hold for HTTP APIs or general serverless applications for now, but adopt for internal AWS integrations like processing SQS messages or handling SNS notifications. RDS is a strong adopt. Really don't waste your time and money running RDMS yourself. DynamoDB is also an adopt. Be sure to design your schemas up front and DynamoDB will work well. Caution though, some things can only be configured at table creation time. ElastiCache is another adopt. It's just hard to go wrong with ElastiCache. I also give CloudFormation an adopt. CloudFormation enables you to keep your AWS solution in code form. This is a clear win for most AWS users.

I also recommend you adopt SNS. It works well and odds are you'll end up using it as plumbing for your other AWS services anyway. All right my friend, hopefully you're more equipped now to decide which AWS product should make up your overall stack. Also remember that everything I've shared with you so far is about general best fit. It's always in your best interest to do your own research and come to your own conclusion. So, now that you've decided what bits to use, what's the next step? That's a great question. So, you're on the right track. Join me for the next lesson where we discuss securing your application.