Cloud native series: Hard truths in soft clouds, DevOps lead at PagerDuty
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source – computerweekly.com
This is a guest post for the Computer Weekly Developer Network written by Eric Sigler in his capacity as head of DevOps at PagerDuty.
Pager Duty offers what it calls a Digital Operations Management Platform that aims to integrate machine data alongside human intelligence on the road to building interactive applications that benefit from optimised response orchestration, continuous development and delivery.
Sigler writes as follows:
These days it’s rare that I speak with a customer building on-premises only infrastructure.
Most companies I speak with are moving to the cloud [model] in some capacity, have already migrated, or were built from scratch in the cloud. As a result of this huge shift in how companies approach their infrastructure, many are inevitably and necessarily adopting a cloud-native architecture.
Forcing function
Going cloud native acts as a ‘forcing function’ for how applications are built on top of infrastructure.
Because you’re standardising on the behaviour of lower-level components like compute and network, what you’re effectively telling individual teams working on these smaller, more agile units of software (be it ‘service oriented’ or ‘microservices’) is
“Please stop spending all of your time reinventing the wheel [in respect of] everything below the application layer.”
This is where traditional or virtualised application design tends to fall down, as you end up spending lots of time reinventing how you ship that software. Which is a painful process, and one that doesn’t often result in useful business value.
Failure 5#1t happens
There are a couple of different, related useful mindsets to remember. The first is just to accept that failure happens, yet this is an area where many software developers tend to treat their software as a precious, unique snowflake.
If, for instance, the network breaks, it’s assumed that the software had nothing to do with that failure – but that’s not the case. Failure happens at all parts and in all aspects of operating a cloud-native infrastructure. In my experience, you ignore this reality at your own peril.
A dependency on dependencies
The second mindset to adopt is that you can’t ignore external application dependencies, such as DNS providers or SMTP delivery services.
Own your dependencies or they will own you.
This isn’t a new concept, but whatever you are building, it’s the responsibility of the service under your control to deliver. Your customers won’t care what downstream dependencies you use, or what problems they had. You must have that engineering in place so that when a dependency fails, you can rapidly recover.
Collaboration confrontation
Shifting to a cloud-native approach absolutely changes an organisation’s collaboration among its developer and operational teams. With cloud native comes the move to a consistent, standardised set of primitives that a team can use. This is closer to total ownership of that service, which is uncomfortable for some teams.
The operations team in most companies should be shifting toward providing those platforms and the primitives to their developer teams.
- Ops teams are no longer charged solely with spinning up infrastructure; they’re also now there to be enablers for developers.
- Conversely, the developer teams must effectively use these primitives and platforms provided by operations.
Compose-ability
One final aspect that I consider foundational to a cloud-native approach is the importance of small teams working together on smaller services that are then composed together. This leads to far more agility within the business and to a better ability to address the multitude of problems that come innately with software development.
Keeping these points in mind should ease your move to a cloud-native approach and hopefully make it a little less painful.