I recently gave a Bright Talk session on adding security to the Agile Cloud/DevOps Development cycle. Part of this discussion addressed adding security testing as part of the process before, during, and even after continuous deployment. In other words, if we continually deploy, we must continually test. Our testing needs to be in the multi-minded parallel process we use for modern development, not the single-minded pipeline acceptable to most DevOps or agile processes. In the past, a team of people would test, each working independently to improve our software. We need similar capabilities within our automated processes. How do we achieve this? How do we add automated, continual testing? And where can we add this to our process or pipeline?
Transformation & Agility
Transformation & Agility concerns the utilization of the technical agility derived from the benefits delivered by virtualization and cloud computing, coupled with Agile Development practices that improve business agility, performance, and results. This includes the agility derived from: (Read More)
- The implementation of Agile and DevOps methodologies
- The application and system architectures
- The implementation of IaaS, PaaS, and SaaS clouds
- Monitoring of the environment, coupled with processes for resolving problems quickly
- Having continuous availability through the use of high-availability and disaster recovery products and procedures
Transformation covers the journey from A to Z and all points between: how you get there and the roads you will travel; how decisions made on day zero or one, or even day three, will affect later decisions; and what technical, operational, and organizational pitfalls can be associated with an implementation. We examine what tool sets are required for Agile Cloud Development, and it delves into other aspects of Agile Development that integrate with cloud computing, SaaS, and PaaS environments, including DevOps, Scrum, XP, and Kanban.
In a recent Twitter conversation, I asked if serverless is anything new, and if so, where are the documents expressing what is new about it. I was asked in reply if I needed a document to understand the difference between Uber and taxicabs. That got me wondering: is the serverless movement a business plan, or is it an approach to technology? If it is a business plan, then it is about how to make money; if it is an approach to technology, it is about architecture. It could also be a combination of the two. Serverless is also known as servicefull. But before we delve further, let us consider the difference between Uber and taxis.
Can you believe that we are over halfway through 2016? With summer in full swing and VMworld 2016 right around the corner, I thought it would be worthwhile to take a look at how VMware is doing and to offer some midyear insights.
Eric Wright of VMTurbo wrote about the death of root cause analysis (RCA) with the rise of microservices. I take exception to this, as microservices aren’t really all that new. Even what’s being called “serverless computing” isn’t particularly new. However, that’s a discussion for another time. The point of RCA is to find the real reasons for failures. I don’t see how using microservices changes this. All we’ve done is add more layers to delve through to find the true root cause of a problem.
In my continual quest for knowledge and current news about virtualization and cloud computing, Deirdre Mahon’s article “Cost or agility: What is cloud’s true purpose?” caught my attention. I’d like to address the same cost or agility theme, but focus in on private clouds instead of the public cloud. My assessment is based on a more specific scenario, in which a company or corporation has presented its business units with the option of utilizing a shared infrastructure, in addition to the option of the public clouds that are readily available in the current technology marketplace.
I recently spent four months mired knee-deep in a large enterprise transformation project, analyzing and working directly with the customer on a bloated application portfolio rationalization. This isn’t easy, especially with a very large, diverse enterprise. Companies of this type have multiple business areas, some of which in turn have multiple business units, each with its own complexities and quirks. These areas and units each have their own versions of shadow IT. Further, in the name of being more productive, they may choose to use applications that aren’t known or supported by the central IT organization.