Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Microservice migration
- 7. routing logging email sending database migrating authentication database connections error handling connecting to external services housing tests
- 8. routing
- 17. Next Steps
- 18. Scalability
- 19. Database
- 20. ECS
- 22. Resiliency
- 24. failover
- 25. AWS failure
- 26. AWS Uptime
- 27. Security
- 29. defense in depth (did)
- 30. Database
- 31. VPC
- 33. Flexibility
- 36. Azure Uptime
- 37. Operation Costs
- 38. pricing
Editor's Notes
- current setup - monolithic what is issue? what is the solution? wanting to migrate to AWS – microservice arch
- let’s look at the current front-end setup what are issues?
- cognito auth users – you already know w/ Amplify – cognito instances/permissions/policies
- S3 serves STATIC website content – images, HTML, JS, CSS
- CI/CD there is a choice I presume you can incorp a Jenkins, TeamCity, etc CI and a CD pipeline Or AWS has a service: CodeBuild and CodePipeline
- let’s look at the current API setup what are the issues?
- responsible for a lot a lot of moving parts: security risks readability issues scalability issues spread this load
- AWS gateway handles all RESTful API calls after hitting cognition and getting granted permission for that user 1M RESTful API hits per month – free tier
- using Node.js, Python, Java, Ruby, C#, Go and PowerShell. Requests $0.20 per 1M Duration $0.0000166667 for every GB-second Lambda@Edge Requests $0.60 per 1M Duration $0.00005001 for every GB-second High coupling of lambda-lambda is ill-advised
- let’s look at the current DB setup what are the issues? scalability converting to Redshift/MongoDB on AWS migration lambdas can be setup
- what it was to
- what it can be – the basics solving all problems defined before 1: user hits the DNS which is served by AWS Route53 2: AWS CloudFront retrieves static webpage from AWS S3 (Angular app, CSS, images) 3: AWS Cognito verifies users login/creds 4: AWS Gateway handles Angular RESTful URIS requests 5: corresponding AWS Lambda function is invoked 6: corresponding action occurs thro AWS MongoDB/Redshift, AWS SNS, Twilio, etc 7: (if applicable), result is returned to the user
- this entire system can be monitored through AWS CloudWatch where alerts can be created on logs or event triggers users can view logs ad-hoc for each serverless component thro AWS CloudTrail X Ray is very useful for diving through the stages of the process
- AWS have their own CI/CD services in the form of: CodeCommit, CodeBuild and CodePipeline I presume you can incorp a Jenkins, TeamCity, etc. CI and a CD pipeline
- 1: code is pushed to BitBucket 2: BitBucket pipeline to trigger CI 3: if pass, hook/action/trigger to CodePipeline 4: push image into ECS 5: Fargate hosts the container in env
- spike thro that process – exc. CI/CD but want to know what they prior
- Whether NoSQL (DynamoDB) or RDB (Aurora through RDS), capable of scaling | Dyn through temporary increased capacity throughput (vertical) or partitioning (horizontal) Aur through either: beefing up stats (vertical) or sharding (horizontal) auto-scaling functionality https://aws.amazon.com/blogs/database/scaling-your-amazon-rds-instance-vertically-and-horizontally/ Transactions follow ACID principles Dyn supports serial isolation (strongest) whilst Aur provides read-commit isolation https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/ConceptsGuide/Other/Transactions.htm?tocpath=Vertica%20Concepts%7CCommon%20Vertica%20Concepts%7CTransactions%7C_____0 Both provide access to multiple Availability Zones (AZ) for fault tolerance - Dyn also provides built-in message queue for undelivered messages Savings attributed https://aws.amazon.com/blogs/database/amazon-dynamodb-auto-scaling-performance-and-cost-optimization-at-any-scale/ NoSQL indexing is very important in design
- ECS containers auto-scale with alerts from CloudWatch metrics and thresholds - service Individual aspects can scale within, i.e. When you scale the DB the UI does not necessarily scale with it | independent of each other – separate tasks ECS can be config’d to run across multi AZ - Elastic IP addresses https://www.freecodecamp.org/news/amazon-ecs-terms-and-architecture-807d8c4960fd/
- Something to note with Lambda (perhaps Functions) is cold-start times
- SVL vs non-SVL components (internal or external) SVL components have resiliency baked-in: | Dyn letter queues retires on Lambdas Internal to AWS, there are components: dead-letter queues, cache clusters, circuit breakers, throttling Appreciation for sync vs async requests
- If an individual server goes down in a region, multi-AZ kicks in | active multi-AZ passive multi-AZ https://aws.amazon.com/blogs/apn/making-application-failover-seamless-by-failing-over-your-private-virtual-ip-across-availability-zones/ If a region datacenter goes down, then multi-regional support is needed – v difficult – only business critical | data syncing issues latency issues data sharing legally DNS routing more costly hybrid-cloud – talk about later Netflix recovery from region datacenter crash Xmas Eve 2012 https://read.acloud.guru/why-and-how-do-we-build-a-multi-region-active-active-architecture-6d81acb7d208 https://www.reuters.com/article/net-us-companies-netflix/netflix-blames-amazon-for-christmas-eve-outage-idUSBRE8BO06H20121226
- AWS provides service health dashboard to give the status on their services/products https://status.aws.amazon.com/ This can be personalised too https://phd.aws.amazon.com/phd/home#/dashboard/open-issues However, these are dependent on AWS products meaning they’re not an assured way of knowing https://aws.amazon.com/message/41926/ So, what is available if AWS fails | user’s local cache – serviceworkers hybrid-cloud – talk about later
- AWS Service Level Agreement (SLA) promises uptimes for their services https://aws.amazon.com/legal/service-level-agreements/ 5-nines is possible (emergency systems) as this article states – through multi-region https://aws.amazon.com/blogs/publicsector/achieving-five-nines-cloud-justice-public-safety/ Credit is compensation for slipping below S3: 99.9 (native storage) IoT Core Service: 99.9 (real-time IOT analytics) RDs: 99.95 (relational database) EC2, ECS, EBS, Fargate: 99.99 (computing) Lambda: 99.95 (inter-functionality) 96.35/yr
- Shared responsibility model
- Point that perhaps I did not explicitly mention, or drive home is the idea of Defense In Depth (DID) | Cognito is not enough AWS services | WAF (firewall rules based on web security rules to protect against SQL and XSS attacks) Lambda authorizers Starts with protecting your code – CI/CD (automate and protect branches, pipelines) Other AWS and security protocols to abide | IAM permissions Principle of Least Privileges (POLP) Secret managers (IAM permissions)
- As part of the shared respon model – encryption on client-side is your responsibility, AWS help out Combined with encrypt at rest = DID
- VPC can be public facing or hidden away and accessed via another VPC Number of conns between VPCs too | k Spin-up time increase
- Shared re model, security of hw, sw, networking All services adhere to these protocols https://aws.amazon.com/compliance/services-in-scope/
- Top-left: Operational DMBS Bottom-left: Cloud IaaS Top-right: Analytics and BI Platforms Bottom-right: Cloud AI Developer Services They are very similar in their ability to deliver and the offerings they have https://www.saviantconsulting.com/blog/7-reasons-why-azure-is-better-than-AWS.aspx
- Multi-cloud is using multiple cloud providers and hosting separate services on them, i.e. AWS ticketing system and Azure web service | idea behind this is to get the best deal or, use specialist tool on 1 provider that another doesn’t offer (Azure Time Series) Hybrid-cloud is deploying a single system over multi-cloud providers | idea behind this is for disaster recovery Different methods of hybridizing | active-passive (backup is used if the primary fails) active-active (both are used and data split between them) Thinking of the architecture of these techniques raises interesting points | it’s not going to be straightforward – business advantage of isolation/tying down active-active seems to be the most manageable – website is split amongst the 2 systems thro some gw – questions there active-passive involves 2 connections between the systems – internal to both https://azure.microsoft.com/en-in/overview/hybrid-cloud/ Multi-cloud within either system process adds more complication | wanted to use Azure Time Series for .e.g https://docs.microsoft.com/en-us/azure/architecture/aws-professional/services https://www.oreilly.com/library/view/multicloud-architecture-migration/9781492050407/ch01.html
- https://azure.microsoft.com/en-gb/support/legal/sla/summary/
- Azure Service Level Agreement (SLA) promises uptimes for their services https://azure.microsoft.com/en-gb/support/legal/sla/summary/ Diff between Azure and AWS’ uptime guarantee is Azure offers more incentive for ‘better accounts’ | this does mean that equivalent free-tier or basic accounts Credit is compensation for slipping below Blob: v. 99.99-99.9 (native storage) IoT Central v. 99.9-0.0 [trial applications] (real-time IOT analytics) MySQL: 99.99 (relational database) AKS: (99.95), VM: (99.99) (computing) Functions: 99.95 (inter-functionality) v (97.28 – 96.23)-0/yr vs 96.35/yr (AWS)
- https://aws.amazon.com/pricing/?nc2=h_ql_pr_ln
- https://azure.microsoft.com/en-gb/pricing/#product-pricing
- Pricing models are the ‘same’ in that, they are, pay for what you use | again with Azure we see incentives for bigger accounts may provide finer granularity – overwhelming to me also offers 3-year and 5-year deals on services multi-AZ prices Something else to consider is direct vs indirect pricing | direct (requests, memory, duration, provisioned concurrency) which I’ve looked at indirect (data transfer, use of services, e.g. auto-scaling ECS requires CloudWatch) bottom line, they are V similar https://aws.amazon.com/pricing/?nc2=h_ql_pr_ln https://azure.microsoft.com/en-gb/pricing/#product-pricing