MLA 017 AWS Local Development Environment

Machine Learning Guide

OCDevel

Artificial, Introduction, Learning, Courses, Technology, Ml, Intelligence, Ai, Machine, Education

4.9 • 848 Ratings

🗓️ 6 November 2021

⏱️ 65 minutes

🔗️ Recording | iTunes | RSS

🧾️ Download transcript

Summary

AWS development environments for local and cloud deployment can differ significantly, leading to extra complexity and setup during cloud migration. By developing directly within AWS environments, using tools such as Lambda, Cloud9, SageMaker Studio, client VPN connections, or LocalStack, developers can streamline transitions to production and leverage AWS-managed services from the start. This episode outlines three primary strategies for treating AWS as your development environment, details the benefits and tradeoffs of each, and explains the role of infrastructure-as-code tools such as Terraform and CDK in maintaining replicable, trackable cloud infrastructure.

Docker Fundamentals for Development

Docker containers encapsulate operating systems, packages, and code, which simplifies dependency management and deployment.
Files are added to containers using either the COPY command for one-time inclusion during a build or the volume directive for live synchronization during development.
Docker Compose orchestrates multiple containers on a local environment, while Kubernetes is used at larger scale for container orchestration in the cloud.

Docker and AWS Integration

Docker is frequently used in AWS, including for packaging and deploying Lambda functions, SageMaker jobs, and ECS/Fargate containers.
Deploying complex applications like web servers and databases on AWS involves using services such as ECR for image storage, ECS/Fargate for container management, RDS for databases, and requires configuration of networking components such as VPCs, subnets, and security groups.

Challenges in Migrating from Localhost to AWS

Local Docker Compose setups differ considerably from AWS managed services architecture.
Migrating to AWS involves extra steps such as pushing images to ECR, establishing networking with VPCs, configuring load balancers or API Gateway, setting up domain names with Route 53, and integrating SSL certificates via ACM.
Configuring internal communication between services and securing databases adds complexity compared to local development.

Strategy 1: Developing Entirely in the AWS Cloud

Developers can use AWS Lambda’s built-in code editor, Cloud9 IDE, and SageMaker Studio to edit, run, and deploy code directly in the AWS console.
Cloud-based development is not tied to a single machine and eliminates local environment setup.
While convenient, in-browser IDEs like Cloud9 and SageMaker Studio are less powerful than established local tools like PyCharm or DataGrip.

Strategy 2: Local Development Connected to AWS via Client VPN

The AWS Client VPN enables local machines to securely access AWS VPC resources, such as RDS databases or Lambda endpoints, as if they were on the same network.
This approach allows developers to continue using their preferred local IDEs while testing code against actual cloud services.
Storing sensitive credentials is handled by AWS Secrets Manager instead of local files or environment variables.
Example tutorials and instructions:

Strategy 3: Local Emulation of AWS Using LocalStack

LocalStack provides local, Docker-based emulation of AWS services, allowing development and testing without incurring cloud costs or latency.
The project offers a free tier supporting core serverless services and a paid tier covering more advanced features like RDS, ACM, and Route 53.
LocalStack supports mounting local source files into Lambda functions, enabling direct development on the local machine with changes immediately reflected in the emulated AWS environment.
This approach brings rapid iteration and cost savings, but coverage of AWS features may vary, especially for advanced or new AWS services.

Infrastructure as Code: Managing AWS Environments

Managing AWS resources through the web console is not sustainable for tracking or reproducing environments.
Infrastructure as code (IaC) tools such as Terraform, AWS CDK, and Serverless enable declarative, version-controlled description and deployment of AWS services.
Terraform offers broad multi-cloud compatibility and support for both managed and cloud-native services, whereas CDK is AWS-specific and typically more streamlined but supports fewer services.
Changes made via IaC tools are automatically propagated to dependent resources, reducing manual error and ensuring consistency across environments.

Benefits of AWS-First Development

Developing directly in AWS or with local emulation ensures alignment between development, staging, and production environments, reducing last-minute deployment issues.
Early use of AWS services can reveal managed solutions—such as Cognito for authentication or Data Wrangler for feature transformation—that are more scalable and secure than homegrown implementations.
Infrastructure as code provides reproducibility, easier team onboarding, and disaster recovery.

Alternatives and Kubernetes

Kubernetes represents a different model of orchestrating containers and services, generally leveraging open source components inside Docker containers, independent of managed AWS services.
While Kubernetes can manage deployments to AWS (via EKS), GCP, or Azure, its architecture and operational concerns differ from AWS-native development patterns.

Additional AWS IDEs and Services

Conclusion

Choosing between developing in the AWS cloud, connecting local environments via VPN, or using tools like LocalStack depends on team needs, budget, and workflow preferences.
Emphasizing infrastructure as code ensures environments remain consistent, maintainable, and easily reproducible.

Transcript

Click on a timestamp to play from that location

0:00.0	Welcome back to Machine Learning Applied. Today we're going to be talking about developing within the AWS environment.
0:08.0	In other words, using AWS as your local development environment.
0:13.4	Now, before we get started, let's reflect back on a prior episode about Docker.
0:19.0	I did an episode where I said you can package up an environment
0:23.1	and its dependencies and the project's source code into a Docker container and deploy that
0:30.3	Docker container to the cloud. What we do is we write a Docker file, literally called Docker file
0:35.9	with a capital D. At the top of that Docker file you specify
0:39.3	the operating system you're going to be using, and then within the Docker file you're going
0:43.2	to specify any number of operating system level packages you want to install, like FFMPEG or Kudaku
0:50.5	DNN, and you might install some PIP packages. You can either directly inline the Docker file, say PIP install X, Y, and Z, or you can have
0:59.2	a requirements. text file that gets copied into the Docker container, and then that thing gets
1:04.4	kicked off with a PIP install of the requirements. text.
1:07.1	And then what you'll see in the Docker files is copy some host directory to the container
1:14.5	directory, all capitals C-O-P-Y, copy, space, the location of the source code on your computer,
1:23.4	relative path.
1:24.5	So if you're working within your project route, and at your project root, there are
1:29.2	a handful of miscellaneous files, and then within the source directory, that's actually the
1:34.3	source code for your project, all your Python files. And then within the Docker container,
1:39.6	it's expected to be running out of the forward slash app directory. What you'll see is copy
1:46.6	forward slash source space forward slash app. And what that will do is it will take your
1:52.5	Python files from the source directory and copy them into the app directory of the Docker container.
1:58.5	And then you'll typically have a Dockercompose.YML file,
	...

Please login to see the full transcript.

Previous episode | Next episode

Disclaimer: The podcast and artwork embedded on this page are from OCDevel, and are the property of its owner and not affiliated with or endorsed by Tapesearch.

Generated transcripts are the property of OCDevel and are distributed freely under the Fair Use doctrine. Transcripts generated by Tapesearch are not guaranteed to be accurate.