What do you think?
Rate this book
Infrastructure as Code: Dynamic Systems for the Cloud Age
Just five years ago, infrastructure as code was a new concept for many companies. Today, even banks, governments, and other highly regulated organizations are moving to the cloud, leading teams everywhere to build up large, complex infrastructure codebases. With this practical book, Kief Morris of ThoughtWorks shows you how to effectively use principles, practices, and patterns pioneered by infrastructure and development teams to manage cloud age infrastructure.
Ideal for system administrators, infrastructure engineers, software developers, team leads, and architects, this insightful second edition demonstrates the tools you need for implementing infrastructure as code. You'll learn about the platforms and tooling involved in creating and configuring infrastructure elements, patterns for using these tools, and practices for making infrastructure as code work in your environment.
In four parts, this book covers:
Foundations: Understand how to use Infrastructure as Code to drive continuous change and raise the bar of operational quality. These chapters lay out a framework for the various tools and technologies involved in building platforms to run software in the cloud.
Working with infrastructure stacks: These chapters introduce practical patterns and approaches for defining, provisioning, testing, and continuously delivering changes to infrastructure resources. This includes managing and configuring environments and sharing infrastructure code.
Working With Servers And Other Application Runtime Platforms: Discover patterns for provisioning and configuring servers and clusters for deploying applications.
Working With Larger Systems and Teams: When you have multiple teams building and using cloud infrastructure, you need to consider workflows and governance, as well as architectural patterns for creating and managing many different infrastructure elements.
Ideal for system administrators, infrastructure engineers, software developers, team leads, and architects, this insightful second edition demonstrates the tools you need for implementing infrastructure as code. You'll learn about the platforms and tooling involved in creating and configuring infrastructure elements, patterns for using these tools, and practices for making infrastructure as code work in your environment.
In four parts, this book covers:
Foundations: Understand how to use Infrastructure as Code to drive continuous change and raise the bar of operational quality. These chapters lay out a framework for the various tools and technologies involved in building platforms to run software in the cloud.
Working with infrastructure stacks: These chapters introduce practical patterns and approaches for defining, provisioning, testing, and continuously delivering changes to infrastructure resources. This includes managing and configuring environments and sharing infrastructure code.
Working With Servers And Other Application Runtime Platforms: Discover patterns for provisioning and configuring servers and clusters for deploying applications.
Working With Larger Systems and Teams: When you have multiple teams building and using cloud infrastructure, you need to consider workflows and governance, as well as architectural patterns for creating and managing many different infrastructure elements.
427 pages, Paperback
First published November 25, 2015
250 people are currently reading
1,473 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 44 reviews
April 2, 2017
The fundamental promise of the book can be summarized by the following (page 258)
Automate Everything
=================
1. Redesign or reconfigure things so the task isn't necessary at all.
2. Implement automation that handles the task transparently, without anyone needing to pay attention.
3. Implement a self-service tool so that the task can be done quickly, by someone who doesn't need to know the details, preferably the user or person who needs it done.
4. Write documentation so that users can easily carry out the task on their own.
As usual, things are easier said than done, "Infrastructure as Code: Managing Servers in the Cloud" manages to describe the challenges, as well as some practical methods to build solutions to deliver in today's fast-paced IT infrastructure building and management.
After the first few introductory chapters that lay down the basic definitions and context, the author goes on to describe patterns and best practices for building server templates, managing configuration and changes to configuration, as well as the pitfalls you might encounter when you move from a traditional system administration mentality to dynamic, automated "infrastructure as code" perspective. You might also find the chapters dedicated to testing infrastructure changes, change management pipelines for infrastructure, and continuity for infrastructure particularly useful.
If you're building / managing a dynamic and flexible information system infrastructure in the cloud or on premise, regardless of your particular tool choice for automation, you'll find yourself facing the challenges described in this book, and therefore the outlined patterns will apply to your problems to a great extent. Therefore, I can easily recommend this book to any IT professional in that position.
Automate Everything
=================
1. Redesign or reconfigure things so the task isn't necessary at all.
2. Implement automation that handles the task transparently, without anyone needing to pay attention.
3. Implement a self-service tool so that the task can be done quickly, by someone who doesn't need to know the details, preferably the user or person who needs it done.
4. Write documentation so that users can easily carry out the task on their own.
As usual, things are easier said than done, "Infrastructure as Code: Managing Servers in the Cloud" manages to describe the challenges, as well as some practical methods to build solutions to deliver in today's fast-paced IT infrastructure building and management.
After the first few introductory chapters that lay down the basic definitions and context, the author goes on to describe patterns and best practices for building server templates, managing configuration and changes to configuration, as well as the pitfalls you might encounter when you move from a traditional system administration mentality to dynamic, automated "infrastructure as code" perspective. You might also find the chapters dedicated to testing infrastructure changes, change management pipelines for infrastructure, and continuity for infrastructure particularly useful.
If you're building / managing a dynamic and flexible information system infrastructure in the cloud or on premise, regardless of your particular tool choice for automation, you'll find yourself facing the challenges described in this book, and therefore the outlined patterns will apply to your problems to a great extent. Therefore, I can easily recommend this book to any IT professional in that position.
December 4, 2016
This is an excellent book. If so, you may ask why did it take me so long to read it? Well, because reading it depressed me. My current gig is so far off from the ideals & ideas presented in this book that I just had to take breaks from reading it. Yes, we're doing the automation sort of, but little to no automated testing. No real push on automated pipelines. No real organization change towards "two pizza teams", microservices or "you build it you run it." That's what depresses me. We've mostly just taken as Keif Morris terms it, old iron age practices and plopped them down in the cloud.
OK enough whining. The book covers quite well all the aspects of building infrastructure as code on dynamic infrastructure, not down in the deep technical weeds, but deep enough that you understand the concepts, patterns and anti-patterns. I did very much enjoy it, when I wasn't being depressed, and learned a lot.
OK enough whining. The book covers quite well all the aspects of building infrastructure as code on dynamic infrastructure, not down in the deep technical weeds, but deep enough that you understand the concepts, patterns and anti-patterns. I did very much enjoy it, when I wasn't being depressed, and learned a lot.
November 10, 2021
Very pragmatic book regarding infrastructure in general.
There are some rather valuable pieces of advices on how to create and segment the whole enterprise infrastructure in order to mitigate risks and increase the level of autonomy.
Sometimes it gets a bit repetitive, but I think one can just ignore that!
There are some rather valuable pieces of advices on how to create and segment the whole enterprise infrastructure in order to mitigate risks and increase the level of autonomy.
Sometimes it gets a bit repetitive, but I think one can just ignore that!
April 4, 2021
Livro muito bom p/ quem vem do contexto de administração de sistemas clássicos e está na jornada de infraestrutura como código. O livro é mais orientado, talvez pela data, ao mundo antes do kubernetes então orquestração de containers não é algo q vc vai encontrar aqui mas as bases de conhecimento p/ levar a esse contexto estão.
January 15, 2020
Kief's book is a fundamental work on modern approach to managing infrastructure. It borrows heavily from software development best practices. The book clearly outlines good practices and anti-patterns. However this field is still emerging and changing quickly. Because of that it wouldn't be practical to give specific advise on implementation of principles described. This is an exercise left to the reader. The book provides excellent theory leaving you wanting the same level of practical advice on implementation of the described principles. Hopefully this is filled by more books in this space.
January 17, 2020
I must be honest, I was expecting something more technical, hands-on. It is instead a long discussion about history of cloud and, mainly, how infrastructure evolved from do-it-all-manually to write-code-to-do-it.
The author touches many different topics and techs, including AWS, Puppet, Chef, ... but doesnt dive deep into anything. Mind, I am not saying this is a boring or not useful text. It a nice introduction and I am sure it would even be better as a talk at the University to students.
The author touches many different topics and techs, including AWS, Puppet, Chef, ... but doesnt dive deep into anything. Mind, I am not saying this is a boring or not useful text. It a nice introduction and I am sure it would even be better as a talk at the University to students.
January 6, 2020
Infrastructure as code is about treating infrastructure as a software system, which means the dynamic infrastructure platform needs to have certain characteristics. The platform needs to be:
� Programmable
� On-demand
� Self-service
Kief's book is a fundamental work on modern approach to build, run and manage dynamic infrastructure. In this book, you can find best practices and patterns to build and run a dynamic infrastructure that is based on new infrastructure technology- cloud, virtualization, and automation. Book does not down into the details of technical implementation with specific tools and just explains about best practices and patterns. Author also talks about challenges of dynamic infrastructure and provides advice to dealing with them.
This book could be ideal for system administrator, infrastructure engineers, team leaders and architects.
� Programmable
� On-demand
� Self-service
Kief's book is a fundamental work on modern approach to build, run and manage dynamic infrastructure. In this book, you can find best practices and patterns to build and run a dynamic infrastructure that is based on new infrastructure technology- cloud, virtualization, and automation. Book does not down into the details of technical implementation with specific tools and just explains about best practices and patterns. Author also talks about challenges of dynamic infrastructure and provides advice to dealing with them.
This book could be ideal for system administrator, infrastructure engineers, team leaders and architects.
August 14, 2017
It is not a bad book at all, but I was hoping for more really.
However it would really help you if you are a SysAdmin in a big corporation or the lead of SysAdmins in a big corporation.
For small to mid companies or startups you´d fine usefull information, pitfalls to avoid. But if you are up to date with current state of the art tools and trends you won't nothing new besides some interesting tools (e.g for infrastructure testing) and insights.
I'm keeping it in my "take advice" book shelf since it really makes for a go-to book for consulting.
One thing it felt a bit out of place where the last chapter and some other hints on people management. Wasn't really the place or in fact I wasn´t the target audience, since I have a dev background and the book explained a great deal of dev practices taken to sysadmins.
If you are a dev, it deserves at least a quick look. If you are a sysadmin still working on bare metal or in pre-cloud big corporations, go read it.
However it would really help you if you are a SysAdmin in a big corporation or the lead of SysAdmins in a big corporation.
For small to mid companies or startups you´d fine usefull information, pitfalls to avoid. But if you are up to date with current state of the art tools and trends you won't nothing new besides some interesting tools (e.g for infrastructure testing) and insights.
I'm keeping it in my "take advice" book shelf since it really makes for a go-to book for consulting.
One thing it felt a bit out of place where the last chapter and some other hints on people management. Wasn't really the place or in fact I wasn´t the target audience, since I have a dev background and the book explained a great deal of dev practices taken to sysadmins.
If you are a dev, it deserves at least a quick look. If you are a sysadmin still working on bare metal or in pre-cloud big corporations, go read it.
December 28, 2017
Good overview and harmonization
This book provides a nice overview of modern approach to build and run infrastructures. However, it is little to be gained from it for an experienced developer. Most things are common knowledge.
Of course any reader would get something new from this book, but time can be better invested.
This book provides a nice overview of modern approach to build and run infrastructures. However, it is little to be gained from it for an experienced developer. Most things are common knowledge.
Of course any reader would get something new from this book, but time can be better invested.
July 20, 2016
Best book on Infrastructure as Code currently available.
November 10, 2016
This is a great read for anyone in Ops, DevOps, or any other discipline that involves to running & maintaining software. The book covers a lot of ground, both in the infrastructure as code space, and in DevOps generally, and is full of wonderful insights. The drawback to this broad scope is that there aren't many examples of real code, and the examples that are there tend to be superficial and simple. There are some subtle concepts that could have been demonstrated by showing real code, but that's probably hard to do in a book that covers so many different topics.
Here are some of the key idea in the book:
* We've moved from the "Iron Age" of metal servers to the "Cloud Age" of virtual servers.
* Core principles of infrastructure as code: Systems can easily be reproduced; Systems are disposable; Systems are consistent; Processes are repeatable; Design is always changing.
* Core practices of infrastructure as code: Use definition files; Self documented systems and processes; Version all the things; Continuously test systems and processes; Small changes rather than batches; Keep services available continuously.
* Go further than just preventing a system from breaking; try to build systems that are "antifragile". That is, systems that get stronger when under stress. Just as a muscle gets stronger from frequent exercise, a DevOps team gets strong by frequent deployments.
* Go further than just automating a system; make it "autonomic". Just as you have autonomic systems in your body (e.g. heart rate, breathing) that run and react completely by themselves, while still allowing conscious input, you should have autonomic systems in your software.
* An interesting thought exercise on disaster recovery: what would happen to your company if one of the vendors you used was entirely wiped out? What if AWS shut down or raised prices by 100x? What about GitHub? What if they got hacked? Would your business survive?
* Successfully using infrastructure as code and adopting DevOps requires a shift in mindset. The Ops team should no longer act like a gatekeeper or babysitter for production. Instead, the Ops team is responsible for being experts, setting standards, build tools that others can use to implement those standards, and educating other teams on these standards and tools. Those other teams are the ones responsible for deploying their code--and, just as importantly, keeping it up and running. This is obvious in other disciplines. For example, a security team can't effectively secure your code for you. You have to do it yourself. All the security team can do is create tools, teach you to use them, and provide review, auditing, and testing. Although not as obvious, the same is true with Ops: they can't effectively run your code for you.
Some of my favorite quotes from the book:
"Infrastructure as code is an approach to infrastructure automation based on practices from software development. It emphasizes consistent, repeatable routines for provisioning and changing systems and their configuration. Changes are made to definitions and then rolled out to systems through unattended processes that include thorough validation."
"An operations team should be able to confidently and quickly rebuild any server in their infrastructure. If any server doesn’t meet this requirement, constructing a new, reproducible process that can build a server to take its place should be a leading priority for the team."
"A fundamental difference between the iron age and cloud age is the move from unreliable software, which depends on the hardware to be very reliable, to software that runs reliably on unreliable hardware."
"The hallmark of an infrastructure team’s effectiveness is how well it handles changing requirements."
"A team’s ability to work with configuration that’s managed internally by a tool is limited to interactions that the tool supports. Configuration externalized as text files, on the other hand, can be accessed and manipulated by any off-the-shelf tool. You can edit them with whatever text editor you prefer, manipulate them with common command-line tools, and write your own scripts to manage them. The ability to use this vast ecosystem of text file–friendly tools to bear on infrastructure configuration gives a team far more control than it can have with a proprietary tool."
"You know your infrastructure definition is becoming monolithic when people become afraid to make a change. When you find yourself considering adding organizational processes to coordinate and schedule changes, stop! There are ways to organize your infrastructure to make it easier and safer to make changes. Rather than adding organizational and process complexity to manage complex infrastructure designs, redesign the infrastructure to eliminate unnecessary complexity."
"The enabling idea of Infrastructure as Code is that the systems and devices used to run software can be treated as if they, themselves, are software. This makes it possible to use tools and working practices that have been proven in the software development world."
"The great thing about CD is that the decision to go live becomes a business decision, not a technical one. The technical validation has already been done: it happens on every commit."
"“DevOops�; the ability to automatically configure many machines at once gives us the ability to automatically break many machines at once."
"The big shift is away from working directly on servers and infrastructures, to working on them indirectly. An infrastructure engineer can no longer just log onto a server to make a change. Instead, they make changes to the tools and definitions, and then allow the change management pipeline to roll the changes out to the server. This can be frustrating at first. It feels like a slower, more complicated way to do something simple."
"The aim is to have infrastructure management systems that work autonomically. In physiology, autonomic functions happen without conscious effort (e.g., breathing or heart rate). You might be able to override some of these (e.g., by holding your breath). But you don’t normally need to think about doing it. Autonomic automation is the secret to making infrastructure as code work reliably. When the team finds a new web server configuration option that improves security, they embed that into their automation tooling. They know that it will be applied to all relevant servers, current and future, without anyone having to think about it again."
"When a team adopts infrastructure as code, its members should find themselves spending less time carrying out routine activities, and more time improving the system itself."
"An interesting thing about a dynamic infrastructure platform is that it looks a lot like unreliable infrastructure. Servers routinely disappear and are replaced. This happens when resources are automatically scaled up and down, and may even happen as a byproduct of the mechanism for making routine changes, deploying software, and running tests."
"Ideally, IT systems would be like a consumer automobile. You buy a new car off the assembly line, and periodically pay to keep it fueled and maintained, occasionally replacing parts as they wear out or fail. You don’t need to keep the engineers who designed and assembled the car on staff. In practice, modern IT systems are more like a Formula One race car. Each one is custom-built, even if they use standard parts and follow common patterns. It takes continuous work to keep it running well, patched and secure. And the needs that IT systems must satisfy are constantly changing, as the way technology is used by consumers and businesses is constantly changing. This in turn means that an organization’s IT systems must constantly change."
Here are some of the key idea in the book:
* We've moved from the "Iron Age" of metal servers to the "Cloud Age" of virtual servers.
* Core principles of infrastructure as code: Systems can easily be reproduced; Systems are disposable; Systems are consistent; Processes are repeatable; Design is always changing.
* Core practices of infrastructure as code: Use definition files; Self documented systems and processes; Version all the things; Continuously test systems and processes; Small changes rather than batches; Keep services available continuously.
* Go further than just preventing a system from breaking; try to build systems that are "antifragile". That is, systems that get stronger when under stress. Just as a muscle gets stronger from frequent exercise, a DevOps team gets strong by frequent deployments.
* Go further than just automating a system; make it "autonomic". Just as you have autonomic systems in your body (e.g. heart rate, breathing) that run and react completely by themselves, while still allowing conscious input, you should have autonomic systems in your software.
* An interesting thought exercise on disaster recovery: what would happen to your company if one of the vendors you used was entirely wiped out? What if AWS shut down or raised prices by 100x? What about GitHub? What if they got hacked? Would your business survive?
* Successfully using infrastructure as code and adopting DevOps requires a shift in mindset. The Ops team should no longer act like a gatekeeper or babysitter for production. Instead, the Ops team is responsible for being experts, setting standards, build tools that others can use to implement those standards, and educating other teams on these standards and tools. Those other teams are the ones responsible for deploying their code--and, just as importantly, keeping it up and running. This is obvious in other disciplines. For example, a security team can't effectively secure your code for you. You have to do it yourself. All the security team can do is create tools, teach you to use them, and provide review, auditing, and testing. Although not as obvious, the same is true with Ops: they can't effectively run your code for you.
Some of my favorite quotes from the book:
"Infrastructure as code is an approach to infrastructure automation based on practices from software development. It emphasizes consistent, repeatable routines for provisioning and changing systems and their configuration. Changes are made to definitions and then rolled out to systems through unattended processes that include thorough validation."
"An operations team should be able to confidently and quickly rebuild any server in their infrastructure. If any server doesn’t meet this requirement, constructing a new, reproducible process that can build a server to take its place should be a leading priority for the team."
"A fundamental difference between the iron age and cloud age is the move from unreliable software, which depends on the hardware to be very reliable, to software that runs reliably on unreliable hardware."
"The hallmark of an infrastructure team’s effectiveness is how well it handles changing requirements."
"A team’s ability to work with configuration that’s managed internally by a tool is limited to interactions that the tool supports. Configuration externalized as text files, on the other hand, can be accessed and manipulated by any off-the-shelf tool. You can edit them with whatever text editor you prefer, manipulate them with common command-line tools, and write your own scripts to manage them. The ability to use this vast ecosystem of text file–friendly tools to bear on infrastructure configuration gives a team far more control than it can have with a proprietary tool."
"You know your infrastructure definition is becoming monolithic when people become afraid to make a change. When you find yourself considering adding organizational processes to coordinate and schedule changes, stop! There are ways to organize your infrastructure to make it easier and safer to make changes. Rather than adding organizational and process complexity to manage complex infrastructure designs, redesign the infrastructure to eliminate unnecessary complexity."
"The enabling idea of Infrastructure as Code is that the systems and devices used to run software can be treated as if they, themselves, are software. This makes it possible to use tools and working practices that have been proven in the software development world."
"The great thing about CD is that the decision to go live becomes a business decision, not a technical one. The technical validation has already been done: it happens on every commit."
"“DevOops�; the ability to automatically configure many machines at once gives us the ability to automatically break many machines at once."
"The big shift is away from working directly on servers and infrastructures, to working on them indirectly. An infrastructure engineer can no longer just log onto a server to make a change. Instead, they make changes to the tools and definitions, and then allow the change management pipeline to roll the changes out to the server. This can be frustrating at first. It feels like a slower, more complicated way to do something simple."
"The aim is to have infrastructure management systems that work autonomically. In physiology, autonomic functions happen without conscious effort (e.g., breathing or heart rate). You might be able to override some of these (e.g., by holding your breath). But you don’t normally need to think about doing it. Autonomic automation is the secret to making infrastructure as code work reliably. When the team finds a new web server configuration option that improves security, they embed that into their automation tooling. They know that it will be applied to all relevant servers, current and future, without anyone having to think about it again."
"When a team adopts infrastructure as code, its members should find themselves spending less time carrying out routine activities, and more time improving the system itself."
"An interesting thing about a dynamic infrastructure platform is that it looks a lot like unreliable infrastructure. Servers routinely disappear and are replaced. This happens when resources are automatically scaled up and down, and may even happen as a byproduct of the mechanism for making routine changes, deploying software, and running tests."
"Ideally, IT systems would be like a consumer automobile. You buy a new car off the assembly line, and periodically pay to keep it fueled and maintained, occasionally replacing parts as they wear out or fail. You don’t need to keep the engineers who designed and assembled the car on staff. In practice, modern IT systems are more like a Formula One race car. Each one is custom-built, even if they use standard parts and follow common patterns. It takes continuous work to keep it running well, patched and secure. And the needs that IT systems must satisfy are constantly changing, as the way technology is used by consumers and businesses is constantly changing. This in turn means that an organization’s IT systems must constantly change."
Read
October 15, 2021I'm going to use this book as the clearing ground for another reading hobby I have: taking coding and coding-related books out of the library, flipping through them, and noting anything interesting. (Some flips are more flippy than others. This book covers a topic that I do not work on in an in-depth way, and so was more of a page-turner, in that sense, but man: that choice of animal on the cover.)
There's a few things you realize in programming world: (1) things move fast, so books are only of limited value. (Heck, code documentation is only of limited value, ultimately, because sometimes developers forget to update the docs -- if you really need to know what's going on, you've got to get into the code, which takes time.)
(2) Even people who have done something for years may have missed some little bit of behavior, and that's ok. I have multiple times in my short career showed something new to someone who was many years my senior, and the best responses have always been "oh, that's neat" or "that's interesting."
Put these two together and you get something like: technology moves fast, pick up what you can when you can -- because you're never going to go into a situation with perfect knowledge. (Or put another way, as in improv, in development you have to start sometimes without knowing everything, and through doing, learn.)
(Note: this principle can be taken too far, which is where you get people taking the wrong lesson: the lesson isn't "dive in before you're ready" alone, it's "prepare what you can, put your toe in to see what it's like, adjust your plans to dive accordingly.")
I can't keep track of the specific books I've flipped through recently, but there's been a few major topics, all related to my recent job change: Go, Kubernetes, SQL/PostgreSQL, Git, and everything else (mostly more abstract/generic topics like "writing clean code" or "what are microservices"). Most of these topics I know -- or at least have been professionally involved in for years -- but again: it's nice to go back and check things and learn some of the stuff that you may have missed while using the technology at hand.
(That said, special shout out to , which includes a section on "how to listen and connect to people when working remotely," which is one of those crucial skills that they don't teach much.)
There's a few things you realize in programming world: (1) things move fast, so books are only of limited value. (Heck, code documentation is only of limited value, ultimately, because sometimes developers forget to update the docs -- if you really need to know what's going on, you've got to get into the code, which takes time.)
(2) Even people who have done something for years may have missed some little bit of behavior, and that's ok. I have multiple times in my short career showed something new to someone who was many years my senior, and the best responses have always been "oh, that's neat" or "that's interesting."
Put these two together and you get something like: technology moves fast, pick up what you can when you can -- because you're never going to go into a situation with perfect knowledge. (Or put another way, as in improv, in development you have to start sometimes without knowing everything, and through doing, learn.)
(Note: this principle can be taken too far, which is where you get people taking the wrong lesson: the lesson isn't "dive in before you're ready" alone, it's "prepare what you can, put your toe in to see what it's like, adjust your plans to dive accordingly.")
I can't keep track of the specific books I've flipped through recently, but there's been a few major topics, all related to my recent job change: Go, Kubernetes, SQL/PostgreSQL, Git, and everything else (mostly more abstract/generic topics like "writing clean code" or "what are microservices"). Most of these topics I know -- or at least have been professionally involved in for years -- but again: it's nice to go back and check things and learn some of the stuff that you may have missed while using the technology at hand.
(That said, special shout out to , which includes a section on "how to listen and connect to people when working remotely," which is one of those crucial skills that they don't teach much.)
October 8, 2022
I think I've dipped into and applied enough of this book to mark is as 'read', but can't say I've read it cover-to-cover except the chapters on principles.
This is an excellent book for general infrastructure as code concepts and advice on good patterns of infrastructure as code. It's kind of on the same level of abstraction as the gang-of-four design patterns book was for object-oriented programming. Expect less 'this is how to use terraform' and more 'this is what great infrastructure-as-code looks like' So don't expect any deep-dives on particular tools but definitely expect development of your infrastructure-as-code tastes!
Would recommend to any infrastructure engineer, platform engineer, anybody with the words 'devops' in their job title and any developer using cloud infrastructure. I personally have used it as a handbook in multiple organisational contexts and as a reference during infrastructure design discussions.
Although one word of caution: make sure to get the latest edition! Cloud infrastructure moves fast and there is a large shift in content between the 1st and 2nd editions. I'm sure this will apply for any nth editions going ahead.
This is an excellent book for general infrastructure as code concepts and advice on good patterns of infrastructure as code. It's kind of on the same level of abstraction as the gang-of-four design patterns book was for object-oriented programming. Expect less 'this is how to use terraform' and more 'this is what great infrastructure-as-code looks like' So don't expect any deep-dives on particular tools but definitely expect development of your infrastructure-as-code tastes!
Would recommend to any infrastructure engineer, platform engineer, anybody with the words 'devops' in their job title and any developer using cloud infrastructure. I personally have used it as a handbook in multiple organisational contexts and as a reference during infrastructure design discussions.
Although one word of caution: make sure to get the latest edition! Cloud infrastructure moves fast and there is a large shift in content between the 1st and 2nd editions. I'm sure this will apply for any nth editions going ahead.
May 22, 2017
I started this just after finishing Continuous Delivery, and was looking for an update dealing with the advances in automatable infrastructure that have happened since CD was published. I came away a little disappointed, as the book seems to be geared towards bringing operations people to the world of software development, whereas I'm a software developer looking to learn more about infrastructure.
As a result, I found the book to be a relatively simple repetition of things I already know, or things I had just finished learning from CD. And to be fair, he does hint at this in the preface.
That said, it's still a good book that drives home good points. The key one is probably that you can and should treat an entire software project as software, regardless of how much hardware is incorporated. You just have to read a lot to get that drilled in.
As a result, I found the book to be a relatively simple repetition of things I already know, or things I had just finished learning from CD. And to be fair, he does hint at this in the preface.
That said, it's still a good book that drives home good points. The key one is probably that you can and should treat an entire software project as software, regardless of how much hardware is incorporated. You just have to read a lot to get that drilled in.
November 27, 2023
Overall, it is a fine book, yet it is very oriented towards traditional operational engineers, rather than software engineers; an example would be that agile and TDD, etc are explained very much in-depth whereas various network concepts are stated by the name, and as a software engineer looking to learn more about infrastructure and defining it as code, that made some parts of the book very obsolete.
However, the book does have great points and certain parts are of high value. I would recommend it, however, is a bit lengthy IMO, and there might be better books out there for people like me.
However, the book does have great points and certain parts are of high value. I would recommend it, however, is a bit lengthy IMO, and there might be better books out there for people like me.
April 5, 2024
There are a lot of great thoughts here and the start is a nice introduction to the whole Infrastructure as Code concept. Having said that, there are definitely whole sections comparing different options to common scenarios that would be better condensed as tables. It's wonderful how it tries to generalize from any particular technology, but it doesn't then get into a more technical engineering analysis and instead keeps at a level of generalizations I found that by 344 pages I just couldn't sustain interest in.
February 28, 2021
The main value from the book is in the patterns for transitioning to an automated way of configuring the infrastructure, accompanied by the principles, tactics and experiences to do so.
Although this version of the book had a few examples outdated (at the time of writing this review a second edition recently came up) and the way of doing infrastructure testing changed (diamond instead of pyramid), among other changes; the core is there, and its very valuable.
Although this version of the book had a few examples outdated (at the time of writing this review a second edition recently came up) and the way of doing infrastructure testing changed (diamond instead of pyramid), among other changes; the core is there, and its very valuable.
November 13, 2023
"Infrastructure as Code" by Kief Morris is insightful for cloud infrastructure management. Pros: It's thorough, covering concepts and tools effectively. The book is well-structured, guiding readers from basics to advanced topics. Its real-life examples help in grasping complex ideas. Cons: The depth of content can be daunting for beginners, and it assumes some prior knowledge in cloud computing. Some topics might feel a bit outdated, given the fast-paced changes in cloud technologies.
September 1, 2017
A very nice book to start managing infrastructure as a code. Has very helpful tips on the strategies to be adopted when doing this.
The book does not cover any one tool (Chef, Puppet or any other tool), it merely gives the techniques to be followed to ensure that this is a success.
Definitely a very good read.
The book does not cover any one tool (Chef, Puppet or any other tool), it merely gives the techniques to be followed to ensure that this is a success.
Definitely a very good read.
July 26, 2017
Подробное введение в современную "облачную" инфраструктуру и того разнообразие инструментов чтобы приложения хорошо масштабировались, были надежными и удобными для разработки. Все "модные слова" про docker, service discover и т.д объяснены.
March 16, 2019
Very well written and comprehensive book, even if it starts repeating the same concepts all over again after a while, applying them to different topics. Without all this repetitiveness, it would have been perfect.
August 31, 2020
Good theoretical overview of the key strategies and techniques to implement an "infra as code". This book is easily accessible to a non-expert audience and contains plenty of references if you want to dig further.
March 16, 2021
The book goes over all the different patterns and designs that go with implementing large scale cloud systems in modern ages. I think this is a must read for anyone willing to dive deep in Infrastructure as Code, similarly to books like Clean Code for programmers.
August 28, 2022
Il libro ha molti spunti interessanti ma a volte si perde in tecniche poco pratiche. Il focus è molto incentrato sulla gestione dei problemi legati alle macchine virtuali e si da poco spazio ad infrastrutture più cloud oriented, nonostante questo il tema viene trattato con estrema professionalità
November 2, 2017
Lots of in-depth information in this book. Recommend it for anyone interested in learning about Infrastructue as Code
March 30, 2018
Good introduction for beginners, but a bit too wordy.
July 31, 2018
Time good spend reading this book. Would recomnend for people into devops or infrastructure automation, or even managers, to see benefits of infrastructure put into code
October 1, 2019
Amazing book. What else? :-p
October 8, 2019
A bit rudimentary for an O'Reilly book. Filled in some gaps for me.
August 6, 2021
Casually describes so, so many problems that I have seen, a lot of which I have not recognized before.
Displaying 1 - 30 of 44 reviews
Can't find what you're looking for?
Get help and learn more about the design.