Why should developers care about OpenStack*? Does it really affect their work adding features, debugging code, improving performance, generally pleasing their customers? (Or at least making them less pissed off).
Sure, cloud computing is a Big Deal. But isn’t the whole idea about infrastructure is that it disappears when it’s working correctly? And as the leading open source Infrastructure as a Service project, OpenStack should be invisible when it’s working correctly.
Knowing the capabilities & limitations of OpenStack drives app architecture
If your organization has adopted OpenStack or you are kicking the tires to see if it will work for you, it helps to know what is easy in OpenStack and what is hard. For example, if your application needs persistent storage, will you make use of the object storage of Swift or Ceph? Knowing how to index objects in Swift would definitely drive how you architect efficient object storage into Swift.
Knowing the pain of operations should factor into application design
Another reason to care is that more IT departments are expecting their developers maximize agility and accelerate deployment of applications. This has led to the emergence of the “DevOps” category of worker, blurring the silos between administrators and developers. I would say you can’t really appreciate deployment until you understand the cloud it’s being deployed on.
Understandably, with an emerging concept like DevOps,actual adoption might be low. The recent Stack Overflow Developer’s Survey showed that amongst respondents only 2.2% considered their title to be “DevOps” vs something else like “Full-Stack Web Developer” which stands at 28%. (But perhaps DevOps people are not responding to Stack Overflow surveys.)
Even if you don’t call yourself a “DevOps” person, knowing how your application will be deployed in the cloud is pretty important to ensuring that your application is adopted quickly.
Knowing how the cloud works drives cloud native applications
Another reason developers should care about Open Stack is an emerging concept of Cloud-Native Applications. In essence, organizations which are adopting the cloud want applications which are designed to run in the cloud! Application developers who don’t take this serious might be accused of “cloud-washing” or trying to paint your application as being cloud friendly even if it’s no different.
There is a Cloud Native Computing Foundation collaborative project under the Linux Foundation, which is designed to help developers adopt an architectural mindset which supports the cloud.
One example of this is the concept of statelessness. Cloud orchestration systems expect to manage compute load by killing VM’s and containers which are underutilized and starting up new ones where demand is higher. If an application is not resilient to this kind of death with extreme prejudice then it can’t really adapt well to the cloud.
Another example is to assume local storage is not necessarily persistent. If you are writing your log messages to a local file, you can be sure that they will be lost.
I would encourage every datacenter developer to learn more about cloud infrastructure such as OpenStack and engage with the Cloud Native folks. This way you can be assured that you won’t be ignored when the clouds gather.