Archive for March, 2016

[Book review] Infrastructure As Code

Thursday, March 24th, 2016

I am currently reading the book Infrastructure As Code

Treating Infrastructure as Code requires not just automation and tools, rather a complete change of mindset from the traditional approaches to Infrastructure management.

Key Lessons:

  • Treat Infrastructure as Software and Data
  • Avoid Snowflake servers
  • Automate everything
  • Automate everything..and let the provisioning, maintenance and lifecycle management happen automatically
  • Automate using specialized DevOps tools rather than custom scripts
  • Implement standard and time tested Software engineering practices such as Testing, Version Control, Change and Release Management etc. for Infrastructure

Automation fear spiral

If you do not follow automation consistently, your automation scripts can get out of sync. with the physical reality which will make the use of automation script even more risky, resulting in a fear spiral.

ch01-automation-fear-spiral

(Image courtesy: Chapter 1 of the book)

I plan to write a review of the book, once finished reading

Lessons Learned in Software Development

Thursday, March 24th, 2016

22 lessons, taken from the blog http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/

DEVELOPMENT

1. Start small, then extend. Whether creating a new system, or adding a feature to an existing system, I always start by making a very simple version with almost none of the required functionality. Then I extend the solution step by step, until it does what it is supposed to. I have never been able to plan everything out in detail from the beginning. Instead, I learn as I go along, and this newly discovered information gets used in the solution.

I like this quote from John Gall:  “A complex system that works is invariably found to have evolved from a simple system that worked.”

4. All new lines must be executed at least once. Before you are done with a feature, you have to test it. Otherwise, how do you know that it does what it is supposed to do? Often, the best way is by automatic tests, but not always. But no matter what, every new line of code has to be executed at least once.

Sometimes it can be hard to trigger the right conditions. Fortunately, it’s easy to cheat a bit. For example, the error handling on a database call can be checked by temporarily misspelling a column name. Or, an if-statement can be temporarily inverted (“if error” becomes “if not error”) in order to trigger something that rarely happens, just to make sure that code is run and does what it should.

Sometimes I see bugs that show that a certain line of code can never have been run by the developer. It can look fine when reviewed, but still not work. You avoid embarrassment if your policy is to always execute every new line you write.  => This one is my favorite

TROUBLESHOOTING

9. There will always be bugs. I don’t like approaches to software development that claim to “get it right the first time”. No matter how much effort you put in, there will always be bugs (the definition of a bug pretty much is: “we didn’t think of that”). A much better approach is to have a system in place that lets you quickly troubleshoot problems, fix the bugs and deploy the fixes.

COOPERATION

15. Face to face has the highest bandwidth. When discussing how to solve a problem, being face to face beats video, call, chat and email. I am often amazed at how much better the solutions are after discussing them in person with colleagues.

MISCELLANEOUS

19. Try it. If you are unsure of how a certain language feature works, it is easy to write a little program that shows how it works. The same applies when testing the system you are developing. What happens if I set this parameter to -1? What happens if this service is down when I reboot the system? Explore how it works – fiddling around often reveals bugs, and at the same time it deepens your understanding of how the system works.