DevOps in a Cloud Native World: Two of Tech’s Hottest Terms Collide

What does DevOps for cloud native development look like?

DevOps is the relative old timer of the two, having been popular for a decade plus. But its longevity hasn’t necessarily brought clarity to what it truly means and looks like in practice. Throw in the newer – and even less well understood – cloud native, and confusion is understandably running high.

That’s probably why we’ve found that without an agreed starting point on definitions, these conversations can quickly get off track. Before getting into how they work together we need to set up what they mean – or what they don’t.

Let’s start with DevOps. DevOps is not a service, a product, or a job title. It’s an operating model that merges the development and infrastructure functions into cross-functional teams, enabled by automation and coordinated by agile methodologies. Then, at a high level, “cloud native” development means modularizing your application stack and leveraging microservices to create a serverless architecture and optimize resources. It's about building or modernizing applications to take advantage of and maximize cloud computing’s biggest attributes around scalability, reliability and automation.

And this is where DevOps and cloud native come together. Because what’s modern and cloud native today may not be in five years’ time. Hyperscalers are coming out with new services all the time and the technology advances quickly.

DevOps done right allows you to constantly evolve how you build your applications and your teams, keeping you in lock-step with new technologies almost as they emerge.

There are three prerequisites on the road to a true DevOps state

Getting to a true DevOps state, particularly when also getting to grips with using cloud native services, is a journey. And probably a long one at that. But there are three prerequisites that we see coming together time and again to form the foundations of success.

First, you need to lose any misconceptions over the nature of DevOps and how it’s implemented. Companies don’t create a DevOps team or buy a vendor solution and immediately automate their processes. They do rip out silos and barriers between teams to blend disciplines and enable a shared understanding and purpose. To truly start adopting DevOps and related agile methodologies within your cloud native development, each of these teams has to have the skills onboard to allow it to take end-to-end responsibility for their portion of the product or service.

Second, you must have all the right stakeholders in the room from the very beginning of your journey. Oftentimes, an influential stakeholder has heard “DevOps” in a keynote presentation and comes back to the office saying “we do DevOps now.” That enthusiasm is great but if you don't engage the right people – that’s those leading the development teams, the application teams, the database teams, the infrastructure teams – then it's going to be a rough start.

Finally, let application owners and developers drive the architecture requirements. They will know what technologies they need and what they need in their application stack in order to implement. However, they should be directed by the infrastructure teams to embrace PaaS and SaaS by default. A lot of times teams are coming into this from a place of using instances and VMs. But if someone wants a VM, or a Mongo or Redis database, then in a DevOps world it’s the job of the infrastructure team to find and recommend cloud native replacements. (If, having done the research or as additional development needs arise, you need to revert to VMs – then that’s OK.)

What does true DevOps for cloud native look like when companies launch new releases?

The first thing to say about launches or new releases with DevOps in a cloud native world is that, if you’re successful in combining the two, then those major deployments no longer feel like actual major events. You've smoothed out the creases, got there piece by piece and launch day is just the final piece of the jigsaw. That’s a liberating place to be.

In the final stages, when coming up against that release date, the machine you’ve built will be humming as you bring in each team perfectly on time to gear up load testing in readiness for launch. And that works because you’ve spent months (and then some) working on a plan in which everyone understands what’s needed and when, in terms of getting the dev environment up by X point in time, infrastructure by Y, to meet goal Z.

It’s a symphony. People need to know their part, when to play it and how it contributes to the bigger picture. When it works, it's beautiful. When it doesn’t… it’s discordant

Getting there: is it better to partner up or go it alone?

If you're adopting DevOps and cloud native by partnering up with a third party, you must find vendor personnel and capabilities that complement and enhance what you already have. This is key: you want to plug in skills that match your operational model to create those cross functional teams – you don’t want to create dependencies on external parties. So, if you’ve got a solid development and product team but need help on the infrastructure side, your partner needs to slot in as an extension of that team (rather than being that team). This is called a “do with” approach.

When going it alone, start small and iterate. There will be a lot of technical debt to solve for and a lot of learning on both sides of the house, so it’s going to take patience. But you can experience that winning feeling early on, by picking the low-hanging fruit first and using it as an opportunity to work with the tooling and get everyone used to being in the room together. That might mean automating a very specific aspect of the deployment, or considering the business needs for uptime, backups and monitoring and planning out the first project from there.

The learning is never done with DevOps and cloud native – so start now (or soon, at least)

This is a journey and the destination isn’t a fixed place – there is always more to learn or new challenges to solve when establishing or maintaining DevOps capabilities.

Organizations in the early stages of DevOps are often dealing with traditional IT pain points such as high costs, instance sprawl and uptime issues. But in attempting to solve these issues retroactively, they’re discovering that it’s a lot harder to go back and fix them than it is to consider them from the start. Late stage DevOps companies on the other hand have figured out agile and got their teams talking; there is depth on both sides of the house and a mature understanding of their stack and tooling. But it’s is always possible to optimize costs and performance.

But early stage companies have the most to learn, of course. So we’ll wrap up on the best pieces of advice for tech leaders when it comes to beginning their journey to DevOps and cloud native.

1. Be thoughtful and purposeful with the tools and standards you choose when starting out, to ensure you’re not setting yourself up for future technical debt. There’s a lot of choice out there and it’s easy to just keep adding and adding to your tool chain.
2. Understand where you’re already at in your cloud maturity and DevOps journeys, and create a plan to fix any issues first. Ask yourself: are you still looking at the cloud as just a place where you have your EC2 instances or your VMs, or is it just where your applications live? How are your teams structured and do they complement or hinder each other?
3. Get started, ASAP. Cloud technology is evolving all the time and the longer you wait, the bigger the gap you have to bridge.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.