
There aren't enough humans for cloud-native infra - prostoalex
https://siliconangle.com/2019/11/25/arent-enough-humans-cloud-native-infra-can-devops-deal-kubecon/
======
dangus
It’s a beautiful cringe-worthy big enterprise marketing piece preying on the
technical ineptitude of certain companies’ leadership.

1\. Point out how the world is changing so fast now, and that computers are
super extra hard (databases are 500 components now, that sounds pretty hard)

2\. Mention how you can’t just get competent employees and trust them to build
anything!

3\. Don’t worry, big consulting/solutions company (Cisco, IBM, Oracle, etc)
has a solution to your deepest fears! Just contract out inferior products and
consulting services at 10x the price of doing it yourself.

------
caust1c
A shining example of how far off the mark Cisco is.

Pretty sure this is just a marketing piece, but regardless, the industry needs
to stop thinking of software development and operations as inherently
separate. Developers should operate the software they write.

~~~
AgentOrange1234
Sounds like a recipe for disaster.

I’m a good programmer in my domain. I have enough ego to believe that I could
probably figure out how to install things and get them working... for awhile.

But I know that in the long run I would fumble it so badly. I don’t follow
security bulletins, I don’t know the first thing about how to set up database
backups, I don’t know how to configure a web server, and so on...

~~~
taneq
I don't think "developers should operate the software they write" means
"developers should be sysadmins", more that developers need to be tightly
coupled to the actual uses of the software they're developing. You can't write
good software in a vacuum, no matter how carefully you analyze requirements
and specify functionality. You just can't. You need to be close to the users.
Even if you can't eat the dog food yourself, you need to watch the users
eating it.

~~~
majewsky
Exactly. The org (and all constituent team members) needs to think about
problems end-to-end.

When you notice a problem, setup monitoring to collect metrics about the
problem and alert on it before it becomes a downtime. Have ops write down
their experience with that problem into a playbook, then have dev figure out
which parts of the playbook can be automated, or if the system design can be
iterated to remove the problem class altogether.

If you're a dev and you don't listen to ops, you're just as doomed as an ops
guy who doesn't read the dev's manuals.

------
sudosteph
__Disclosure: I develop automation for a company that provides managed cloud
services for huge companies. __

Am I reading this right? Are they really saying that the main issue is hiring
DevOps /SRE engineers at scale is hard - but that hiring and keeping an
additional team of AI engineers who understand cloud infra is somehow more
achievable for the average company?

I just don't see that playing out well for places where cloud and/or AI
technical expertise is not a core competency. There are managed cloud
providers who specialize in these areas. If your problem is literally that you
can't scale DevOps, it's at least worth pricing out those services before
committing to hiring an even more specialized role for infra purposes.

~~~
thinkingkong
I think its more hinting at a product suite or other companies that layer on
top; not that you need to build AI solutions yourself.

That being said I think the major issue isnt devops hiring. Its having poor
SRE practices, no breathing space for engineers, and scaling for the sake of
it, most of the time.

------
carty76ers
> You can’t just have a database admin,” Pandey explained. “A database is now
> 500 components. So you need your [site reliability engineer] organizations
> and your DevOps organizations to be aligned to that.”

LOL, what? Maybe for the cloud provider... but what’s presented to the end-
customer is most certainly not 500 components.

~~~
hawkice
I mean, they claim you can't just have a database admin. Let's be clear, you
can just have a database admin. (For nearly all values of "you")

~~~
kbr2000
Yes, and even two or three, not to put all your eggs in the same basket...

------
_bxg1
One just has to ask oneself how much of this complexity is actually needed.
Reminder: [https://nickcraver.com/blog/2016/02/17/stack-overflow-the-
ar...](https://nickcraver.com/blog/2016/02/17/stack-overflow-the-
architecture-2016-edition/)

~~~
hinkley
If I ever need an ego check, I go look at the number of requests per day
Wikipedia gets. Our traffic is sad by comparison.

------
bobberkarl
How can a database become 500 components? What are they doing???

~~~
dclusin
Probably referring to large scale deployments of Spark clusters where the
number of servers you're running for the cluster is in the hundreds or
thousands.

~~~
lykr0n
I still count 3 to 5 components.

~~~
kthejoker2
Eh, i cant get to 500, but I think it's more like "the database" has been
decentralized, so now you have

* a dedicated key vault instead of installing certs directly on the DB server * separate IAM / SSO * separate monitoring * separate logging and audit * separate vnet, subnet tooling * separate orchestration * separate object store / data lake * separate queuing * separate replication / backup * separate tools for streaming data, batch processing, job running

The only real additional vectors for a "Modern DBA" are CAP theorem, elastic
scale, cloud security, multi cloud, and the sheer belwidering variety of
platforms you may be required to support.

