In my last article, I spent a little time talking about the difference between automation, which is an automated task or scripted solution to perform a task, and orchestration, which is the complete process. I topped it all off with a discussion about how DevOps is a philosophy driving orchestration. For this article, I want to focus in on the some of the most common tools of the trade behind the automation and orchestration for different types of environments.
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 part one of Cost to Build a New Virtualized Data Center, we discussed the basic software costs for a virtualized data center based on VMware vSphere 6.0, Citrix XenServer 6.5, Microsoft Hyper-V 2012 R2 and 2016, and Red Hat. If you missed that, please click here to review before continuing.
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?