5 ms·

Depends on what you think Developer Operations should be. Our developers instantiate their buckets, databases, cache instances etc. themselves, deploy microserv

Depends on what you think Developer Operations should be. Our developers instantiate their buckets, databases, cache instances etc. themselves, deploy microservices themselves and update configuration, traffic management and scaling parameters themselves. No 'system' people required. The system people are mostly just keeping the automation running and add features as needed. The work also really isn't the same. Unless you're stuck in the 90's we aren't building servers, installing operating systems, installing applications and installing patches anymore.

trog 4y ago
> Depends on what you think Developer Operations should be. Our developers instantiate their buckets, databases, cache instances etc. themselves, deploy microservices themselves and update configuration, traffic management and scaling parameters themselves. No 'system' people required. The system people are mostly just keeping the automation running and add features as needed. When I read this though, I just think about how much time your developers are not actually developing because they're doing operational-side work. I have the situation where my developers do this stuff, then things break or need debugging and they don't really know how to dig into any of this stack in any meaningful way, so the problems tend to compound. Meanwhile, they're not writing code. The cadence of development seems massively slower to me (coming from a traditional background where they're writing to a clear Ops-set target environment). The logical outcome is to hire someone who is an expert in all this infrastructure stuff to help manage it - ostensibly, a "DevOps" person, but really, a classic Operations person, just for cloud.
- jnsaff2 4y ago
  > When I read this though, I just think about how much time your developers are not actually developing because they're doing operational-side work. Cool. Cool cool cool. Now instead of doing these things that first time takes a few days, second time a few hours and after that are barely noticeable you dev your thing, then it goes to an Ops queue, which (hopefully next day) comes back with a big fat "heute leider nicht" because you did not understand how the queue works or something. You fix your thing, it goes back to a queue, etc etc. So your flow is still messed up and yout Time to First Eyeball has increased quite a bit as you have high latency round-trips with external parties. Obviously there is a tradeoff somewhere, does the dev know all the opsy things or does she know enough to only need to ops when the paved road is not enough or is it the good old "over the wall it goes".
- oneplane 4y ago
  So instead of having a team of people own something (a product) you are splitting ownership up in so many ways, nobody really owns it, and now you have to make everyone waste their time on KPI tracking because somehow that's better than someone just owning their small product as part of a larger business? This is pretty much a waterfall vs. iterations discussion where the reality is that the world doesn't stop moving while you're working. If a product team needs to deliver something (i.e. "allow users to select a delivery window for an order"), they might update their microsite with the components and API calls to do this, and then update their API microservice to exchange that information based on the customer's identity (so they can only update their own order delivery data). None of that knowledge is going to exist in a classic ops team, nor should it be if such a team were still relevant. At the same time, that team might need to take into account that there might be order peaks during the day and they have to collect and act on the right metrics to know how well their code works, how many resources they are consuming and what their scaling policy should be. None of that has anything to do with ops either. Then, at the end of the day, they'll use all of this information and domain specific knowledge to decide: - is the feature complete - can users make proper use of it - do we need to invest time and effort in code optimisations - do we need to extract this feature into a separate scalable entity to prevent disruptions to neighbouring features None of this is relevant or knowledge for ops either. Nobody will be able to manage a feature like that better than a product team with a few developers, a few features, a (shared) product owner, and perhaps a (shared) domain expert or tester. But the people who wrote the code own the implementation (but usually they don't own the business requirements). What ops (or devops enablers) would be doing in this case is: - make sure metrics aggregation is working as expected - make sure scaling is working as expected - make sure deployments and configuration updates are working - construct new deployment options if needed - construct new metric aggregation systems if needed - construct new scaling and traffic management systems if needed - notify the teams/owners if they are using deprecated resources or features for too long Perhaps a simple but too vague summary of the above would be: small feature-owning teams build and maintain their features, devops people enable many small teams to do their work by providing shared systems. A developer isn't just a 'writes some code, clocks out' type of value to a company. If it was that simple, robots could do it, and there would not be a shortage of skilled people. There are many more dimensions to work, and unless you work at a very large scale company, or a very restrictive company, it's highly unlikely that you'll be isolated from the world and just write a bit of anonymous source code with no idea of what happens before or after.
hitpointdrew 4y ago
> The work also really isn't the same. Unless you're stuck in the 90's we aren't building servers, installing operating systems, installing applications and installing patches anymore. I guess I am stuck in the 90’s then, I absolutely do all of the those still. Not every thing is “sever less” you know.

trog 4y ago

> Depends on what you think Developer Operations should be. Our developers instantiate their buckets, databases, cache instances etc. themselves, deploy microservices themselves and update configuration, traffic management and scaling parameters themselves. No 'system' people required. The system people are mostly just keeping the automation running and add features as needed. When I read this though, I just think about how much time your developers are not actually developing because they're doing operational-side work. I have the situation where my developers do this stuff, then things break or need debugging and they don't really know how to dig into any of this stack in any meaningful way, so the problems tend to compound. Meanwhile, they're not writing code. The cadence of development seems massively slower to me (coming from a traditional background where they're writing to a clear Ops-set target environment). The logical outcome is to hire someone who is an expert in all this infrastructure stuff to help manage it - ostensibly, a "DevOps" person, but really, a classic Operations person, just for cloud.

jnsaff2 4y ago
> When I read this though, I just think about how much time your developers are not actually developing because they're doing operational-side work. Cool. Cool cool cool. Now instead of doing these things that first time takes a few days, second time a few hours and after that are barely noticeable you dev your thing, then it goes to an Ops queue, which (hopefully next day) comes back with a big fat "heute leider nicht" because you did not understand how the queue works or something. You fix your thing, it goes back to a queue, etc etc. So your flow is still messed up and yout Time to First Eyeball has increased quite a bit as you have high latency round-trips with external parties. Obviously there is a tradeoff somewhere, does the dev know all the opsy things or does she know enough to only need to ops when the paved road is not enough or is it the good old "over the wall it goes".
oneplane 4y ago
So instead of having a team of people own something (a product) you are splitting ownership up in so many ways, nobody really owns it, and now you have to make everyone waste their time on KPI tracking because somehow that's better than someone just owning their small product as part of a larger business? This is pretty much a waterfall vs. iterations discussion where the reality is that the world doesn't stop moving while you're working. If a product team needs to deliver something (i.e. "allow users to select a delivery window for an order"), they might update their microsite with the components and API calls to do this, and then update their API microservice to exchange that information based on the customer's identity (so they can only update their own order delivery data). None of that knowledge is going to exist in a classic ops team, nor should it be if such a team were still relevant. At the same time, that team might need to take into account that there might be order peaks during the day and they have to collect and act on the right metrics to know how well their code works, how many resources they are consuming and what their scaling policy should be. None of that has anything to do with ops either. Then, at the end of the day, they'll use all of this information and domain specific knowledge to decide: - is the feature complete - can users make proper use of it - do we need to invest time and effort in code optimisations - do we need to extract this feature into a separate scalable entity to prevent disruptions to neighbouring features None of this is relevant or knowledge for ops either. Nobody will be able to manage a feature like that better than a product team with a few developers, a few features, a (shared) product owner, and perhaps a (shared) domain expert or tester. But the people who wrote the code own the implementation (but usually they don't own the business requirements). What ops (or devops enablers) would be doing in this case is: - make sure metrics aggregation is working as expected - make sure scaling is working as expected - make sure deployments and configuration updates are working - construct new deployment options if needed - construct new metric aggregation systems if needed - construct new scaling and traffic management systems if needed - notify the teams/owners if they are using deprecated resources or features for too long Perhaps a simple but too vague summary of the above would be: small feature-owning teams build and maintain their features, devops people enable many small teams to do their work by providing shared systems. A developer isn't just a 'writes some code, clocks out' type of value to a company. If it was that simple, robots could do it, and there would not be a shortage of skilled people. There are many more dimensions to work, and unless you work at a very large scale company, or a very restrictive company, it's highly unlikely that you'll be isolated from the world and just write a bit of anonymous source code with no idea of what happens before or after.

hitpointdrew 4y ago

> The work also really isn't the same. Unless you're stuck in the 90's we aren't building servers, installing operating systems, installing applications and installing patches anymore. I guess I am stuck in the 90’s then, I absolutely do all of the those still. Not every thing is “sever less” you know.