Devops in an application-centric cloud world

opinion
Jul 31, 20154 mins

The model changes in the new world of cloud native applications

The application-centric cloud development model becomes a devops approach to managing applications. Traditional cultural differences between developers and operations are very pronounced in the current information technology environments, but devops brings forth a blended approach to moving applications and a much quicker and more agile approach to the application-centric cloud.

Devops also makes both sides responsible for the success of the application. It’s not only true for an application cloud, but also for the third platform that IDC calls the new environment, or the bifurcated platform, as Gartner calls it. The reason for the new model is that one cannot wait for the cycle times that were created by the old model to facilitate the service level agreements that most companies need to be competitive.

In the new model, developers can develop the code or application and can deploy them in production without having another group involved in the process. That’s why the term “developer operations” evolved. The applications deployed can be updated extremely quickly because there is no need for anything other than quality standards that are higher than the standards in the postmodern dev ops environment.

Operations take on a whole new role in this environment as well, ensuring quality and administering the system so that the deployed applications are seamless and productive. Change management still resides with operations, but the operations group must work very closely with developers as they move their code to production. They also have to be totally cognizant of the impact of changes and ensure that the developers are testing in a devops environment well enough to ensure success. The dependencies of composable applications are resolved during development, which saves operations from having to solve problems when an application moves to development operations.

That is why platforms such as OpenShift or Cloud Foundry become critical in the framework that is put in for devops to be consistent with all new languages, databases, and tools. Since not everything is going to move to an application-centric cloud immediately, the operations group and developers have to continue working in the current structure, with the application-centric cloud being an overlay to the current environment. Clearly, this will save the operations group a significant amount of time but, again, you need to have a bifurcation of the group so that devops can flourish.

In both environments, it’s important to manage problems within a critical situation group that deals with issues of availability and application SLAs. Problem management will never go away in any model. Even though some articles promise nirvana from this model, getting there will be evolutionary, not revolutionary.

This model enables facile deployment and shared responsibility, not responsibility for one group over the other. When working with financial corporations, clearly, executives must deal with a cultural divide. The lines were drawn a long time ago, and the blending of groups requires the reassignment of people into each group so they can learn what the other group does.

Also, when doing agile development as part of a multidisciplinary operations team, the developers, analysts, and businesspeople take this to a whole new level. Lately, I have seen many companies talking about agile and forcing it into a model that fits the old IT. Most companies believe this will sustain them in the future 

In the new environment, I have seen open source products like Cloud Forms, Puppet, and Chef used to manage the environment. As previously stated, the tools are not the issue; the mindset needs to change to a share all environment where success comes from rapid application development and deployment. This would enable system administrators and developers to move to a new level of application deployment. Each group will bring its strengths and weaknesses to the new infrastructure, and this will enable a world of application centricity to become a reality.

Sam Greenblatt is a consultant to technology companies to define strategies, and offers technology services beyond the company's business strategy. He will focus on the strategic requirements of clients' businesses by working with them to determine long term technology-related decisions and create the appropriate operating model. Mr. Greenblatt is a Technologist in Residence at several technology companies where he uses his background as technologist and his history of successfully helping companies bring technology to market by helping the management team of these companies source and evaluate potential technology, particularly in areas where he applies his background.

Sam served as CTO and General Manager of Engineering Solutions at Dell providing solutions, to have strong alliances, develop cross-line of business offerings and offer a cohesive architecture that will make customers’ offerings run better with the workloads that meet these needs. He is a recognized expert in Object Technology, IaaS, PaaS, and HPC (Red Hat OpenStack, Azure, HyperV, VMware). He built solutions based on Cloud, Analytics, Big Data, and Enterprise Applications (SAP and Oracle). He was chief architect and technologist at the Enterprise Solution Group was involved in the architecture, communication and technical promotion of Dell's Enterprise family of products. Sam has served on USDL (Linux Foundation) 4 years, Object Management Group (11 years), Eclipse Board (1 Year), and the DMTF Board 2 Years. He is the primary inventor on 4 US Patents in Object Technology. He was a CTO at Hewlett Packard, Candle Corporation and Chief Innovation Officer at Computer Associates. Sam also was an adjunct professor of Computer Science at both Temple University and LaSalle University.

The opinions expressed in this blog are those of Sam Greenblatt and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author