-
Jan
15thVirtualization & Abstraction : The New ParadigmThis post is inspired by this outstanding post by Chuck Hollis (@chuckhollis) and this one by Chad Sakac (@sakacc). Chuck mentions my favorite way to summarize what virtualization encompasses: “abstracts logical from physical”. What makes abstraction critical is that it breaks historical dependencies that develop as technologies are built over time. I have said this phrase hundreds of times over the last four years of my career and in my mind it translates into an incredible paradigm shift in data center approach over the next ten years. A good example of this is the push to service-oriented architecture design principles in the enterprise application space over the last decade. The whole gist was to enable business functionality to achieve independence and agility by breaking hard coded dependencies to platforms and systems. A loosely-integrated system can provide value to multiple business units by removing the overhead of inherited designs. Any ability to move quickly to market with business features brings competitive advantage. In simple terms, removing boundaries opens more opportunities. Virtualization is the same approach with the end goal of the four food groups (CPU, memory, storage, networking) becoming commodities that can used as needed and where needed. The status quo has been large CapEx investments in infrastructure where efficiency was limited by the boundaries of the physical needs and the return on labor cost to optimize. Even with a large team invested in tuning and sizing, the organic growth of the business can waste resources quickly as usage patterns change [...]
-
Nov
25thOptimization vs. Scaling: How virtualization affects the scorecardImage via Wikipedia Many times I have seen situations where an application or process grows incrementally to a point where it is no longer able to meet it’s SLAs (whether official or imaginary). The cause of this can vary but is usually: Overworked/Unbalanced teams - Too much effort dedicated to new feature-add and not enough to technical debt Poorly planned systems – Designs for immediate need without taking into account needs for things like instantiation or scaling of decoupled components. Poor maintenance/understanding – Lack of knowledge or effort to tune application/process to more effectively use resources. This can exist in both the application and infrastructure groups. Usually the performance degradation is known early on but accepted because the business users are not making a big enough stink; or at least not big enough to reduce the drive for new features. In addition, lack of monitoring and baselining of application performance is a critical problem. It eliminates the ability to effectively plan for growth and manage team resources. Eventually the impact reaches a point where someone significant (business executive) resets priorities to fix it (technical debt due date). Many options will be evaluated immediately, from trying to buy time by tuning components to finding misconfigurations. However if no easy answers exist, it usually comes down to two options. Optimize the application/process (Fix the code) Scale the application/process with faster hardware (Throw metal at it) Both of these options impact the same core factors: time and money. Depending on what time of [...]
-
Disclaimer