Accelerating software delivery has been an important organisational goal for well over a decade, and the new software economy is making it even more so.
As I’m sure you’ve noticed, digital disruption is very real. The past few years has seen profound change across many established industries (with repercussions felt across tens, if not hundreds of thousands of businesses), and it’s clear that we’re only just getting started.
Established companies have to resist the temptation to perpetuate “business as usual”, instead remodelling their businesses to create and serve the new kinds of value demanded by customers in a digital world. And if the incumbents don’t do it, a new entrant into your market will.
“The traditional core competencies of existing companies often become less like industry-defending fortresses and more like deadweight.”
– Digital to the Core. Mark Raskino and Graham Waller.
Technology is no longer considered simply a support function; it is core to product performance, customer satisfaction and ultimately to the success of your business. Every industry is in the process of being remastered, and no-one is safe.
One thing is certain though, and that is that the winners will be the ones whose businesses can adapt to change the fastest. The curve is starting to bend, and we need to make sure that the pace of change inside the organisation matches, or if possible is ahead of, the pace of change outside.
In this context, I’d like to discuss the importance of DevOps. It is my belief that DevOps is fundamental to the future success of your organisation.
In the worlds of software development and project management, the evolution in approach from Waterfall to Agile took the best part of a decade to catch on in most organisations. Then came DevOps — a phrase coined by Patrick Debois in 2009, which is now setting the industry on fire at an incredible pace.
In 2015, Gartner found IT organisations that had chosen not to pursue DevOps were in the minority. More than 60 per cent of organisations it surveyed claimed they were already using DevOps or had pilots in place, or that they had plans to implement DevOps during the next 24 months.
So what is DevOps?
If you were to ask ten IT professionals you’d get ten different answers. DevOps is often used (incorrectly) to describe “full-stack” developers who are expected to master — in addition to their software development responsibilities — the traditional responsibilities of “Ops”, which is a blanket term used to describe the work performed by systems engineers, system administrators, operations staff, release engineers, DBAs, network engineers, security professionals, and various other disciplines.
Which sounds like a bum deal if you ask me.
If you expect your developers to be “always on call”, you’re not doing DevOps.
One of Agile’s overarching goals is “continuous improvement”, a principle borrowed from the Japanese “Lean” manufacturing approach called Kaizen. It is this — enabled by the advent of API driven cloud infrastructure and pioneered by AWS — that has lead to the emergence of DevOps. DevOps can be thought of as an approach that extends Agile’s application of continuous improvement from development and testing, to include the process by which the application and the environment itself is delivered.
Getting this right certainly doesn’t mean overloading your developers; it means making fundamental changes to the way in which development and operations teams have traditionally worked.
“DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.” — The Agile Admin
DevOps and “Shifting Left”
As Agile teams adopt a DevOps approach, they’re known to be “shifting left” — as in shifting Ops responsibilities to an earlier stage in the software delivery lifecycle. The goal of DevOps is to bring Dev and Ops together, not just at deployment time but all through the development cycle.
Companies that incorporate DevOps practices simply get more done. Improved time to production, business value and cost savings are typically cited as the top three drivers for DevOps adoption, but there’s more:
- Faster delivery of features
- More stable software
- Faster resolution of problems
- Less complex problems to fix
- More time is spent adding value (rather than fixing and maintenance)
The Agile Journey
Phase 1 all started with the web natives. They were the Agile/Scrum and AWS pioneers, driven by a desire to improve development speed, quality and scalability. Waterfall development approaches were shown the door, and now the world’s Corporates and Enterprises have started catching on too.
Not long after Agile took hold, the concept of Continuous Delivery (CD) was born to address bottlenecks in software deployment. CD can be considered the 2nd phase of Agile, and was a natural extension of Continuous Integration (CI), a quality control mechanism used in Agile development. Agile’s primary scope was to accelerate and improve the development of software, and Continuous Delivery saw the scope extended to include the deployment of code into production — previously an operations task.
It’s no surprise then that the 3rd phase of the Agile journey is known as “DevOps”. Continuous Delivery without the involvement of Ops had limited success and led to the emergence of the term “Fragile Agile” – where a lack of operational rigour almost always leads to quality problems.
To combat this, Agile organisations are now working to unify development and operations capabilities within the same delivery team — leading to highly effective CD practices, improved quality and velocity. Phase 3 of the Agile journey can be described as organisational or cultural change.
Increased collaboration between Dev and Ops also means increased empathy. Developers are now building software that considers an operational perspective from the outset, and operations people are taking an engineering approach to tackle Ops-related problems – problems that used to be dealt with procedurally. This, and greater use of infrastructure automation results in greater stability and resilience for your applications.
And now we’re entering the 4th phase – Microservices – which seeks to address application architecture constraints.
Most software today is delivered as part of a single “application stack”. In the fast moving world of web native applications, this ageing architecture is far from ideal. As your business scales and increases in complexity, it becomes an impediment to new feature delivery, and the lack of scalability causes maintenance and stability problems.
So what are Microservices exactly? Pioneered by companies like Twitter and Netflix, it’s the name given to a new architectural style; an approach to developing an application as a suite of narrowly focused, independently deployable services.
Breaking what were once monolithic applications into discrete, business-focused services is far more suitable to Agile/DevOps methodologies and culture.
Read more about the limitations of monolithic applications and why Microservices rock here.
Finally, it’s worth noting that while often used interchangeably, Containers and Microservices are not the same thing. A Microservice may run in a Container, but it could also run as a stand alone virtual server. Containers are however, a popular way to develop and deploy Microservices. You can read more about containers here.
Are you on an Agile/DevOps journey?
Reduce risk, simplify deployments & increase your team’s velocity. Talk to us about embedding experienced cloud operations specialists (Scrum Master & AWS DevOps certified) into your team today.