And what exactly is "Platform as a Service"? Can someone define that?
It is bunch of network devices, servers, oses, services and softwares running by (dev)ops
The Big DevOps Misunderstanding
191–200 of 321 posts
Re: The Big DevOps Misunderstanding
#192The "devops philosophy" is not a fundamental fact of nature (of dev teams or whatever). If deploying stuff is complicated, it is not surprising that we'll have teams that specialise in it. The naming/identification of the organization concept has to follow structures determined to be desirable for more fundamental reasons ... and not the other way around.
So the right question to ask here is perhaps "why is deploying so complicated?"
Re: The Big DevOps Misunderstanding
#193Are you running your application on a UNIX system? (You probably are). Do you know your octal file permissions? Your various FS choices? Your reserved ports? Your inode limits? Your uid mapping? Your SSL root trust location? Your free-space limits? Your TCP handshake? Your TLS 1.1, 1.2, 1.3 handshake? Your HTTP verbs? Firewall rules? NAT configurations? Load Balancer health checks? JVM -~XmX values? Swap size? Databa…
As a developer your stack goes all the way down. An issue with a TCP 3 way handshake to your application load balancer is still an issue. An error in the filesystem that results in customer impact is still your responsibility. We can work with specialists but ultimately it is a team that owns their software running in production.
Many of the things you listed are well known, monitored, and tuned by software engineers operating their software. Especially connection pools and memory settings.
Re: The Big DevOps Misunderstanding
#194Earlier quoted context omitted.
Being a devops guy these last 2 years I have noticed that besides doing what you just mentioned, I am basically end user support for developers. And through this I've noticed that developers can be just as bad at communicating issues as any end user I've ever dealt with. Just because they've written the system end users use, does not mean they're better at reporting problems to me, because their problems are about th…
> And through this I've noticed that developers can be just as bad at communicating issues I swear to god the next guy who sends me the screenshot of an error log...
You haven't known hell until you've been sent a video of someone scrolling through a log file.
Re: The Big DevOps Misunderstanding
#195Earlier quoted context omitted.
To adapt Greenspun's tenth rule: You have a dedicated team building an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Google App Engine (or Heroku, or Digital Ocean App Platform, etc).
I know my company is likely not the norm, but we can’t use Google App Engine or anything like that because we are a CDN. Our infrastructure is core to our product. I know this might be unreasonable, but I always get frustrated when everyone suggests that anyone running their own infrastructure is clearly doing it wrong. I get that most dev groups are creating web apps and should use a PaaS, but there are also a lot o…
I'm sure there are many people in the same boat, but I don't know that there could be the forum you imagine, not with our current cloud landscape. You're building a CDN, Netflix's video CDN is different from Akamai's is different from Fastly's is different from yours, internally and externally.
More mainstream; AWS engineers don't know GCP's architecture don't know Azure engineers' needs. And just right there are 7 different dialects of "cloud".
There's tons of interest, but much of the knowledge is covered behind corporate NDAs/employe and getting people aligned on terminology and technologies is hard because so much is hidden behind NDAs. The current solution is either to work for a big company where there's rigorous internal discussion or go to tech conference after-parties and hope to meet the right people at the right time/place on the Ballmer curve to have a productive discussion.
Re: The Big DevOps Misunderstanding
#196We built the https://controlplane.com platform to let developers focus on the Dev and get best practices Ops so they can deliver many times faster. Our customers get 99.999% availability and ultra low latency no matter where users are. Check it out and I'd love to hear your feedback on the Ops part in DevOps with Control Plane.
Control Plane is awesome and as a former SRE I recommend it whole-heartedly.
Thank you! make sure you write me an email. I'll ship you a t-shirt :)
Re: The Big DevOps Misunderstanding
#197I think a lot of people are missing the point of the article: it's saying that devops was coined by Vogels (i.e. Amazon) as a value add because actual ops people are a necessary evil for a lot of companies that just want the features devs are cranking out to WORK without needing to be managed. Every salary that has to be paid to an ops person is a salary not spent on a dev making new features, fixing important bugs,…
> pay Amazon a fraction of what you'd pay full time in house people to do - at least in part. DevOps was meant to give devs more control over this work so that fewer ops people would be needed.
And here is the lie in the AWS marketing promise. In reality without ops the infrastructure clueless devs will generate huge AWS bills that move the profits from AWS customers into Amazon's pockets. At the same time with production being more brittle and ci/cd becomming a complex nightmare that gradually takes larger chunks of dev time until things grind to a halt.
The catch 22 being leaking abstractions. In the same way that devs cannot really empower regular users to generate apps with nocode that work well, devops cannot create iaas or paas that can be used without understanding the underlying os, networking, configuration management, package managers, etc
Re: The Big DevOps Misunderstanding
#198Kubernetes is a cancer for 99% of companies. Most companies need little more than docker compose/swarm. Kubernetes is the antithesis to KISS. If you’re Google, then you need something like K8s. Most orgs using it are pretenders or trend followers. Sadly it has become the “standard” way to deploy apps.
100% this, same for microservices.
One of the most damaging belief a developer can have is "if my stack looks like * insert unicorn *'s stack, we will be a unicorn"
Re: The Big DevOps Misunderstanding
#199Earlier quoted context omitted.
> And through this I've noticed that developers can be just as bad at communicating issues I swear to god the next guy who sends me the screenshot of an error log...
Blame management. They thought it would be a good idea to go into the DevOps PaaS business.
At a certain point you have to ask how can someone not think about what they're doing at all. If someone asks for a log, what would go through your brain that says, should I give it to the person asking in the most inconvenient format possible? What's the first thing they're going to do with it?
Re: The Big DevOps Misunderstanding
#200Earlier quoted context omitted.
Devops is having an identity crisis, but what you describe is what I call devops. It's the subset of engineering that supports engineering by defining/inferring workflows and building systems and tools to codify them. But I've seen it called ops, sysops, internal platform, and even infrastructure -- in some companies, devops and infra are the same people.
Yeah, I am not sure how typical this is, but my company has DC (data center) ops, NetOps, SysOps, and DevOps… DC ops is in charge of the physical system, from racking and stacking to hardware replacements. NetOps handles the networking stack, managing the routers and switches, vlans, announcements, IP block management, network access requests, etc. SysOps handles provisioning systems, working with dc ops to get syste…
Who's clicking the button that says deploy this service to production?