If you help other people solve problems, you may have run into this phenomenon: a person gleefully tells you how messed up their environment is. Processes make no sense, roadblocks are everywhere, and all previous attempts to make things better have failed. As you explore the details, you talk about directions to try. But every suggestion is met with an explanation of why it won't work. I say that these folks are "

CRC I find the old object-oriented design technique of CRC Cards to be useful when defining service designs. CRC is short for "Class, Responsibilities, Collaborators." It's a way to define what behavior belongs inside a service and what behavior it should delegate to other services. Simulating a system via CRC is a good exercise for a group. Each person takes a CRC card and plays the role of that service.

My daily language is Clojure. One of the joys of working in Clojure is its great core library. The core library has a wealth of functions that apply broadly across data structures. A typical function looks like this: (defn nthnext "Returns the nth next of coll, (seq coll) when n is 0." {:added "1.0" :static true} [coll n] (loop [n n xs (seq coll)] (if (and xs (pos? n)) (recur (dec n) (next xs)) xs))) I want to call your attention to two specific forms.

While reading Bryan Cantrill's slides from Papers We Love NYC, I was struck by something. One of the very first slides says: The traditional UNIX security model is simple but inexpressive. The papers go on to describe a progression of techniques to isolate processes from the host environment to greater and greater degrees. It began with the ancient precursor 'chroot', through Jails, and Zones. Each builds upon the previous work to improve the degree of isolation.

Please understand, dear Reader, that I write this with positive intention. I'm not here to impugn any person or organization. I want to talk about some decisions and their natural consequences. These consequences seem negative to me and after reading this post you may agree. When an established company faced a technology innovation, they often create a new team to adopt and exploit that innovation. During my career, I've seen this pattern play out with microcomputers, client/server architecture, open systems, web development, agile development, cloud architecture, NoSQL, and DevOps.

Here's a syllogism for you: Every technical review process is a queue Queues are evil Therefore, every review process is evil Nobody likes a review process. Teams who have to go through the review look for any way to dodge it. The reviewers inevitably delegate the task downward and downward. The only reason we ever create a review process is because we think someone else is going to feed us a bunch of garbage.

Every single person I've heard talk about Continuous Delivery says you have to change your system's architecture to succeed with it. Despite that, we keep seeing "lift and shift" efforts. So I was happy to be invited to join a panel to discuss architecture for Continuous Delivery. We had an online discussion last Tuesday on the C9D9 series, hosted by Electric Cloud. They made the recording available immediately after the panel, along with a shiny new embed code.

During this morning's drive, I crossed several small overpasses. It reminded me that the American Society of Civil Engineers rated more than 20% of our bridges as structurally deficient or functionally obsolete. That got me to thinking about how we even know how many bridges there are in a country as large as the U.S. Some time in the past, it would require an army of people to go survey all the roads, looking for bridges and adding them to a ledger.

Back in April, I had the good fortune to speak at Craft Conf in lovely Budapest. It's a fantastic conference that I would recommend. During that conference, Randy Shoup talked about his experience migrating from monoliths to microservices at EBay and Google. David, one of the audience members asked an interesting question at the end of Randy's talk. (I'm sorry that I didn't get the full name of the questioner… if you are reading this, please leave a comment to let me know who you are.

When I was at Totality, we treated an outage in our customers' content management system as a Sev 2 issue. It ranked right behind "Revenue Stopped" in priority. Content management is critical to the merchants, copy writers, and editors. Without it, they cannot do their jobs. For some reason, we always treated dev environment or QA environment issues as a Sev 3 or 4, with the "when I get around to it"