PaaS: Breaking Ties, Increasing Focus
PaaS: Breaking Ties, Increasing Focus
Join the DZone community and get the full member experience.Join For Free
We learn the basic principle of abstraction early in our computer science studies. The ultimate abstraction is really not having to care about what you are abstracting away at all. Take the typical example of a microwave: most people don’t know how it works, it just does. All we need to know is how to use it. Even for a geek like me who is intrigued to know how it works, and why it works the way it works, not having to care about fiddling with the internals is truly a blessing.
Today, when developing applications, most developers and operations staff aren’t enjoying that carefree state. Although they have very different concerns, most developers are still bogged down by infrastructure concerns, while Operations still needs to understand more than they should with the underlying application requirements.
My developer experiences have not been extensive, but I certainly have interacted with many developers through my studies, working in the industry, participating in hackathons, and just over coffee at conferences. Developers prefer to focus on writing code for their application. Do they really care about whether the application runs in a physical server, many physical servers, VMs, containers, or just in some little corner in the cloud? Provided that their application is running and performing as desired, visibly bug-free, the developers are happy.
Let’s look at what generally matters for developers:
- New frameworks (express, hapi, grails, spring)
- New languages (go-lang, node.js, etc.)
- New application architecture
- Application security
I have worked under the Operations group in IT shops, as well as in a Solutions Development team designing and implementing architectures that spanned multiple data centers and geographic locations. Within the Operations business unit, we cared very deeply about the infrastructure. The focus with Operations is definitely on infrastructure management, whether or not they are supporting the contractually required uptime, whether it is easy to maintain, whether it is secure. That being said, is it part of their duty to be concerned about what the application actually does for end users?
This is what generally matters to Operations:
- Backup and Disaster recovery
- Geographically distributed configurations
- Resource Utilization
- Infrastructure security
I see no overlap. But let’s not kid ourselves, applications do need proper infrastructure to run on and this is not changing. Not too long ago, definitely less than a decade ago, the physical resources played a vital role as a major constraint to architecting and deploying applications. An application and its supporting hardware were very tightly-coupled. However, with advancements in both infrastructure and applications, the locking between the two have now loosened. While many IT personnel today still associate applications with physical or virtual hardware, this shouldn’t be the case anymore with modern cloud technologies like platform-as-a-service (PaaS).
The loosely coupled association between application and infrastructure has opened up a new world for both groups. PaaS facilitates the abstraction, enabling developers to focus on their applications and operations staff to focus on the infrastructure. It doesn’t matter whether you are a developer writing applications or in Operations working on the infrastructure, you can focus on what you need to do and what you care about. 
The Clear Benefit: Focus
Before PaaS, applications had, by today’s standards, unnecessarily strict infrastructure requirements. There’s no doubt in my mind that the most significant benefit you get from a PaaS is to break those ties, allowing everyone in their respective role to focus on their already difficult-enough tasks at-hand.
 Leave comments below whether you’re a developer or in the operations function. Tell us your top-of-mind and what you care deeply about.
Published at DZone with permission of Kathy Thomas , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.