Habits are the human mechanism for simplifying decisions which drive what we do daily. When thinking about habits, it is essential to recognize they can be good, bad and with respect to our goals.

Heads of technology always have a love-hate relationship with DevOps. A solid DevOps team can provide cutting edge speed, collaboration and delivery but the kind of changes in the culture it brings along is difficult to accept and adapt in some organisations. Despite this, DevOps is being adopted across many organisations due to the good features it brings to the table. Hence, it has even become the new hack to get investment from IT investors these days. But in no way is the importance of DevOps being overstated by organisations that do abide by it. Future of organisations is highly dependent on their ability to deliver software faster and faster while not compromising on security and stability. This article on “10 Habits of all successful DevOps” will familiarize you with 5 best and 5 worst DevOps habits that your organisation can imbibe. ‍

The Good

1. Fail fast, learn fast: Failure is not a sin, it is something you should strive for to succeed in DevOps. Success by failure sounds contradicting. But it is executed by having failure built into the testing process. DevOps means a shift from the worry of failure to a desire to a fail-fast and learn. This does not mean that your goal should be to fail. Rather, you need to look at failure as an opportunity to learn and improve without playing the blame game. The sooner issues are discovered the cheaper it is to fix them, thus making failing early on a benefit. Once you fail fast, you need to learn fast and for this, the 2 most effective techniques are to make sure that you include strong Application Performance Monitoring tools (APM) which help you in identifying what caused the failure and feedback loops that raise immediate alerts in case of failures using tools like Slack to communicate.
2. Architect your delivery pipeline: Organisations need to treat their delivery pipeline like a product rather than a separate set of tools used to move a feature from idea to deployment. For this, they need to have a product owner for the pipelines who define stories and owns prioritization just like business products’ owners. Apart from this, the choice of the right stack matters too. The next great tool for CI/CD is always round the corner and they need to be a part of a company’s DevOps stack for a well-architected pipeline. But they need to be integrated using standard integration patterns and technologies that are model-based so that your workflow isn’t disrupted and the tools work the way they were intended. Customisation creates a dependency that will cost you in future when you need to replace or upgrade certain tools.
3. CI-CD: From being an added star in a company’s tech report card, CI-CD has now become the norm. The discipline of validating a project through automated regression testing whenever there's a commit into the version control system enables the development of quality solutions in small, safe and uniform steps. Continuous deployment helps development teams to scale back the time between a new feature being ideated and deployed in production which ensures responsiveness in companies.
4. Standardising and simplifying the environment: There ` things can be done making standards necessary while adopting DevOps. There is a need to have some rules around how the architecture and unfractured is configured. However, there is a reason why standardising and simplification are mentioned together. Sometimes, when adopting such standards, organisations hit an axe on their foot by overengineering. If teams are not given a certain autonomy, it leads to lower productivity. To prevent this, a right balance can be to have guardrails around how the infrastructure is architected but let teams choose what technologies they think is most effective for their needs.
5. Inculcate good programming habits: This point focuses on some habit changes in programmers that help. A strict no for programmers should be doing something manually even if it automated just because it is one time. This includes builds, merges, deletion of old files and so on. Another habit that should be made mandatory is writing documentation, the lack of which, while might not hurt in the short term, can be a disaster in the long term. Good documentation will make your code better incrementally. Such habits matter because long term maintainability should always trump over short term execution.  ‍

The Bad

1. Making DevOps one person or team’s job: The major failure in DevOps come when it is a one-person or team responsibility. With agile being adopted across the board, changes that occur in one team affect the entire organisation. Along with this, you will also be changing how deployment, monitoring and customer support happens. Thus, for DevOps transformation to truly succeed, silos never work and everyone should be involved and engaged. An easy way to do this is to simply redefine success as a satisfied customer from the current metric of a feature being shipped which will lead to everyone being accountable in the success measurement.
2. Trying to be Netflix: Netflix deploys multiple times a day and tries all new tools, so you should too. Right? No, you could not be more wrong. Organizations need to understand that business value is in observing the impact of each change and the way users react. Patterns of multiple deployments might even end up having negative business value if there are no behavioural patterns formed in end users that businesses can track and measure to make decisions. Ultimately, DevOps is not about being ‘cool’ and not all organisations have the resources that Netflix does.
3. Ignoring security early in the development cycle: There is a tendency of many organisations of being narrow-minded in DevOps with the focus being on faster releases but this usually comes at the cost of ignoring security during the development cycle and in production. The result of this is that there are security loopholes in the product and infrastructure that get missed by the team which leaves the product exposed and additional time is needed to apply fixes upon a breach, which makes security a game of catch up. It is thus a great practice to make security a core part of DevOps goals at your organisation.
4. Overdoing automation: Organisations need to understand that automation is about converting a manual process to automatic using technology. This means that if the manual process itself is flawed so is the automatic one. Automating this flawed process would just make it possible for mistakes to happen at a faster rate. So, organisations should know that overdoing automation would lead them to an unproductive extreme and that the primary focus has to be on understanding the requirement, developing, testing and then automating a process.
5. Making speed your only goal: In today’s world, the constant focus on releases without qualitative improvements is useless. Deployment automation should not be a focus for organisations without test automation. A focus solely on speed shows that while there might be an understanding of the aspects of automation in the organisation, the cultural groundwork of having developers, testers and operations team build automation collaboratively is missing.

The goal behind effective DevOps habits is to enable DevOps teams to maneuver fast with a continuous delivery workflow. Building a DevOps culture isn't an instant process, you can’t simply pull it out of the box. But if you're taking a thoughtful and incremental approach, DevOps becomes a strong combination of culture and tools which will elevate your business to a level of agility and quality that your competitors would find hard to beat. And adopting the above habits of highly effective DevOps will get you there.

It’s your turn now. Tell us in the comment section the habits that drove DevOps success at your organisations and the habits that you make sure are avoided at any cost. For more such articles, follow us on LinkedIn, and if you have queries specific to your business or want to leap into the cloud, drop in your contact details in the comment box and we’ll reach out to you.

As a key decision-maker, it feels that you just can’t ignore the big buzz words of technology like AI, Computer Vision, Mobile First and so on, and it is just natural to sideline DevOps Transformation as a buzzword that will fade out soon. But, doing so would mean missing out on a train of fast-paced, technology-supported growth. Today, we try to explain to you this paradigm simply and understandably.‍

What is DevOps transformation?

‘In an organisation, there is an unwritten coding policy, called throw it over the wall and let the operations team run it. The ops team is usually the one responsible for customer or manager facing tasks and so developers are less worried about buggy code. The incentives are misaligned and there is a vision mismatch between the business and the technology side since everyone is working in their silos.’ Do these sentences remind you of an organisation you have worked/are working with?

DevOps Transformation is a process aimed at breaking down these silos and building an integrated environment working towards a common vision.

While there is no standard definition or way to do it, it is essentially a process that aims at cultural and technological change aimed towards improved communication among business, design, engineering and all other parts of an organisation.
‍

Why should you opt for DevOps transformation?‍

Without beating around the bush, here are 3 solid reasons why you should opt for DevOps transformation.

1. Better quality: While better is ambiguous and every tool and consultant offers it, in a DevOps culture, it can be assured by asking the correct questions, such as the biggest worries, what is lacking and so on to the leadership and planning the transformation around it.
2. More confident releases: Since DevOps addresses essential quality concerns, there will be lesser unpleasant surprises for the team and users. This is because the visibility to the processes increases and the riskiest and critical quality checks are done early on.
3. Higher flexibility: Flexibility in this paradigm is not about changing the business model but rather constant improvements in the release process as business needs change. Early on, speed might be the most important, but later stability will matter more, and this can be achieved incrementally.

These 3 factors together ensure that there is lesser wasted effort and higher predictability, which will directly reflect on productivity and profitability of your organisation.‍

What is the journey going to look like?‍

As you start with DevOps transformation, be aware that it will bring major cultural and procedural changes. It will mark the start of shared decision making. While collaboration and standardisation may be slightly chaotic early on, as time goes by, it will be refined and lead to constant optimisation with the help of the metrics tracked. The process of DevOps transformation is like washing clothes. First, observe. As different clothes are observed for materials and colours, observe where the organisation stands currently on different metrics such as speed and ability to handle change. Next, lather, that is, measure how things work today and find the greatest pain points and bottlenecks. Now, rinse, that is, start fixing the problems that are evident by using tools and techniques such as CI/CD, automation, etc. and streamline them. Lastly, repeat. Remember that this is not a one time process and as new observations crop up, be ready to repeat the process and change incrementally.‍

What are the challenges of this transformation?‍

The journey is not going to be without its challenges. Organisations need to reimagine the structure of doing things and culture. It is important to ensure that you don’t underestimate the effort required. Choosing the right metrics is tough. Focusing just on feature development speed without a focus on corresponding better quality will not yield results. The goals set must be realistic and in line with the limited funds that an organisation can allocate. Lastly, the complexity involved in the process of DevOps transformation must not be undermined. Your IT leaders must be able to answers questions like, ‘Will standardisation improve results or delay innovation?’ and your teams should be ready to overcome resistance to change and relearn many ways of doing things.‍

What is the future going to look like?‍

The DevOps transformation journey is most going to be an ongoing journey since new paradigms will keep on emerging, but its core mission will remain the same. With the involvement of AI, automation will play a major role in the transformation. AI, with machine learning, will put the focus on anomaly detection, predictive insights and performance baselining which will speed up mundane and repetitive tasks. AI will also take in metrics and put actionable insights from the data. All of this will ultimately sharpen focus on cloud optimization.

Be it about habit, health or DevOps, transformations are tough. Fortunately, we can help you with at least one of them. Feel free to reach out to us for any help or advice on DevOps Transformation and use the comments section to tell us how DevOps Transformation helped your business scale new heights.

Businesses across the globe are experiencing unparalleled change today across operations, services, fulfilment and customer experience, at the core of which is technology. Yet, not many businesses harness the power of technology fully and continue using legacy systems. Legacy systems are simply systems that are outdated but still in use. Legacy software and hardware are not reliable and run slowly or may not at all be supported by the vendor. In this article, we talk about why and how you can harness the power of the cloud for your business.

What is cloud migration?

It simply is the process of moving digital operations to the cloud. It’s like a physical move, but instead of goods, data, applications and IT processes are moved and much like a physical move, a lot of advance work is required but it ends up being worth the effort by resulting in high savings and flexibility. Sometimes it might also mean moving from one cloud provider to another for added benefits.

What if I am creating a new system?

In that case, a business should opt for a cloud-native approach. Cloud-native is an approach that exploits the benefits of the cloud delivery model. It is more about how the applications are created and deployed rather than where, which is implied to be the cloud. Cloud-native uses open-source software stacks in a containerised fashion. The architecture is more micro-service oriented for agility and maintainability. Using these modern tools in an agile fashion improves the performance of your system by many folds.

Different strategies of adapting to the cloud

Gartner, a technology research company, lists 5 strategies for businesses to migrate to the cloud, commonly known as “5 Rs”

Re-host - Re-hosting is having the same applications on cloud-based servers. Companies doing this select a cloud provider such as Amazon Web Services or Digital Ocean and recreate the application architecture on the cloud provider. In terms of a physical move, this means shifting your office to a new but empty flat and recreating the interior just as before.

Refactor - Refactoring would mean that companies use the existing code and frameworks but run it on a Platform-as-a-Service (PaaS) provider. In our office shifting analogy, this would be something similar to telling an interior designer to make a similar office for you, but not doing the work yourself. This makes the process of deployments abstract and makes the developers more productive.

Revise - This strategy includes partially rewriting or expanding the code and architecture then deploying using re-hosting or refactoring. This will help in addressing the limitations and drawbacks of the current system and tapping the advantages of the cloud system. If your new physical office had 100 sq ft. of extra space, your new plan would obviously take that into consideration.

Rebuild - Rebuilding would involve starting from scratch as the name suggest. The entire application must be rearchitected and rewritten from the ground up making it a tedious process, but this process ensures that the application is written in a way to exploit all the features of the cloud. This would mean breaking down the new office you buy entirely and make it in a newer design for more benefits.

Replace - Here, you discard your current application and switch to an existing Software-as-a-Service solution. This would mean shifting your office to a fully managed office space or moving to a co-working space.

Benefits of moving to the cloud

1. Improved customer experience: Customers don’t care about what goes on under the hood. In the end, they want a reliable system with maximum features. Developing on the cloud makes releases faster and more scalable. Better monitoring techniques also help in lesser downtime in case of a failure. These factors improve the customer experience many folds.
2. Lower Costs: Cloud saves you cost in maintenance and upgrades since the provider takes care of them. Cloud also releases you from the shackles of vendor lock-ins that traditional providers have, charging you by the minute instead, thus giving you more predictability of costs. Using modern methods of deployment such as a microservice architecture and containerization further lowers costs.
3. Easier compliance: With new privacy and data protection laws coming up in each country, it is extremely important to comply as soon as possible to serve customers in those countries. Major cloud providers already comply with standards such as GDPR, ISO 27001, SOC 1 and more to take that trouble off your heads.

Depending on your needs, you need to create a strategy to move to the cloud. Some companies choose a single cloud provider, for simplicity, others use multiple providers to get the best of all worlds and yet others have a hybrid cloud-on premise model, which might need tight integration. Regardless of the strategy, you choose, we can handhold you during the transition and till a point of self-reliance. Comment below which strategy you think would work for your business and feel free to reach out for more guidance.

‍

In times of disruption, businesses, especially small and mid-sized ones need to come up with resilient business models to drive through the challenges and be ready to leap on to growth opportunities