251–260 of 363 posts
At least this is how the role works in my company.
Earlier quoted context omitted.
This is really important, and I've gotten a lot of quizzical looks when making this assertion over the years: data is owned by one and only one service. If two pieces of code assert ownership of it by mutating that data or looking past the public encapsulation of that data, then that code is the same service. If you see a queue between two services, that is usually an indication that some ownership is being transferr…
> Data sovereignty per microservice > An important rule for microservices architecture is that each microservice must own its domain data and logic . Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice. https://learn.microsoft.com/en-us/dotnet/architecture/micros...
Earlier quoted context omitted.
I completely agree that 20+ years of cheap money have absolutely caused much of the complexity we see today. That's because people aren't working on problems that matter; instead, they're just trying to make VCs rich--effectively passing the buck on to the greater fool. I think this era is coming to an end, and we should see a drastic reduction in software development costs with the end of cheap debt.
I hope I'm not being pedantic here, so please forgive me. Didn't interest rates go to zero after 2008? So that's 14 years. I guess 8 years before that there was also Dot Com. Are you talking about interest rates? Thanks. Even if you're wrong, it's an interesting theory.
Is probably one of the better explainers.
Earlier quoted context omitted.
> DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. This is always a dead giveaway that something is a buzzword Same for rest. Sometimes when people use it, it just means JSON + http requests. Other times it's supposed to be some kind of architectural style
You can always point people to the original paper that defined REST: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
The other thing that this misses is that the deployments to the cloud are only half the battle. CI/CD pipelines, Dev environments, and other SDLC phases like planning and testing are just as important as terraform. Making the infra as code better and more reusable is a great step in the right direction but only part of the puzzle to making software development workflows better in the big picture.
> 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.
This is me right now: https://i.kym-cdn.com/entries/icons/original/000/019/304/old...
Said the 4th article on the subject this month.
I have bewilderingly tried to discern why software development continues to grow more and more complex. It wasn’t always like this. There was a time when we talked about languages and OSes and libraries as if they made a difference on how much you could get done with as little people and cognitive load as possible (the claims were very much overrated, but the point was we acted like it mattered). And then it started…
It has blown me away too. There was a time where it seemed like the default "devops" strategy for startups was to use Heroku. Developers could spend all their time working on code. Worked at a startup a few years ago. We had 2 devs, and one devops guy building out Kubernetes, Docker, running on Aws. Had to constantly spend me time with him troubleshooting why this or that thing wasn't working rather than writing appl…
I'm glad you said this. 2-dev shop here and we've used Heroku the last five years. We spend all our time developing and supporting our application and almost never worry about infrastructure. I keep getting tempted to move to K8s; Heroku is expensive for what we get and seems to have suffered some serious brain-drain. I've dabbled with K8s in side-projects and I can geek out on all the terraform and yaml stuff for days. But its probably not a great idea to inflict it on a 2-dev shop.
Earlier quoted context omitted.
> I don’t hire devops, I hire infra engineers, build engineers, release engineers and: backend engineers. This is a great way to do it. There seems to be a correlation between unnecessary product complexity and unnecessary corporate complexity. Being direct about roles goes a long way towards simplifying corporate complexity.
> There seems to be a correlation between unnecessary product complexity and unnecessary corporate complexity. That's Conway's law. "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." https://en.m.wikipedia.org/wiki/Conway%27s_law
I'm sure we're due for a new one soon which will follow the same path, since people seem to be admitting that Devops has problems on here more and more. Will that cause deeper reflection? Probably not for many orgs, because soon some consultants will dream up a new brand of silver bullet to slay the immortal monster of organizational dysfunction and that's much more exciting.
