James Gregory & Fernando Freire- Pets ~> Cattle ~> Steak: A Story of the Commoditisation of Cloud Compute (Evolution)
•Als PPTX, PDF herunterladen•
1 gefällt mir•648 views
They used to be pets, then we turned them into cattle, when all we ever wanted was a good steak. Developers just want to run code reliably and repeatably. Instead, they spend their time with pet servers or caring for their herd. We’ve relegated hardware to a distant memory, and it is time to do the same for our idea of what a server is. In this talk, James and Fernando will cover the landscape of cloud computing, and how the evolution from pets to cattle is moving fast towards 'just the steak'. They will contrast between serverless solutions and container orchestration, and the bright future for application developers in the cloud. This is the age of computing steak, exactly how you like it done. Compute on demand, when you need it, for as long as you need it.
Empfohlen
Weitere ähnliche Inhalte
Mehr von Thoughtworks
Mehr von Thoughtworks (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
James Gregory & Fernando Freire- Pets ~> Cattle ~> Steak: A Story of the Commoditisation of Cloud Compute (Evolution)
- 1. FERNANDO FREIRE Tech Lead @nano_freire #EvolutionTW #ThoughtWorks JAMES GREGORY Tech Lead @jagregory
- 2. Pets ➜ Cattle ➜ Steak A story of the commoditisation of Cloud Compute
- 3. Pets ➜ Cattle ➜ Salad A story of the commoditisation of Cloud Compute
- 5. ©ThoughtWorks 2018 Commercial in Confidence Anything we say may be outdated by the time we end this presentation. No animals were harmed in the making of or lead up to this presentation This talk is k8s heavy 5
- 6. MOTIVATION
- 7. THE 3 WAYS
- 8. PETS
- 10. CATTLE
- 11. IAAS
- 13. PAAS
- 14. SALAD
- 17. KUBERNETES 101
- 19. HOW DO YOU DEPLOY AN API?
- 20. PETS
- 21. PETS
- 22. CATTLE
- 24. SALAD
- 25. METADATA
- 26. METADATA your-container kube-api Hi Kube API, how are you? Got Stuff?
- 27. METADATA your-container kube-api Hi Kube API, how are you? Got Stuff? HELLO FRIEND. GOT 2 SERVICES.
- 28. NGINX PROXY
- 29. KUBE LEGO
- 30. LOG AGGREGATIO N
- 31. HOW DO YOU GET LOGS?
- 32. PETS
- 34. CATTLE
- 36. SALAD
- 37. DAEMONSETs
- 40. WE LOVE SALAD
- 43. type: Deployment spec: replicas: 2 selector: app: nginx-ingress
- 46. type: Deployment spec: replicas: 2 selector: app: nginx-ingress affinity: podAntiAffinity: app: nginx-ingress
- 48. Lots of moving parts. No one definition of the whole system. COMPLEXITY 48
- 53. DEVOPS 53 DEV TEAM DEV TEAM
- 54. HOW DO YOU GET STARTED?
- 55. USE A MANAGED SERVICE AKS Azure Container Service GKE Google Kubernetes Engine EKS Amazon Elastic Container Service for Kubernetes
- 56. PLAY IN A SANDBOX
- 57. OUR REAL SANDBOX
- 58. CONCLUSION
- 59. METADATA is our FRIEND, and so is the ECOSYSTEM
- 61. 61 Keep your CLUSTER CONTAINED
- 64. THANK YOU Fernando Freire ffreire@ThoughtWorks.com James Gregory jgregor@ThoughtWorks.com 64
- 65. RESOURCES ● https://kubernetes.io/docs/tutorials/ ● https://cloud.google.com/kubernetes-engine/kubernetes-comic/ ● @krisnova ● @jessfraz ● @thockin ● @kelseyhightower ● @mipsytipsy
Hinweis der Redaktion
- These are our opinions based on our experience, we are consultants, so if you hire us we will probably be expressing these opinions.
- This is a pivot point in the industry We don’t think we all get it yet: we’re still thinking about servers We’ve had some experiences that are worth sharing
- http://www.acreditanisso.com.br/wp-content/uploads/2015/11/vaca9.jpg nano talks about physical servers and star wars and uptime racers
- Uptime racers story, 3 years without rebooting the server james: 3 years without security patches? overspecing, possibly black friday example
- NOT supposed to name Not suppose to keep them around Scale up and down 2 ways for cattle
- IAAS - too low level, have to to everything myself Story: general first experience of what autoscaling was like
- Too specific Gets expensive
- CONTAINERS! ALL we want is SALAD! pack everything together, run instantly, modular, portable, reproducible and scalable Smaller, faster, repeatable
- Docker called it “swarm” for a reason… lots of little things that are hard to control james goes into the docker host story, talking about how all of us played with this and immediately out grew the single host, and orchestration became a problem
- https://portworx.com/use-case/kubernetes-storage/ - image
- Remember the bees? Kubernetes gives us order and structure It’s about taking all our containers, and scheduling and distributing them across our servers
- James talks about high level abstractions, descriptive language, pods nano talks about services and deployments, how that gives an abstraction for things we use to do by hand (blue/green, zero downtime...) Like language abstractions and patterns
- you order a server, you name it, you compile the kernel, you wait a bunch of months, you click on a domain register to setup your DNS, you order a certificate with goDaddy, there are not enough characters in the star wars universe to run netflix
- This is your alerting system
- you write a bunch of ansible, you have some terraform. you have route53 on your terraform with your domains you get certs from your cert issuer (waiting months for internal certs from enterprise), link them in your scripts you bake some AMIs with your ansible and you app
- Not physically, but virtually putting things together, so many things to do still
- CONTAINERS!
- CONTAINERS!
- Developers are creative, it’s all containers anyway.
- Developers are creative, it’s all containers anyway.
- Mind blown story
- you ssh into your servers and tail the logs you forget passwords to some servers you need to physically be in the building to access the internal network
- That one time I forgot to logrotate ssh multiplexing
- you add log forwarding configuration to your ansible you need to make sure it's running
- One of your servers out of many is not shipping it Some apps are not shipping config drift, deployment staleness
- CONTAINERS!
- There are nodes that run all of our pods/services/deployments
- A daemon set runs on all (or selected) nodes
- Containers log to STDOUT Container hosts have access to logs on STDOUT Another container listens to host logs and forwards them to you log aggregator of choice Story about moving log aggregator service without impacting any of the teams
- So we walk into work one day and the CI is down What could be happening?
- only one nginx running on an overloaded node
- Ok, so we scale up, amazing!
- Still down, what did we get wrong?
- We have them running on the same node, the node goes down it’s all over
- So we make them run on separate nodes using affinities
- Now they’re distributed properly
- https://appdevelopermagazine.com/5680/2017/11/16/the-kubernetes-list-of-certified-providers/
- Who manages all this? Isn’t it becoming more specialised? Are developers realistically expected to know all of this? SRE, roaming specialists, secondments.
- Who manages all this? Isn’t it becoming more specialised? Are developers realistically expected to know all of this? SRE, roaming specialists, secondments.
- Who manages all this? Isn’t it becoming more specialised? Are developers realistically expected to know all of this? SRE, roaming specialists, secondments.
- Who manages all this? Isn’t it becoming more specialised? Are developers realistically expected to know all of this? SRE, roaming specialists, secondments.
- the good patterns of the industry still apply there’s no reason clusters should be shared
- While you’re mastering what’s the difference between ReplicaSets, StatefulSets, DaemonSets, Deployments etc, use a managed service for looking after your cluster.
- We’re all learning. This is all new. Play somewhere safe.
- Create a cluster, peer it with a real system, and run something non-production on it. Monitoring, alerting, logging, CI workers, etc...
- ecosystem, new creative ways to compose solutions
- keep things that change together close, and change apart separate
- there is still infra there
- The lessons summarised
- This is the future, or actually the present. We are at a time where we can make our salad exactly how we like it, on demand It presents complexities, but as we have seen a huge amount of benefit to make our systems and organisations more resilient.
- Some links and stuff for people to get started