James Enable local development (kind, minikube) Create a reference application and good docs Workshops and user groups.
Logging Monitoring Metrics Cluster Provisioning
Public and Private options AWS IAM permissions CVS vuln scanning Immutable image tagging
Bottlerocket OS EKS Optimized AMI Eksctl
ALB ingress controller native integration with ALB Cloudwatch agent for logging
Traffic Routing mTLS Canary Deploys
1. AWS App Mesh has several components that power the service mesh functionality.
2. A virtual service is an abstraction of a real service.
3. Virtual routers handle traffic for one or more virtual services within the mesh. After creating a virtual router, routes can be created and associated to it to direct incoming requests to different virtual nodes.
4. A virtual node acts as a logical pointer to a particular task group, such as an Amazon ECS service or a Kubernetes deployment
We will be deploying all of this in the lab using our ping, data, and admin service.
ENvoy proxy for monitoring
. Envoy proxy controls all
2, outgoing and in coming traffic
3. It emits statsd metrics that can be sent to
4. Cloud Watch for storage
5. Also you can run the AWS X-ray agent inside the application pod to emit
6. metrics to AWS X-Ray for traffic flow analsyt
7. Application Logs can also be sent to cloud watch
Some of the AWS App mesh functionality includes
1. Service to service communication and abstraction to enable
2. Network traffic control and Advance application rollouts such Canary deployments
3. App mesh adds in Observability by Exposing Statsd metrics, adding in tracing with AWS X-Ray and Integrating with Cloud Watch for application and mesh logs and alerting
4. It includes Fault isolation by adding configurable retry polices for routes inside AWS App mesh , This can mitigate failed requests by selecting a new host and rerouting traffic.
The AWS Copilot command line interface (CLI) commands simplify building, releasing, and operating production-ready containerized applications on Amazon ECS
AWS Proton helps you update out-of-date applications with a single click.
For Proton, an environment represents the set of shared resources and policies that Proton services are deployed into. An environment applies to all stacks deployed for a service instance.
A Proton service is an instantiation of a service template, normally including several service instances and a pipeline. A Proton service instance is an instantiation of a service template in a specific environment. A service template is a complete definition of the infrastructure and pipeline for a Proton service.
Schema file (schema.yaml)The schema file uses the OpenAPI format and includes some of the metadata that Proton requires and a definition of all the input and output parameters that are injected in the Jinja parameterized CloudFormation and pipeline templates. The parameter definitions contain such information as the name of the parameter, a description, type, whether the parameter is required, its default value, and other options if applicable. Proton validates and verifies inputs based on the schema file. CloudFormation file (cloudformation.yaml)The CloudFormation templates define infrastructure and resources that are used for the service. As an administrator, you write these templates using standard CloudFormation methods, and then use Jinja to indicate the input and output parameters as defined in the schema. CloudFormation file (pipeline.yaml)The pipeline CloudFormation templates define the pipeline that is used for the service. You write these templates using standard CloudFormation methods, and then use Jinja to indicate the input and output parameters as defined in the schema. Manifest file (manifest.yaml)The manifest file includes a list of the templates that will be used to define provisioning of the service infrastructure and the service pipeline.
The team brought in Contino to define a Cloud and Containers strategy that is scalable across the entire IT organization. Two pilots were completed - each app was onboarded to the internal Kubernetes platform, the CI/CD process was automated, delivery pipelines were designed and processes were defined and standardized. Additionally, Contino established a CCOE (Cloud Center of Excellence) to help drive the cloud strategy and help upskill the Catalyst team to scale further transformation efforts.
Automated app deployment - 40% CCOE - Workshops and working group Playbooks and strategic arch Developer Experience - Local Dev, FAQ, path to production
Kubernetes - do or do not, there is no try
Kubernetes: Do Or Do Not,
There Is No Try
James Strong - Cloud Native Director
Dec 3, 2020, 5:45 PM - 6:45 PM
Cloud Native Director - Contino
AWS APN Ambassador
A Cloud Guru Instructor
Kentucky CNCF Meetup Organizer
Certified Kubernetes Administrator
● What problem are you solving?
● How variant is your traffic?
● Is your team familiar with containerized applications?
● Do you have a good release process?
● Do you want to separate the management of the infrastructure from the applications?
● Do you frequently have too much or not enough compute power for your applications and
● Make it easy!
● Set up a base container with common
● Enable local development