Pets versus Cattle: servers evolved
•Als PPTX, PDF herunterladen•
2 gefällt mir•1,655 views
An excite talk I gave talking about Pets versus Cattle and the pros and cons of this approach going forward. TL;DR having more cattle than pets will make datacenter more efficient, shift the burden of uptime towards more of a DevOps role and provide a smoother development and deployment model. Let's do this!
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (11)
Ähnlich wie Pets versus Cattle: servers evolved
Ähnlich wie Pets versus Cattle: servers evolved (20)
Mehr von Phil Cryer
Mehr von Phil Cryer (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Pets versus Cattle: servers evolved
- 1. Pets versus Cattle: servers evolved St Louis, MO 02/24/2015 Phil Cryer / @fak3r Automation Engineer / hacker
- 2. Servers the "enterprise computing" model
- 4. "When one of them gets sick, you shoot 'em in the head and replace 'em with a new one” Randy Bias, CEO of Cloudscaling, 2012 Pets Cattle!
- 5. Major disruption! (aka #fail) Decision? Server offline! Fix ASAP or you’re fired! Pets
- 6. Major disruption! (aka #fail) Decision? Server offline! Fix ASAP or you’re fired! Unnoticed by end-users Kill server, and start another Pets Cattle
- 7. One size does not fit all so we’ll still need (some) pets
- 10. “…a data center full of vanity free servers… is more efficient and less expensive to build and run.” 38% more efficient 24% less expensive Hardware the "cattle" model
- 11. DevOps it’s the new style (4 and 3 and 2 and 1) WWAD?
- 12. Agile infrastructure frequent incremental releases
- 13. Automate everything open source, apis take control
- 14. Stax light fuse, get away
- 15. Forward thinking brings new ideas and methods
- 16. Existing IT the impact of the "cattle" model
- 17. Barriers to adoption “this is how we’ve always done it”
- 21. Thanks St Louis, MO 02/24/2015 Phil Cryer / @fak3r Automation Engineer / hacker Mooooo…
Hinweis der Redaktion
- SERVERS HAVE ALWAYS BEEN — formally named (Zeus, Apollo, etc) — utilizing proprietary hardware required lots of hand holding— run for years, with incremental patching and meticulous backups
- MEANWHILE ADMINISTRATION - response was very reaction(ary) — servers were configured as one offs — with specific solutions to problems — that had to be documented via ticketing system —systems are siloed and often unique to different environments
- NEW IDEA PROPOSED IN 2012 at the CERN conference; is pets versus cattle — pets are unique and require special needs and caring — whereas with cattle: they are expendable and easily replaced
- THE IDEA CAN BE ILLUSTRATED LIKE THIS - server went offline — IF causes a major disruption — worrying about backups, scheduled downtime, or manual reconfiguration— needs an immediate response, you have PETS
- BUT IMAGINE that the offline server goes unnoticed by the end user — because the system can handling failures like that so another server picks up the slack — it’s easy to kill the misbehaving server and bring up another, then you have CATTLE
- THIS (SEMI) POST-VIRTUALISATION MODEL — idea isn’t right for every server or every server or service (database, caching) — so we’ll still need pets around— but having more cattle than pets will make things more agile, predictable and controlled
- ADMINISTRATION OF CATTLE SERVERS — focuses on a self-service, collaborative, API-driven architecture — small, automated servers can scale-out / horizontally — on commodity hardware and open source software
- FOR CATTLE, GENERIC SERVERS RULE — simple to repair / replace — from a data center perspective, ordering and planning is predictable — scaling out is easier and less expensive than before
- PUSHING THAT IDEAL FORWARD MORE IS THE OPEN COMPUTE PROJECT - working on standardized hardware — data center full of vanity free servers — 38% more efficient — 24% less expensive to build and run than current propriety offerings
- OPERATIONALLY THIS TIES IN WITH DEVOPS IDEALS using infrastructure as code — leaving behind the days where every single bit of the hardware and OS need to be tweaked — dev and ops helping each other for uptime and availability
- PVC — MOVING TOWARDS AGILE DEV — focusing on moving towards more open processes — allowing teams to make decisions about the software on their own— while they develop small, incremental releases —frequent delivery of products— helps moving to the cattle ideal
- USING OPEN SOURCE TO AUTOMATE solutions to handle configuration — using open APIs — configuration management tools like puppet — and command line tools to create a framework of systems for services, that can create and destroyed equally
- FROM AN OPEN SOURCE SCRIPT called stax — I’ve developed, I’m expanding on a simple idea to handle the framework to build cloud infrastructure — AWS, VPC, Route 53 — automatically
- THIS TIES IN WITH FORWARD THINKING in the form of using microservices, Docker containers, building immutable infrastructure and reusable ideas — focusing on working in sprints and more collaborate programming model
- THE CATTLE IDEA WILL IMPACT EXISTING IT, since it's using the Pet model —configuration management will radically different — environments will much more dynamic (but more predicable) — shift the burden to development to create apps that better handle tolerate issues on their own
- THERE WILL ALWAYS BE BARRIERS to adoption — people that are not comfortable with change — “this is how we’ve always done it” will not work… or scale —but rem we’ll still need some pets, just far less of them that we have now
- SUMMARY - PETS is the old ”Enterprise” way of computing - GUI-driven, using specialty hardware with silo’ed resources and knowledge — scaling vertically is the only way to go, and that won’t scale enough for today’s cloud demand — INFLEXIBLE !!!
- WHILE CATTLE COMPUTING is the new — API-driven, self-service/automated way — easy to scale-out horizontally on basic hardware and Open source software — much more collaborative and FLEXIBLE way to progress
- UTILIZING THE PETS VERSUS CATTLE model — processes and infrastructure can evolve, develop and be more agile — this will allow building iteratively with modern tools, cutting the time to market and simplifying deployments