Earlier quoted context omitted.
SOA is just Spaghetti Architecture. I haven't seen an implementation that convinces me otherwise.
What is your definition of Spaghetti Architecture? Netflix had a good SOA that enabled rapid development and had strong cut lines between services, with no way to access the data of a service without going through the service's API. I think that's where most people go wrong. They put a bunch of services in front of a shared database, which means that they don't have to go through a service's API to get to it's data,…
DevOps is broken
281–290 of 363 posts
Re: DevOps is broken
#282Hard disagree but Mandy Rice-Davies applies. Some interpretation of DevOps may be BS, e.g. >> Need a database? File a ticket with DevOps. That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022. Counter points as to why DevOps is not BS: Today there's just an acceptance that you version your code in VCS, it wasn't always that way. "Hey, this doesn't look rig…
At uni back in ~2000 was the first time I ever heard of version control. It was a bit of a curiosity, nobody seemed to be using it.
In 2004, engineering at the place I worked (you've heard of it) were developing PL/SQL in production with no VCS.
In 2007, I worked in IT at the same place. They were developing in SharePoint without VCS. When I asked if I could use VCS, I was told to use a 1996 or so Visual SourceSafe which was more temperamental than Subversion.
The first place I worked that used VCS was in 2008, and only because the devs had started using it against the wishes of the principal developer.
The world moves fast and slow at the same time.
Re: DevOps is broken
#283Earlier quoted context omitted.
>>the only alternative is to start making CPUs by hand Agreed. For some applications the cloud difference is significant; for many (most?) others though, "Cloud" is just rebrand of "Hosted". And even for more cloudy offerings, while I'm in a very specific and different part of IBM, some of the old timers/architects/powers-that-be keep trying to explain "We had that in 1969 !!!" :-D Agreed also at rewriting of history…
> My dad has been IT director and he chuckles when I talk to him about "new and exciting paradigms" which he of course sees as turning a circle to what they had in 70's and 80's :) As someone with 20+ years in IT, I agree - a lot of these "new and exciting paradigms" are not new at all. My personal favourite is how many large multi-nationals are now building in-house clouds? WTF is the difference between an "in-house…
I am guessing that in the 80s you weren't writing Infrastructure as Code to define exactly what resources you needed for your software, having it all set up automatically, and so on.
Re: DevOps is broken
#284Over the last ten years, the market has tried to kill off the hardware, systems, network and security people, and mostly succeeded. As a result, it's relatively easy to find someone who advertises as "full stack devops" who has never actually operated any infrastructure more complex than a LAMP webserver cluster. And it's hard to find a senior sysadmin who has enough years of experience to understand and troubleshoot…
I worked at a place that had an elastic search cluster with 30 nodes, because they kept hitting open file limits, when 8 servers could easily handle the traffic with basic tuning.
Re: DevOps is broken
#285> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.
I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code. There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and…
If you don't want to think about AWS S3, GitHub Actions/Jenkins, Terraform, etc, .... then we need to work together. All those tools and services exist because all the software developers are sitting in their sandbox, and don't want to come out and play. The systems and tools that we run your code with... suck. A lot. We need programmers to make the systems better. We (in Ops) are a little busy with trying to just figure out how to run your apps without them falling down. We don't have a lot of time to reinvent the state of the art of computer systems.
For example, we need a distributed operating system. Not some fucked-up kludge of a monolith of microservices overseen by a company that has more engineers than brains... but an honest to god, stable-ABI, simple, composeable, stable, general operating system. We need Linux to come out of the box, ready to run distributed applications, in a way that doesn't require a PhD. Once we have that, then you - yes, you, the developer! - will be able to make applications that automatically scale so easily that we will never need to utter the phrase "container" ever again. You will rarely ever need us again, because the system will just be so simple, so general, that anybody who can use the terminal can build and deploy applications without ever learning anything outside of your programming framework.
But we need you to make that distributed operating system. Until you do, we will just have more stupid kludges, more bizarre unnecessary complexity, in the futile attempt to constrain all the crazy shit we want to do with technology, while trying to run your apps for you. Please, I'm begging you - put me out of a job.
Re: DevOps is broken
#286Earlier quoted context omitted.
The big issue I've seen is that takes a lot of work, so people cut corners. The problem is of course when you cut corners with microservices and rely on a shared database for instance, suddenly you're dealing with 40% of the costs of a microservices and 0% of the benefits.
Shared database can be a reasonable microservice boundary, especially when using database-as-queue or database-as-mucroservice. In the former, services a, b and c can insert and query but only D can update, i.e. any service can creat a work-order but only D can mark it completed. I. The latter, nobody can read or write and all access to tables is done through stored procedures. I don't recommend either, and it's stil…
Btw some of the confusion might be what I mean by shared database. I didn't mean two services sharing a limited set of tables, using the database as a rabbitmq replacement. I meant sharing the backing database of the microservices. It sounds like we probably agree I just wasn't very clear about what I meant by sharing a database.
(Ironically I am literally using a database as a queue to share data between two services we are running in prod. I don't think of it as a microservice because it's not separate teams, it just because our monolith is hosted on a platform that doesn't support certain libraries so we had to role those libraries onto a separate platform that does support them.)
Re: DevOps is broken
#287Earlier quoted context omitted.
Alan Kay said that “Everyone who is serious about software should make their own hardware.” How can you be a good developer if you don’t understand the architectural limitations and choices? When I design a backend system, I need to think about how the front end developers are going to interact with it. My data storage characteristics and scaling. I need to know am I designing anything that’s hard to deploy. How will…
I don’t think you’re disagreeing with me. Developers should know what their code runs on. They shouldn’t have to add managing that to an already full schedule of work. That’s the difference.
I think to push back is rightfully coming from the “ops” part. I consider “creating the CloudFormation/CDK/Terraform” code as part of “development” as part of coding.
If you use Docker, wouldn’t you consider creating the Dockerfile as part of development?
Yes I knew AWS pretty well by the time I left and I needed to know it to be a good developer in that context and designed most of the processes around it. But I refused to do “operations” - ie “infrastructure babysitting”
There is a huge distinction between “I don’t think I should have to know how everything works” and “don’t call me in the middle of the night when something goes down “.
[1] I’m the first to admit that I left the “real world” once I started working in the cloud consulting department at $BigTech
Re: DevOps is broken
#288I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
DevOps to me is all about bridging what used to be a huge gap between operations and development. Developers need to know top 10 OWASP. One cannot simply say "it works locally". Ops people need to understand how your tools and programs work at a high level at minimum.
Some teams historically worked fine together, others didn't.
I think the tools we have these days are much better (for ops) to ship what works on developers machines.
But if your organisation had a culture of not working together then devops didn't really do much.
and anyway, you've leaned into my point about it meaning different things to different people.
Re: DevOps is broken
#289Earlier quoted context omitted.
"anything else not happening on a developers computer which they should control but wont" Ok, I've seen this, but IME (24y in industry, the last 6 as a consultant) in the vast majority of cases, it's more like "things devs should control but CAN'T [bc CICD etc are silo'd and owned jealously by an overburdened ops team unable or unwilling to facilitate self-service]".
Some of the 'jealousy' may also come from bad experiences. It only takes a few instances of people royally messing stuff up in production for their deployment rights to be stripped away – and other groups catch the fallout too, as new "procedures" get implemented.
Sure, there are some overbearing procedure monkeys who really want a process on everything, but a lot of "protection" rules are there because something really bad (and expensive, financially or reputationally) has happened before.
Re: DevOps is broken
#290I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
Are you hiring? I was hired as an infrastructure engineer and I'm currently writing typescript for the frontend of an internal product.
jan [at] competition [dot] company
If you want more information on the project we're working on the site is https://rennsport.gg
We're building a hard-core racing simulator game with a backend which can persist car ownership in a way that feels authentic. (IE; not just tied to a game).