We live in interesting times. If I were to chart the increase in the number of customers asking for help with DevOps, that chart would look like a hockey stick, that same kind of hockey stick our CFOs are always dreaming of. If I added another line on the chart for the percentage of those companies that actually knew what DevOps was, it would be a flat line at the lower coordinates of the chart. What we are seeing is that everyone wants DevOps, but not everyone knows why or exactly what DevOps means. Continue reading The Value of DevOps in the Enterprise
Does this scenario sound familiar? A sprint team delivers another release on time and on budget. It boasts about how much its velocity has improved and how many story points it was able to cram into a two or four-week sprint. It shows its business partners a bunch of nice, pretty charts that illustrate how it is cranking out software and how agile the organization has become. The business partner is not impressed, however. Her competitors are crushing her by getting more rich features out each month. The competing products seem able to adapt on the fly and quickly address new requests from customers. The business partner asks the team to call out the major features delivered in the last release. Continue reading Agile Requires Architecture, Not Methodologies
There is an old saying, “the definition of insanity is to repeat the same thing over and over and expect a different result.” The way many enterprises are approaching the cloud, insanity would be a great way of classifying it. When we look across most enterprises, we see a collection of technologies from every era of computing. We have just about every vendor solution imaginable—often multiple versions of products from the same vendor—and a hodgepodge of architectures that makes spaghetti look organized.
One of the great advantages of the public cloud is its elasticity, the ability it gives systems to provision and deprovision resources as workloads increase and decrease. Much has been written about how building RESTful services is crucial to deploying elastic services in the cloud. I concur that writing code loosely coupled with the underlying infrastructure and abstracting things like business rules, business processes, and systems configurations into independent modules is a key to elasticity. What I have not seen discussed enough is how we should be abstracting the different types of server farms away from each other to eliminate tightly coupled dependencies between compute resources. Continue reading Designing for Elasticity
I have been building solutions on AWS since 2008, and even though that sounds like a long time, I have still only scratched the surface of what is possible in the cloud. Every few weeks I get another “Aha” moment when I see problems solved with cloud architectures that would be either too hard, not feasible, or too time-consuming to accomplish in a non-cloud environment. Here is my latest “Aha” moment. Continue reading Expand Your Thinking When Architecting in the Cloud
For many years, the focus in IT has been on building robust systems that invested heavily in avoiding failures. To accomplish this goal, methodical processes were implemented to guide IT through a list of known use cases so that systems could try to avoid failing and have a plan for recovery if a failure did occur. This approach often led to long delivery cycles and a high degree of complexity which in reality, increased the risk of failure and created fragile systems. Fragile systems are those systems that cannot adapt to unpredictable, volatile, and random events often referred to as “shocks to the system”. Continue reading Antifragile Systems: Designing for Agility vs. Stability