4 ms·

This article was frustrating to me. When it started out in the mid-90s (which is when I started my career also), I thought our experiences would be more aligned

This article was frustrating to me. When it started out in the mid-90s (which is when I started my career also), I thought our experiences would be more aligned. However, I've never worked with an operations team. In all the places I've worked I've been expected to do everything from setting up servers (originally physical servers, later cloud servers), hardening them, installing software, optimizing the software, installing and optimizing the database, creating database schemas and related objects, writing untold number of sql queries, writing server side code, writing front end code, etc. I was hoping that the article would explain what devops really means today and how I can jump on the devops wagon to hopefully make my job of doing all of the above easier.

commandlinefan 7y ago
> make my job of doing all of the above easier. That’s the dream… the reality in my experience is that you have to describe, in detail, the exact steps that you would perform if you were doing it yourself so that somebody else can perform them, verbatim. But you have to describe those steps, exactly, without any access to the target platform where they’ll be performed.
- Andhurati 7y ago
  Does it get any better? I feel like I'm on thin ice whenever I deploy. Granted, I now try to make sure the SAs have to do as little as possible (because now I "understand" the infrastructure, I can build a postinstall that handles all the environment configuration I am allowed under an FID), it still feels nerve wracking to know that a single fuck up means I have to spend another 4-5 hours trying to get tickets to deploy. Fuck this.
walshemj 7y ago
And its also written from a very recent perspective, arguably I was formally working in devops in the 80's I was hired as development team member partially as I was a sysadmin on the hardware we were using, our team both wrote the code but also the entire JCL infrastructure that managed the compilation linking, deployment and the running of code across the cluster of 16 or 17 systems. On of my friends, an IBM guy from the operations side was shocked that we as developers where allowed to deploy and run our own code.
dogprez 7y ago
The article is lost on me too. ~15 years professional experience as a software developer and I never had to deal with an "Operations" team. My understanding is that it's the people that would be doing Amazon's job if you were trying to not use AWS or some other cloud service? "Devops" means not fighting with those people??? haha
- deleted 7y ago
  [deleted]
- alchemism 7y ago
  I take it you’ve never worked in any of the Fortune 500, then.
  - irrational 7y ago
    I work for a Fortune 150, but I’ve never worked with a operations, devops, etc. team.
    - alchemism 7y ago
      Who monitors production? Who provisions routers, wireless access points, VPN servers? Just because you are “throwing it over a wall” doesn’t mean the team on the other side doesn’t exist.
  - dogprez 7y ago
    I've worked for a Fortune 500 company for the past 5 years, still nope.
    - alchemism 7y ago
      You configure the Cisco routers, then? The company doubtlessly has a CEO, too, even if you are so compartmentalized as to never speak with her.
      - dogprez 7y ago
nbouscal 7y ago
My background is more like yours. For me it’s likely a difference in size and type of companies worked for. > I was hoping that the article would explain what devops really means today and how I can jump on the devops wagon to hopefully make my job of doing all of the above easier. 1. Use AWS Fargate for all of your backend services. Keep the architecture simple enough that complicated service discovery issues etc don’t come up. If you need coordination between services, do it through Redis or similar. 2. Use RDS unless you really need to save money or use unavailable extensions. 3. Use terraform for initially provisioning the above 4. Set up CI/CD such that merges to master automatically update your services. (I like CircleCI’s aws-ecr and aws-ecs orbs for this.) Pretty simple recipe, but it means no setting up servers, no hardening servers, no installing or optimizing software (other than by adding it to the Dockerfile), no installing or optimizing the database. This recommendation reflects what modern devops means to me; opinions differ. To me it means: - Infrastructure as code (terraform rather than clicking buttons in the AWS console then later forgetting which buttons you clicked) - Immutable infrastructure (aka cattle not pets). Never SSHing into a server again. - Automated testing and deployment cleanly integrated with existing dev workflow Obviously there’s a scale at which you have to do something more complex, but I’d say that’s the scale at which you previously would have had an operations team. Getting rid of the “writing server side code” and “writing front end code” parts is beyond the scope of devops, but you can skip a lot of the “writing server side code” part by using PostgREST. In exchange you may have to write an even-more-untold number of SQL queries, depending on your current practices. Edit: Someone helpfully pointed out that I forgot to mention anything about logging or monitoring, which is a pretty glaring omission. On that front I strongly recommend Honeycomb. To set it up with Fargate you may need to run it in a sidecar container, but it’s fairly straightforward.

commandlinefan 7y ago

> make my job of doing all of the above easier. That’s the dream… the reality in my experience is that you have to describe, in detail, the exact steps that you would perform if you were doing it yourself so that somebody else can perform them, verbatim. But you have to describe those steps, exactly, without any access to the target platform where they’ll be performed.

Andhurati 7y ago
Does it get any better? I feel like I'm on thin ice whenever I deploy. Granted, I now try to make sure the SAs have to do as little as possible (because now I "understand" the infrastructure, I can build a postinstall that handles all the environment configuration I am allowed under an FID), it still feels nerve wracking to know that a single fuck up means I have to spend another 4-5 hours trying to get tickets to deploy. Fuck this.

walshemj 7y ago

And its also written from a very recent perspective, arguably I was formally working in devops in the 80's I was hired as development team member partially as I was a sysadmin on the hardware we were using, our team both wrote the code but also the entire JCL infrastructure that managed the compilation linking, deployment and the running of code across the cluster of 16 or 17 systems. On of my friends, an IBM guy from the operations side was shocked that we as developers where allowed to deploy and run our own code.

dogprez 7y ago

The article is lost on me too. ~15 years professional experience as a software developer and I never had to deal with an "Operations" team. My understanding is that it's the people that would be doing Amazon's job if you were trying to not use AWS or some other cloud service? "Devops" means not fighting with those people??? haha

deleted 7y ago
[deleted]
alchemism 7y ago
I take it you’ve never worked in any of the Fortune 500, then.
- irrational 7y ago
  I work for a Fortune 150, but I’ve never worked with a operations, devops, etc. team.
  - alchemism 7y ago
    Who monitors production? Who provisions routers, wireless access points, VPN servers? Just because you are “throwing it over a wall” doesn’t mean the team on the other side doesn’t exist.
- dogprez 7y ago
  I've worked for a Fortune 500 company for the past 5 years, still nope.
  - alchemism 7y ago
    You configure the Cisco routers, then? The company doubtlessly has a CEO, too, even if you are so compartmentalized as to never speak with her.
    - dogprez 7y ago

nbouscal 7y ago

My background is more like yours. For me it’s likely a difference in size and type of companies worked for. > I was hoping that the article would explain what devops really means today and how I can jump on the devops wagon to hopefully make my job of doing all of the above easier. 1. Use AWS Fargate for all of your backend services. Keep the architecture simple enough that complicated service discovery issues etc don’t come up. If you need coordination between services, do it through Redis or similar. 2. Use RDS unless you really need to save money or use unavailable extensions. 3. Use terraform for initially provisioning the above 4. Set up CI/CD such that merges to master automatically update your services. (I like CircleCI’s aws-ecr and aws-ecs orbs for this.) Pretty simple recipe, but it means no setting up servers, no hardening servers, no installing or optimizing software (other than by adding it to the Dockerfile), no installing or optimizing the database. This recommendation reflects what modern devops means to me; opinions differ. To me it means: - Infrastructure as code (terraform rather than clicking buttons in the AWS console then later forgetting which buttons you clicked) - Immutable infrastructure (aka cattle not pets). Never SSHing into a server again. - Automated testing and deployment cleanly integrated with existing dev workflow Obviously there’s a scale at which you have to do something more complex, but I’d say that’s the scale at which you previously would have had an operations team. Getting rid of the “writing server side code” and “writing front end code” parts is beyond the scope of devops, but you can skip a lot of the “writing server side code” part by using PostgREST. In exchange you may have to write an even-more-untold number of SQL queries, depending on your current practices. Edit: Someone helpfully pointed out that I forgot to mention anything about logging or monitoring, which is a pretty glaring omission. On that front I strongly recommend Honeycomb. To set it up with Fargate you may need to run it in a sidecar container, but it’s fairly straightforward.