[irrational]

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]

> 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]

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]

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.

[nbouscal]

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.

[dogprez]

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

[alchemism]

I take it you’ve never worked in any of the Fortune 500, then.

[irrational]

I work for a Fortune 150, but I’ve never worked with a operations, devops, etc. team.

[alchemism]

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]

I've worked for a Fortune 500 company for the past 5 years, still nope.

[alchemism]

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]

I think the mismatch is that I never developed websites, think games, media tools, developer tools. Anytime there was a dependency on a web component I was using a cloud service, external or internal. Internal cloud services were operated by different BU's like a separate business. Software was distributed via boxed CD or 3rd party web stores. I've never looked into the eyes of someone that configures routers or even heard them mentioned in all my years. They were always essentially in a different company.

[alchemism]

That makes sense. It is modern in the sense of being structured as cloud services, yet the proverbial walls between Dev and Ops were tall and sturdy, as is the tradition.