AWS DevDay Vienna - Automating building blocks choices you will face with container services

Editor's Notes

• #3: Each team can move independently and simultaneously In contrast to Monolith (where the Deployment Unit is the entire program), Microservice has a separate deployment pipeline, enabling us to make small changes and speed up our Release Velocity. Each microprocessor can be written in a different language, and each team can choose its own technology stack - the most convenient or appropriate tools. Modularity - Because each unit is small, it can be easily replaced. Distributed work reduces dependence between different parts - but there are, however, common principles that aim to facilitate coordination and organizational standards.
• #4: When you know you’re going to need to eventually handle more than one type of a thing, consider generalizing. Take for example integrating payments systems, building for one is easy but integrating with any system, even those you are unaware of is really hard. Click Generalize… But just barely-, make your system capable of handling two kinds of things. This will help you avoid too tightly coupling. Click As long as the systems are not too similar you will be abstracting a good amount of flexibility for the effort.
• #5: Starting with a monolith is often the right choice, it allows for fast development at the early stage. As you don’t need to design the process boundaries ahead of time. A designed monolith can be scaled horizontally and broken apart later if needed. Depending on the type of startup, you may never outgrow the scaling capacity of a well-designed monolith.
• #6: The solution is self-service tools and automation….enabling each one of the DevOps teams to own and manage their own release process.
• #8: There are different approaches for IaC, but it is important to use one with declarative syntax, like CloudFormation or Terraform
• #10: The AWS CDK is an infrastructure modeling framework that allows you to define your cloud resources using an imperative programming interface. The CDK is currently in developer preview. We look forward to community feedback and collaboration.
• #11: OPTIONAL: a live demo with the CDK with this sample code
• #12: Applets are YAML files that directly instantiate constructs, without writing any code.
• #13: To configure AWS CodePipeline pipelines with the CDK. When you add a microservice, you need to create a new pipeline, similar to your other ones. With CDK you can use an higher level class instead of copying and pasting lots of YAML code.
• #14: Constructs are the building blocks of AWS CDK applications. Constructs can have child constructs, which in turn can have child constructs, forming a hierarchical tree structure. The AWS CDK includes two different levels of constructs: CloudFormation Resource These constructs are low-level constructs that provide a direct, one-to-one, mapping to an AWS CloudFormation resource, as listed in the AWS CloudFormation topic AWS Resource Types Reference. All CloudFormation Resource members are found in the @aws-cdk/resources package. AWS Construct Library These constructs have been handwritten by AWS and come with convenient defaults and additional knowledge about the inner workings of the AWS resources they represent. In general, you will be able to express your intent without worrying about the details too much, and the correct resources will automatically be defined for you. AWS Construct Library members are found in the @aws-cdk/NAMESPACE packages, where NAMESPACE is the short name for the associated service, such as SQS for the AWS Construct Library for the Amazon SQS service. See the Reference section for descriptions of the AWS CDK packages and constructs.
• #15: In the stack you can use the constructs you defines before, like the pipeline we created in the previous slide.
• #18: The most common purpose for an auto scaling groups is resiliency; instances are put into a fixed-size auto scaling group so that if an instance fails, it is automatically replaced. The simplest use case is an auto scaling group has a min size bigger than 1.
• #35: The most common purpose for an auto scaling groups is resiliency; instances are put into a fixed-size auto scaling group so that if an instance fails, it is automatically replaced. The simplest use case is an auto scaling group has a min size bigger than 1.
• #36: The current AWS container services landscape covers a broad set of products. Not all are serverless (Fargate) So you have other options. At the orchestration layer we’ve Amazon ECS and Amazon EKS. EKS makes it easy to deploy, manage, and scale containerized applications using Kubernetes on AWS. You can currently run your containers on ECS using either the EC2 launch type – where get to manage the the underlying instances on which your containers are running - or you can choose to run your containers in a serverless manner with the AWS Fargate launch type. Finally, we provide a registry services, Amazon ECR, where you can store your container images.
• #38: Fully managed control plane: Multi az, right sized master setup etcd scaled automatically, Provisioned IOPS, snapshotted at intervalsWorker nodes: Spot instances / GPU / autoscaling group You can think about EKS as a managed Kubernetes API endpoint. It’s upstream Kubernetes, no forking: So you can take your kubectl and communicate with the endpoint. Use all your tools
• #43: Creation + storing Rotation Dynamic - storming
• #51: ESB: Dumb endpoints smart pipes uS: Smart endpoints, dump pipes Retries, circuit breaker pattern, routing etc. Netflix Open Source Software Center
• #52: Creating services is easier, Manage parts go harder. New pattern: offload to proxy Istio is the control plane and Envoy is the data plan Istio, at its core, handles the routing, load balancing, flow control and security needs of microservices. It sits on top of existing distributed applications and basically helps them talk to each other securely, while also providing logging, telemetry and the necessary policies that keep things under control (and secure). It also features support for canary releases, which allow developers to test updates with a few users before launching them to a wider audience, something that Google and other webscale companies have long done internally. The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices Touches every packet/request in the system. Responsible for service discovery, health checking, routing, load balancing, authentication/authorization, and observability. Service mesh control plane: Provides policy and configuration for all of the running data planes in the mesh. Does not touch any packets/requests in the system. The control plane turns all proxies into a distributed system. https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc
• #53: Originally from Lyft Envoy is a nice peace of engineering with a lot of good background articles to read: Now used by various cloud providers and in OSS projects to build everything from API GW to LBs Linkerd and Nginx have shown Istio integration. Data plane can be swapped. Not so tightly coupled Since it is level 7, it can route for URL, user agent = Safari / Chrome ,
• #54: Explain sidecar pattern, same network namespace IP/ports. Sidecar injection: default namespace gets a tag. Istio injects pod when tag is set. Chaos engineering. Try to break things before they break in prod. Add delay of 5 seconds. Kubectl apply -f CRD: kubectl get virtualservices ### The service mesh a lot of attention right now (rightly so!) The Istio model of a service is independent of how it is represented in the underlying platform (Kubernetes, Mesos, Cloud Foundry, etc.).  clients of a service have no knowledge of different versions of the service, continue to use host / IP VirtualService: rules that control how requests for a service are routed within an Istio service mesh. Kubetctl get virtualservices / destinationrules – uses CUSTOM RESOURCE DEF https://istio.io/docs/concepts/traffic-management/#rule-configuration
• #55: Originally from Lyft Envoy is a nice peace of engineering with a lot of good background articles to read: Now used by various cloud providers and in OSS projects to build everything from API GW to LBs Linkerd and Nginx have shown Istio integration. Data plane can be swapped. Not so tightly coupled Since it is level 7, it can route for URL, user agent = Safari / Chrome ,
• #57: Replica deployment / traffic flow Free symbol https://iccpic.com/free-icon/bathtub-house_64734.html https://iccpic.com/free-icon/foot_479564.html
• #59: Originally from Lyft Envoy is a nice peace of engineering with a lot of good background articles to read: Now used by various cloud providers and in OSS projects to build everything from API GW to LBs Linkerd and Nginx have shown Istio integration. Data plane can be swapped. Not so tightly coupled Since it is level 7, it can route for URL, user agent = Safari / Chrome ,
• #60: It is all the same mesh. Use mesh to migrate from monolith to containers Mesh Does not have to be container, helps to containerize. Remember the options for modernization of legacy apps: different solutions App mesh embraces them all Based on Istio data plane, but we implemented a control plane and that HA, for you. ECS, Fargate: You add the Envoy proxy image to the task definition OBSERV, Tracing: Iintegrated with Cwatch log & metric, X Ray Traffic Management: LB, Path based routing