Are you a Salesforce or an Uber? Choose wisely, devs

Know when to break out the emergency release tools...

Comment There’s no one-size-fits-all when it comes to DevOps. In small operations DevOps will likely mean very little as developers will probably already be managing production environments in addition to the deployment of applications.

At the other end of the scale, in very large organisations - where there are well-defined lines between the different roles of development and operations - DevOps is seen as a major change. In between, there is a whole spectrum.

Hence, there will be a range of views when you mention DevOps – from those who see it as a marketing ploy to those who view it as transformational.

Whether you appreciate the term or not, the objective of smoothing the movement of an application from development to production will resonate with organisations of all sizes.

It seems we can't stop hearing about how organisations need to be more agile and move faster to support innovation in order to be successful. Often the industry looks to startups for inspiration as to how to achieve these goals. Uber and Airbnb have become poster children for the very types of IT organisation that many traditional businesses now aspire to be.

But more recently DevOps has come to be conflated with the concept that of continuous deployment. This is often taken to mean that updates to an application can be delivered to production almost instantly and that this should happen very frequently. A good example of this is Amazon, which delivers updates every few seconds. The result is that many businesses whose ambition is DevOps end up trying to achieve continuous deployment. That can lead to other problems.

So, if the objective of DevOps is not continuous deployment what should it be and why should organisations care?

The truth is that we now live in a world where stakeholders demand new software and updates to existing products faster than ever. This has been driven by the experience of using applications on mobile devices and from the use of cloud-based applications. These apps are smaller and more lightweight point solutions compared to many of the big enterprise applications of the past.

This creates a challenge for organisations in terms of speeding up the delivery of their software far beyond what they have done in the past. It makes sense that mobile apps can be delivered and iterated upon quickly as new use cases rapidly emerge and user requirements change. But for many of the more traditional, and core critical applications, the quarterly release cycle may still be very suitable.

Salesforce, who could be seen in the same ilk as Amazon or Uber, still sticks to this type of release cadence. That is because their customers – enterprises – do not actually appreciate constant changes and such an approach could have significant cost implications for them. But for anyone involved in application development there are other important concerns aside from just adding new features.

For a bank, a bug in an application could cost large amounts of money every minute, hour or day that it remains unfixed. For many businesses a security breach could have significant legal, cost and brand image implications. The longer it goes on the worse the problem becomes. In these scenarios, the ability to develop an appropriate change to the application, test, approve and deploy it as rapidly as possible is incredibly beneficial.

This is what DevOps is about: the old adage of just because one could deploy continuously does not mean one should. It is not that putting in place the necessary processes DevOps requires should result in organisations deploying application updates every few seconds, minutes, hours or even days. But that in the important event they need to move super fast the ability is there.

This might be because a bug needs fixing, a security hole patching or some user feedback needs addressing. Each organisation will need to decide for themselves the main reasons just as long as one recognises why DevOps is important to them. We should not all be chasing why it’s important to someone else such as Amazon.

DevOps is like the fire safety procedures in any office. You won't need a fire extinguisher or an evacuation plan every day but they are there because when there is a fire having them is incredibly helpful. For this reason, whether a business is large or small they should care about DevOps. ®

Similar topics

Other stories you might like

  • Battlefield 2042: Please don't be the death knell of the franchise, please don't be the death knell of the franchise

    Another terrible launch, but DICE is already working on improvements

    The RPG Greetings, traveller, and welcome back to The Register Plays Games, our monthly gaming column. Since the last edition on New World, we hit level cap and the "endgame". Around this time, item duping exploits became rife and every attempt Amazon Games made to fix it just broke something else. The post-level 60 "watermark" system for gear drops is also infuriating and tedious, but not something we were able to address in the column. So bear these things in mind if you were ever tempted. On that note, it's time to look at another newly released shit show – Battlefield 2042.

    I wanted to love Battlefield 2042, I really did. After the bum note of the first-person shooter (FPS) franchise's return to Second World War theatres with Battlefield V (2018), I stupidly assumed the next entry from EA-owned Swedish developer DICE would be a return to form. I was wrong.

    The multiplayer military FPS market is dominated by two forces: Activision's Call of Duty (COD) series and EA's Battlefield. Fans of each franchise are loyal to the point of zealotry with little crossover between player bases. Here's where I stand: COD jumped the shark with Modern Warfare 2 in 2009. It's flip-flopped from WW2 to present-day combat and back again, tried sci-fi, and even the Battle Royale trend with the free-to-play Call of Duty: Warzone (2020), which has been thoroughly ruined by hackers and developer inaction.

    Continue reading
  • American diplomats' iPhones reportedly compromised by NSO Group intrusion software

    Reuters claims nine State Department employees outside the US had their devices hacked

    The Apple iPhones of at least nine US State Department officials were compromised by an unidentified entity using NSO Group's Pegasus spyware, according to a report published Friday by Reuters.

    NSO Group in an email to The Register said it has blocked an unnamed customers' access to its system upon receiving an inquiry about the incident but has yet to confirm whether its software was involved.

    "Once the inquiry was received, and before any investigation under our compliance policy, we have decided to immediately terminate relevant customers’ access to the system, due to the severity of the allegations," an NSO spokesperson told The Register in an email. "To this point, we haven’t received any information nor the phone numbers, nor any indication that NSO’s tools were used in this case."

    Continue reading
  • Utility biz Delta-Montrose Electric Association loses billing capability and two decades of records after cyber attack

    All together now - R, A, N, S, O...

    A US utility company based in Colorado was hit by a ransomware attack in November that wiped out two decades' worth of records and knocked out billing systems that won't be restored until next week at the earliest.

    The attack was detailed by the Delta-Montrose Electric Association (DMEA) in a post on its website explaining that current customers won't be penalised for being unable to pay their bills because of the incident.

    "We are a victim of a malicious cyber security attack. In the middle of an investigation, that is as far as I’m willing to go," DMEA chief exec Alyssa Clemsen Roberts told a public board meeting, as reported by a local paper.

    Continue reading

Biting the hand that feeds IT © 1998–2021