DevOps is not an individual role, it is a group effort.
Your infra should be able to handle a failed deployment automatically and rollback. If it can’t, you’re doing it wrong.
The meaning of DevOps is different to different people.
If any task cannot be automated, remove it instantly from the task list.
Communication is more important than tooling and will make or break an organization.
Shift the focus of Security to the left in the development life-cycle.
Using Jenkins != CI/CD or DevOps …
Always design with autoscaling in mind. Automate-all-the-things. One-click deploy to one-click revert.
Create ready to use images in AWS and use those images for auto-scaling instead of scripted from GitHub builds.
There is a real skillset shortage in the DevOps field. See 'Why it is difficult to hire for DevOps?'
The CI/CD pipeline is one of the best practices for DevOps teams to implement, for delivering code changes more frequently and reliably.
Do not automate a bad process, you end up with an automated bad process — [Credits: DOES18 ]
Testers who know how to code and automate scripts to test various cases are in massive demand in DevOps.
Add monitoring to infrastructure as well as applications. The monitoring system should send alerts on every important events.
Utilize Infrastructure as a code templates to build the infra. Ex. cloud-formation, terraform etc
Serverless is not actually serverless, it is simply 'pay as you use' model
Cloud-native is not a synonym for microservices or Kubernetes, it is all about utilizing the advantages of the cloud computing model
-
Make use of container registries for publishing, storing, locating, downloading, and managing container images
-
Golang and DevOps are made for each other.
-
The recent cloud acquisitions have created confusion in the market, it is time to step up and make a move.
towardsdatascience.com
Your turn. Share your learnings:)
Top comments (7)
You mentioned a lot of good things. There's some that will cause frustration and failures if embraced, plus they go against the fundamentals of DevOps...
2 - Your infra should be able to handle a failed deployment automatically and rollback. If it can’t, you’re doing it wrong.
12 - Do not automate a bad process, you end up with an automated bad process
16 -If you need to SSH into your VM then your automation is failed.
All of those are the opposite of DevOps. DevOps, as anything in life or software, is a progression. All three of the above imply that we can wave a magic wand and things will be at 100% satisfaction instantly. I'll comment on each one, in the hopes of bringing some DevOps clarity...
2 - Your infra should be able to handle a failed deployment automatically and rollback. If it can’t, you’re doing it wrong.
The first step in DevOps/CD is to have an automated deploy, not have one that is also revertible. One of the most important aspects to learn about DevOps, is it's not about rules and regulations, it's about the Journey to be be better, with a set of goals in mind. #2 above is important, but it's not "doing it wrong" or "failed" if you don't achieve that right out of the gate. In fact, I'd argue that if you rush into that, you'll have a tangled web of nastiness to cleanup after the fact. This actually leads into comments for #12 as well, which will shed more light on the matter.
12 - Do not automate a bad process, you end up with an automated bad process
This one would really fall into proper practices on "refactoring". If you have a bad process, you absolutely should automate that bad practice first, and "as is". That way, you start off with something familiar, something that you know works, etc, no matter how non-idealistic it is, before you start refactoring it. And, in the process of building that "bad process" you learn all the nitty gritty details about why it's bad, which will help you plan to get away from it. This is one of those foundational refactoring strategies; start with what is working now, and slowly, incrementally, move to something better!
16 - If you need to SSH into your VM then your automation is failed.
Again, this seems to imply there's a magic wand that we can somehow get from where we are now, to a perfect state. Did you know that AWS recommends having a way of SSHing into your ECS containers if necessary, for diagnostics purposes? You absolutely must have a way of getting into your containers, but you should also avoid the need to do so by incrementally improving your systems to handle problems automatically.
Nicely put, DevOps is truly a journey.
16 is hilarious. More quirky than one can imagine.
Removed it. I didn't put it properly.
I know, it is hilarious and I removed it
Hi Pavan like your post & feel it informative as well but can you explain point no. 16 i didn't get it.
Sorry, I removed it since it was causing a lot of confusion:)