Cloud Zone is brought to you in partnership with:

My name is Bruno Terkaly and I am a Developer Evangelist in Northern California. Over the past few months I have been presenting a wide variety of demos and slides highlighting the wealth of new features in Visual Studio 2008. Bruno is a DZone MVB and is not an employee of DZone and has posted 51 posts at DZone. You can read more from them at their website. View Full User Profile

The DevOps Story - Why it is Really About Platform as a Service

04.18.2014
| 6675 views |
  • submit to reddit

Overview

The relationship between central IT and developers is being re-defined as the world adopts cloud technologies. The ultimate challenge is making central it feel secure while simultaneously giving developers freedom. IT wants to be able to control the deployment of applications so that there is consistency and adherence to policy. The policy could be related to PII or even the size of the VM that will host the application. There could also be cost considerations as well as monitoring and performance. Developers want to focus on their applications, their code. Developers don’t want to worry about public versus private cloud or with finding exactly their app should be installed.

It is about abstraction

More abstraction is needed if cloud computing is to really provide value. Ultimately, the technology will eliminate the need to login into specific VMs. This approach just doesn’t scale. In addition, the distinction between public and private clouds will need to disappear. VMs, whether they run on-premises or in the cloud, are just part of a big pool of available resources. At the end of the day, an enterprise has a specific number of VMs, an amount of memory, CPU, and storage. Managing these resources with a global perspective is what will reduce the time to market for applications and foster innovation.

I once wrote a blog post called, “Why platform as a service will rule the world.” It was pretty popular and got picked up by a number of different sites. Not surprisingly to me I’m seeing platform as a service rise to new levels.

Hello Apprenda

One of these companies in this space that provides platform as a service software that sits on top of cloud infrastructures is Apprenda (see http://www.apprenda.com). Although the lines are blurring between infrastructure as a service and platform as a service, it is clear that the industry is moving towards a more abstracted and automated approach to managing cloud resources, hopefully incorporating both on premises data centers as well as public data centers. It’s a matter of semantics about where infrastructure as a service leaves off and where platform as a service picks up.

Dev ops - the struggle between IT administrators and developers

The notion of platform as a service is directly related to what is now being called a devops story. A lot of what devops focuses on is the historically contentious relationships between IT administrators and developers. It is been well documented that developers want the freedom to innovate and don’t want to be concerned with the headaches of provisioning and the procuring of computing resources. IT administrators are about control, compliance, security, monitoring, problem resolution, orderly migrations to the public cloud, and cost containment.

Challenges with the Hybrid Cloud

There are some important challenges to overcome when managing hybrid cloud scenarios, whereby you have resources that lived in side of a company’s data center as well as having resources in a public data center. The trend in the industry is to carefully migrate on premises applications to the public cloud, mostly to reduce costs but also to provide flexibility and speed to developers acquiring needed computing resources to be able to innovate. But not everything can just be moved to the public cloud, especially where compliance is concerned.

Many applications have personally identifiable information that must be kept on premises. This concern falls squarely on the shoulders of the IT administrators. In the ideal world an IT administrator would flag specific applications as containing PII. At deployment time applications that contain PII can only be deployed only on-premises. At that point, the fabric that manages the enterprise takes care of this need, freeing the IT staff and developers from having to worry about such details.

A single abstracted view of computing resources helps with efficiency

IT administrators are concerned with the efficient utilization of computing resources. It is wasteful to have VM’s inside of both public and private data centers that are sitting idle. What is needed is a single holistic view of all computing resources, so that during deployment time applications can be targeted to available VM’s. Whether those VM’s exist on premises are in the cloud may not be relevant for most applications. If PII is not a factor but cost is, the goal would be to deploy the application and the public cloud because of the lower cost and of some of the benefits of operating in a highly automated data center that may contain other useful services.

What IT administrators want

IT administrators are burdened with the financial liabilities of running business applications on a pool of computing resources. The most obvious financial liability is cost. Managing cost can get complex quickly, because you have to factor in not just the cost of compute, but also of storage and network bandwidth costs. Cloud vendors generally charge for data leaving the data center so it might be financially advantageous to run certain business applications on premises. However, cloud-based storage and compute is often less expensive than its on-premises counterpart.

Compliance is a big liability

The other significant financial liability relates to compliance. Compliance is a very complex topic because it differs not just by company, but by state and country as well. Cloud computing has evolved more quickly than the laws that govern it. Perhaps the most important concern is PII, but companies also have to worry about HIPPA and other industry related compliance laws.

Customer dis-satifaction means higher cost

Often overlooked is the fact that application performance factors into the cost structure. Although it is hard to measure the impact of poor performance on user experience, it clearly maps to a financial outcome because happy customers are paying customers.

Declarative policy enforcement

IT administrators need declarative approaches to enforcing policies, not programmatic ones. For example, an IT administrator may flag an application as having PII data. As mentioned previously, during deployment, this application needs to remain on premises. But the IT administrator might also want to set a policy that controls the scaling of an application during busy and slow times. Having the application automatically scale based on CPU utilization or a memory footprint is important both for the customer experience but also for containing costs. Ultimately, the IT administrator needs to control costs and wants to be able to set a policy that determines how many computing resources are available to specific applications. That means that during deployment time certain applications will be limited to the machine size they can be deployed to. But this is critical for the developer as well. Minimizing what the developer must know during deployment contributes to developer satisfaction and productivity.

Developer needs

In the ideal world developers want to self-provision IT resources and minimize dependencies on IT administrators. They want a friction free way to spin up development and testing scenarios, as well as targeting virtual machines for deployment. They don’t want to worry about cost or security policies. They don’t want to worry about programming for multi-tenancy, registering endpoints for their web services, scaling their applications - to name a few. In short, developers don’t want to worry about the complexities of provisioning infrastructure to get their job done. They want to write code and to test it.

Common needs

Despite all the differences between IT administrators and developers, they do share some things in common. First, they want to get a holistic view of their respective worlds. The developer would like to see a view of all their deployed applications and the operating performance at any moment in time. IT administrators are also keenly interested in this holistic view of running applications. However, they also need this holistic view for all their available virtual machines, along with available memory, CPU, and storage. Both developers and an IT administrators are interested in benchmarking applications for performance and to track diagnostics. Identifying applications that are not running optimally is important to both developers and IT administrators. Developers and IT administrators also consider the application lifecycle to be an important part of their daily activities as applications move through the life cycle - dev, test, and production.

Shared Accountability

From the perspective of the software development lifecycle, this is a shared accountability. Developers can’t wash their hands of the running software in production and under the control of operations. Managing the complexities of performance engineering, problem resolution, capacity planning, and disaster recovery is a team effort. Developers must work with operations to properly virtualize the development and environments to reflect real-world, production conditions, including load testing, virtual machine configuration, networking, services, data, and end-user profiles.

Conclusion

Simply put, platform as a service means a more abstracted and automated approach to cloud computing. It represents the next generation in the way data centers will operate. I recommend taking a look at Apprenda. They really nailed it when creating a product that specifically responds to the needs of central IT and of developers. They are clearly two different stakeholders that differ in their needs while also sharing many common needs and goals.

Published at DZone with permission of Bruno Terkaly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)