DevNetCreate

Cloud & DevOps Chat
DevNet Create inaugural event conversation of experts talking cloud and devops.
   3 years ago
#DevNetCreateIoT and Apps Expert ChatDevNet Create inaugural event IoT and Cloud for developers
John Furrier
POLL: Of the two tracks Cloud and IoT which one will be more popular?

POLL: Of the two tracks Cloud and IoT which one will be more popular?

ashley roach
Do you see infrastructure as an important part of your application, or do you take it for granted?
Chip Childers
unless your application is supposed to interact with infrastructure, it should be taken for granted. Otherwise you're doing something wrong.
Ken Owens
@chipchilders Chip what about the infrastructure teams?
Andrei Yurkevich
Developers need to understand how the infrastructure works, but should be 100% abstracted from its management with the DevOps automation layer
Chip Childers
@kenowens12 super important if you run your own infra, but the question was about infra being something that app devs should care about
Chip Childers
@kenowens12 you need infra, but you should be free to take it for granted
Ken Owens
@chipchilders 100% agree. My question for you was related to your advice from experience for the infrastructure team
ashley roach
@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. :-)
Chip Childers
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.
Chip Childers
@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
Ken Owens
someone caresπŸ˜€ and the interaction between these layers is critical
Chip Childers
@kenowens12 traditional DC management functions are going to start rapidly consolidating... public cloud, IT departments learning to operate as service providers, etc...
David Staudt
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.
Chip Childers
@kenowens12 ex: the CF community has a ton of examples of ratios at least at 1 platform operator to 4K apps deployed
Chip Childers
@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..
susie wee
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
susie wee
@dstaudtatcisco Agree. Some apps can benefit from engaging with the infrastructure. Infrastructure programmability and network programmability enable this!
Andrei Yurkevich
this is exactly the goal of PaaS and Serverless to make developers produce less "infrastructure" code
Chip Childers
@dstaudtatcisco completely agree... but 80/20 rule (at least) applies. Also: many of those that *believe* they are snowflakes are wrong
Ben Schumacher
@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...
jameskobielus
@susiewee Right. Anyone who thinks "serverless"/functions-as-a-service environments will, through abstraction, render security, scaling, and workload mgt trivial is fooling themselves. Juggling multiple "functions-as-a-service" clouds will exacerbate
Chip Childers
@susiewee but none of those reasons can't be handled by a platform layer completely abstracting them below *developer* consideration.
jameskobielus
@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.
Val Bercovici πŸ‡»
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
susie wee
@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?
susie wee
@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.
jameskobielus
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?
DevNet Create
Great question @jameskobielus! #DevNetCreate is for all futurists, coders and decoders included. https://blog.devnetc... #DevNet
Ken Owens
great question
John Furrier
what do you think Jim?
susie wee
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.
Edwin
we are using 'developer' term broadly, which includes data scientist, network engineer, solution architect, operator, etc.
jameskobielus
@furrier I like the range of #DevNetCreate blogs that address that issue from many angles.
Val Bercovici πŸ‡»
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
jameskobielus
@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
jameskobielus
@Edwin_zh That's the right approach. Developer is anybody who contributes to the design, coding, engineering, implementation, and delivery of a reusable asset.
jameskobielus
@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
Andrei Yurkevich
the IoT is becoming an area where you can see AI more and more often. The #DevNetCreate agenda testifies that
Chris
- too easy! Of course. Simple example: how many times does our customer visit us Visits/Month! Meraki!
jameskobielus
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"
Val Bercovici πŸ‡»
Love it - New hashtag! #FogHog πŸ˜‡
John Furrier
What is the biggest misconception about devops in the enterprise?
Chip Childers
that you can implement it the same way ITIL was implemented
Andrei Yurkevich
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
Andrei Yurkevich
the DevOps operations is probably the most mysterious area of IT. Everybody understands it differently
susie wee
The biggest misconception about #DevOps is that it's easy. It's not. It takes time to learn how to put it in practice and practice it well.
mandy whaley
The biggest misconception is that #DevOps is all about tools. It is equally as much about people and culture change.
jameskobielus
@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?
Edwin
misconception - "go hiring a DevOps engineer; you will have DevOps."
Chip Childers
@jameskobielus biggest issue that I lived through was believing that ITIL was an org chart, not a list of disciplines / considerations
Chip Childers
@jameskobielus similarly, "DevOps" is neither role or team. It's an approach that everyone should be part of.
John Furrier
@coggerin says
That is replaces traditional operational models completely!
John Furrier
@PlatenReport says
That it requires major cultural and organizational changes. Passing out books won't do anything...Think the Agile mess
Chip Childers
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).
Shubha Govil
" it will bring instant feature velocity"
jameskobielus
@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)
Chip Childers
@jameskobielus right... and no specific step or team is "devops"
jameskobielus
@chipchilders Right. The entire end-to-end continuous CI/CD/release pipeline is "DevOps."