@chipchilders i tend to agree, but i find that depending on the layer that you are deploying on (IaaS vs. PaaS vs. Serverless) you end up having to care more or less. Unless one has a team to take care of that for you. :-)
there's always infrastructure... what matters for a productive developer is to not have to worry about it. How abstracted that is becomes the question.
@kenowens12 scary time for infra management teams. Two moves in my opinion: (1) focus on the edge (where infra isn't being centralized) or (2) move into application operations role
@kenowens12 traditional DC management functions are going to start rapidly consolidating... public cloud, IT departments learning to operate as service providers, etc...
For many apps (probably the vast majority of LoB stuff) 'best effort' by the infrastructure is good enough. But there are some apps that can absolutely benefit from the ability to engage with deeper OSI layers.
@kenowens12 that is a massive change for the industry, and it's not just CF... mega clouds have much higher ratios... other platforms for enterprise DC's support similar ratios, etc..
In an ideal world the app dev can take the infrastructure for granted. But once you hit enterprise-grade apps, security issues, analytics workloads, and scale then someone needs to be doing the hard work
@dstaudtatcisco Agree. Some apps can benefit from engaging with the infrastructure. Infrastructure programmability and network programmability enable this!
@yurkvch I would turn it around the other direction, and say that the goal is to ensure your developers are focused on adding business value. Somebody still has to provide the servers...
@yurkvch We have to think long and hard about the assertion that developers should "know how infrastructure works." Knowing how it all drills down to, say, bare metal might be overkill for most app development initiatives.
growing maturity of DataCenter/Cloud Region orchestration platforms means apps should be abstracting away from infra towards service API endpoints. OTOH at edge it's almost polar opposite today. Emergence of IoT PaaS like @FogHorn_IoT point the way
@chipchilders Agree. Now the next question: What does it take to build, manage, and operate the layer below, Even if you "buy it" from someone else doing the work?
@jameskobielus Agree that they don't need to know how it works, but it should be abstracted and they should know when there are knobs / APIs they can use.
Another question: Does Cisco include data scientists (statistical modelers, data engineers, etc.) in the scope of "developers," or does the latter term refer more narrowly to coders?
Yes! We actually have a pretty broad definition of developers. We include crackerjack coders, data scientists, as well as "operators" who need to be power users of software systems as DevOps and network programmability come to play.
from my current focus on AI-driven supportability, it's essential to *include* Data Scientists. In order to foster & accelerate adoption of Cloud Native apps throughout their lifecycles monitoring signals & logs must be continuously analyzed
@susiewee That's the right scoping. IMHO, "programming" is done by anybody involved in shaping the assets (code, algorithms, biz rules, orchestration paths, etc) that direct and contextualize the flow of control over some end2end process
@Edwin_zh That's the right approach. Developer is anybody who contributes to the design, coding, engineering, implementation, and delivery of a reusable asset.
@valb00 Yes, exactly. What you're describing re AI (monitoring and continuously analyzing signals/logs) is the heart of training the ML/deep learning algos at the heart of these apps. Without continual algo retraining and tweaking of the algos, they decay
From a DevOps standpoint, I think a key app-maintenance issue in development, iteration, and deployment of AI apps in the IoT is the need for continual algo retraining, retweaking, redeployment to all those edge devices. Potential "fog hog"
If you speak about DevOps engineers, there is always a dilemma from what background the person should come: software or infrastructure. We saw success in both cases. However, the background often defines the strengths and weaknesses of the DevOpes engineer
@chipchilders Can you explain. What was the issue with how ITIL was implemented? How should DevOps in the enterprise be done to avoid repeating those issues?
Also - only focusing on operational considerations misses the point of increasing iteration rate. Iteration needs to be through the whole delivery process, from ideas, through development and into operations (and back again).
@chipchilders DevOps is tricky: a bit like discrete manufacturing (where you produce distinct items, ie. code releases) and a bit like process manufacturing (where you're producing a continual flow, eg., using code releases to sustain a biz outcome)
#DevNetCreate
