A Mindset Change..

If you’re not changing, you’re not growing. If you’re not growing, you’re not being intelligent. Humans thrive in change and expansion — yet there can be so many internal or external blocks to change.

Trying to keep things as they are is a very unhealthy approach to life. Avoiding change reflects a misunderstanding of the human condition and human flourishing. Change is not to be avoided, but embraced..

In the IT parlance, change can be viewed as a product release. It can be organization transformation, an infrastructure shift, a new service, or a feature release to a classically developed product.

All of these can benefit from MVE.

MVE is Minimal Viable Everything..

Consider every big change that you are attempting to achieve and then, slice it down to that which is minimally viable. Implement that minimum viable thing, collect feedback from its related consumers, then correct and continue as appropriate.

If you are figuring out how to transform from a classic IT organization to a DevOps organization, start by considering the minimally viable DevOps organization.

That brings us to the question..

What is DevOps in simple terms?

It’s just a catchy way of saying we deliver with Minimum Viable Process using lean techniques to drive waste out of the system. It requires shared goals and shared pain throughout the IT value stream.

Now that we know of MVP, what is the lean technique to drive waste out of the system?

We all want to spend less time in overhead work like meetings, compliance, documentation, late rework, waiting and progress reporting. And we want to spend less time in manual tasks that can be automated. By avoiding these sources of waste AND by steering with continuous feedback and advanced analytics, we can improve the economics and add value to the service.

What exactly does DevOps do?

DevOps is all about rebooting deep-rooted cultural habits, transforming old processes and ensuring all changes are made for the right reasons.

Don’t embrace DevOps for the sake of it. Only proceed if you have clarity and purpose.

What are the challenges in DevOps implementation?

The challenges and risks for DevOps implementation include cultural resistance to change, lack of communication and collaboration between teams, lack of standardization and automation, security and compliance risks, and difficulties in measuring success.

Misnomer and / or Anti pattern??

You have read and come this far and think DevOps is a simple thing to understand and implement..well..Organizations do fell into this trap..

With software buzzwords that people focus so much on what something is that they forget what it is not. DevOps is no exception and this happens when you ask to summarize an extensive concept in a few words.

This anti-pattern is a classic example of why one has to dive deep into something before jumping to conclusions — because “Dev + Ops = DevOps” is the sort of answer that’ll probably earn you only grace marks in an exam. It’s not DevOps just because you combine your development and operations teams and call it DevOps.

Some common Anti patterns include:

• Agile and DevOps Are the Same
• DevOps Is All About the Tools
• You Need a Dedicated DevOps Team
• DevOps Gets Rid of Operations
• DevOps Is Only About Automation

What are the list of DevOps Tools?

Well I won't delve into listing out all that is available by dozens of DevOps tool..I would rather present a picture below worth a thousand words..

What is DevSecOps?

Phew..Just when you have had enough of technical Jargon..I irritate you with another argot..!!

Relax.. I will simplify...

DevOps has a focus on efficiency while DevSecOps focuses on security. DevSecOps builds upon DevOps to address vulnerability at every stage.

How DevOps and SRE are different?

A simple rule to differentiate SRE from DevOps is:

If your engineering team has reliability/performance/uptime requirements that need someone to carry that torch on top of feature development : You might need an SRE.

At a higher level, the SRE team serves as a bridge between development teams and operations teams, enabling the development team to bring new software or new features to production as quickly as possible, while also ensuring an agreed-upon acceptable level of IT operations performance and error risk in line with the service level agreements (SLAs) the organization has in place with its customers.

Based on their experience and a wealth of operations data, the SRE team helps the development and operations teams establish

• Service level indicators (SLIs)
• Service level objectives (SLOs)
• Error budgets

In this article from Google, the company behind SRE concept, they state that SREs can use DevOps practice, but they don't necessarily have to. Maybe that's where the confusion comes from?

On a day-to-day, Site Reliability Engineers do not answer to the same hierarchy of other software engineers, so they should not be biased by any feature delivery, yet, their responsibility is to guarantee the uptime or any other SLA from their teams.

So what's your resolution??

Hmm..So you have Agile, DevOps, DevSecOps, SRE and many options to choose from..What would be your choice.??

Whatever be your choice, if it need to bear you the fruits, you must first have a change in your mindset..

Srikanth K N