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 have seen far too many definitions of the term DevOps. Everyone, including myself, has their own definition. Worse, I have seen even more interpretations of what “doing DevOps” means within enterprises. Here are a few examples of what some people think DevOps is:
- Automating infrastructure
- Building out CI/CD pipelines
- Writing Chef scripts
- Creating a new silo called DevOps
- Doing anything on AWS
All of the above-mentioned items are tasks that are common when a company embraces DevOps philosophies but by themselves are not DevOps. DevOps is much bigger than these specific tasks.
Every day, IT professionals live and breathe applications, yet our focus for operational tools is a single container, virtual machine, database, etc. How do these items map to the application in use? Even the monolithic-looking applications of yesterday were actually made up of services. Those services will be reborn as microservices within the applications of tomorrow. How do we make this transition? Is it possible with a container as a service model? Or should we scratch the past and start over?
I hear that vendors are bundling cloud services with their other software licensing deals, and I have some thoughts about why. Azure credits are being bundled into Microsoft software license deals. Oracle customers can buy cloud credits as a way of avoiding problems that stem from database software licensing true-ups. There are a couple of ways of looking at such practices. One is that these credits are a great way of getting customers hooked on your cloud. Oops, I meant to say a great way of helping customers learn the value of your cloud. The less positive perspective is that the largely unused credits inflate the cloud services’ revenue without customers actually using the cloud. Naturally, the reality is more complex. I suspect that these are the primary reasons for bundling cloud services into license deals.
Recently, we upgraded our cloud environment. This raises the question, “What is wrong with the environment after an upgrade?” As tools improve, we get new warnings, messages, and analytics. This often leads to a decision to ensure that after the upgrade, all monitoring, alerts, and other diagnostics show green across the board. Is this required, desirable, and even warranted? Wouldn’t it make sense to understand a change between releases first, before blanket acceptance?
The use of the cloud is not governed by technology so much as it is governed by cost: the cost of on-premises management, support, expertise, and environment vs. the cost of cloud services and outsourced expertise, management, etc. The cost differential must be high enough in the short term to allow it to become valid in the long term. There are lots of cloud calculators out there. Since Apple, Dropbox, and others have changed clouds or moved to their own data centers, what does this tell us about the future of cloud?
Building a private cloud was a high priority for a number of organizations in 2014. This priority carried over into 2015 because it is hard to execute. For many organizations, it has carried over again into 2016. Of course, the definition of a private cloud has changed in that time, too. Some organizations are happy simply to have consistent VMs deployed in response to a helpdesk ticket. Other organizations aspire to have the AWS in their own datacenter. One significant trend is the use of public cloud services to manage on-premises private clouds. The other trend is OpenStack in the enterprise, rather than only in academia and hyperscale where it started.