The Four Pillars of Cloud-Native Operations
As organizations shift their application strategies to embrace the cloud-native world, the purpose of the cloud transitions from saving money to delivering and managing applications. Platforms such as Cloud Foundry, Kubernetes, and Docker redefine the possibilities for application environments that utilize the cloud. It’s time for us as operations professionals to rethink how we approach our jobs in this new world. We should be asking, how do our organizations take advantage of cloud-native as a new mode of application delivery?
In addressing this question, we should strive to make our platforms and services as easy to consume as possible. Both the developer and the consumer rely on us to hide operational complexity and maintain freedom of choice. For the sake of both groups, we should recognize four pillars of cloud-native operations:
- Composability: Application components should be easily composed and connected, for building higher-level services.
- Flexibility: The modern applications team should not perceive their options as limited.
- Programmability: We should stick to an API-first approach to provisioning, deployment, and management.
- Frictionlessness: We should hide the complexity and detail of infrastructure and operations from the modern application team.
Composability
Composability has been a major feature of the cloud since its inception. The typical Lego block composition analogy has already become cliché. So to refresh our perspective, let’s try a real-world example: Some would argue Amazon Web Services’ rapid growth is a byproduct of its first-mover advantage. Others argue that it’s because AWS understood this idea of composability long before others, and exploited this to its advantage.
Elastic Compute Cloud was one of the first AWS services offered, providing users with an easier way to requisition compute infrastructure via an API request. For AWS, EC2 provided a foundation for all its other services going forward. AWS understood that EC2 was not the end game, but the foundation for higher-level services such as SimpleDB and Elastic MapReduce. These services leveraged large clusters of compute instances, along with the Hadoop framework on top.
With cloud-native operations, you should consider the higher-level services you could compose for customers, atop the foundation you’ve already constructed. Services can become foundations in themselves if you ensure they can be easily re-composed into even higher-level services. Certainly, you haven’t discovered every use case yet.
Flexibility
Flexibility can be described as “freedom of choice.” Modern applications teams should have the freedom to choose the application languages, runtimes, and backing services they require. Technology changes too rapidly, so developers should not be limited in their choice based on the service requirements of the past.
Each platform should support a wide range of languages and backing services, or else provide the ability to easily extend itself to support new languages or services that developers may require.
Programmability
Offering cloud services with an API endpoint, along with the composability of services through this API, ensures programmability. This plays well with the principle of flexibility — easily extending a cloud service through a well-defined interface.
Not only should the cloud service offer its open API, it should offer the ability to easily create additional API endpoints. Some great examples of this are AWS’ API Gateway service, and Kubernetes’ custom resource definitions, both of which offer extensibility through an API for your own services.
Frictionlessness
For years you’ve heard talk about the concept known of NoOps, which maintains that in a cloud-native world, operations become virtually nonexistent. Unsurprisingly, this argument has been met with the cry, “But there’s still operations!”
The basic idea behind NoOps is generally correct: Operations becomes transparent and frictionless, from the perspective of the modern application team. Yes, there are still operations, but they’re several layers removed from the consumer. In presenting your cloud services, you should reinforce this idea of reduced friction. You should refine your processes so that, as you add new services, you further reduce the applications team’s operational overhead, closer and closer to zero.
Building services for the modern application team require care and thought. These four principles of Cloud-Native Operations provide guiding concepts for operations professionals to meet the needs of their applications teams. Cloud services should focus on making consumption easy and seamless.
Chef sponsored this story.
Title image of the Four Pillars at the Pakistan Monument in Islamabad, by Mrfaisal007, licensed under Creative Commons 3.0.
