The title of this article is “In the Hybrid Cloud, Your Role Matters, but…,” and there is a big “but” there. How you use your role is what really matters. Whether you are a cloud, virtualization, or container administrator, evangelist, or architect, how you use your role makes or breaks the secure hybrid cloud. We have written a lot about technology, but it’s the people who really make the technology a win for the business. It is the processes you develop that make the difference. It is the roles you entrench that can hurt your prospects. So, how do we eliminate the “but”?
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.
I want to preface this post with a quote from a movie to set the stage. Bonus points for guessing the movie the quote is from.
Captain: Define “hoe-down.”
Ship’s Computer: Hoe-down: A social gathering at which lively dancing would take place.
[AUTO appears near the captain]
Captain: AUTO! Earth is amazing! These are called “farms.” Humans would put seeds in the ground, pour water on them, and they grow food—like, pizza!
When we scale things up to handle ever-larger quantities of data, we also scale up the number of issues related to the increasing pace. We’re dealing with this with fewer tools and, quite frankly, less knowledge We’ve seen changes in security (visit our latest podcasts on security and scale). We have seen changes in operations. We have also seen changes in development. Scale changes everything. But how so?
Software-defined storage (SDS) has usually meant storage that augments, optimizes, aggregates, and presents some form of cloud gateway. It is storage manipulated by an automation with an orchestration layer that ties differing data functions together. The ultimate in automation and orchestration for storage is the inclusion of Docker. Docker, or any container technology, needs storage—persistent storage. How storage is presented to Docker is unimportant to Docker. It is, however, important to the storage team. SDS is about making storage simpler by reusing, improving, or automating delivery. How does your storage fit with Docker?
It seems to be fashionable to be a software company. In fact, we hear statements that every company must be a software company. The logic is that software is allowing companies to do business faster than in the past. Software-driven design and manufacturing allow faster product development and shorter time to market. This last part is undoubtedly true: businesses are reaping great benefits from new software techniques. But are they really software companies?
When I look at large tech companies, I always get the feeling that they have a strategy based on maximizing revenue from one or two core products. Every decision about the other products tends to be made on the basis of protecting or increasing sales of these core products. It is usually hard for the company to accept that the central products are past their prime. This is the core of the innovator’s dilemma: protecting the goose that lays the golden egg leaves you exposed when the goose dies. In the end, the large company usually gets disrupted by a smaller player with no legacy to protect. Very occasionally, companies will allow themselves to self-disrupt, building a new core product before the golden goose is dead. It looks to me like Microsoft has decided to build a new golden goose: Azure.