From Zero to Zen with Cloud-Native DevOps

After attending DevOpsDays in Baltimore this past week, I was convinced that the push to cloud-native could not be more resonate. The fear of lock-in and having less control over performance and security has turned upside down. One firm, Fearless—a name that speaks for itself—were sponsors of the event and had many volunteers who contributed to its success. They weren’t afraid of much of anything, wearing silly hats with a super casual style to make the whole event fun along with planned topics, open sessions, and lightning rounds for folks to engage.

For specific cloud-native examples, friends close to us in Washington, DC at DHS provided details of their move to the cloud for the processing of citizenship. PayPal attendees from North Baltimore gave us the rundown for their security payments group to our team of CloudBolt experts, Alan, Jasmine, Lauren, and Sam. These larger organizations, as well as many other smaller teams at the conference, discussed how a cloud-native approach is working for them. Performance and security were not holding them back.

In all cases, the representatives of these efforts described the DevOps culture change that they underwent and how they are now convincing other teams within their organizations to make the shift. It was all very convincing to me, as we at CloudBolt are moving toward deeper partnerships with AWS, Google, and MS Azure. In response to this shift in focus, we’re also strengthening the cloud-native offerings for our prospects and customers.

Why Cloud-Native?

The ability to develop, test, and deploy application architectures from one public provider that scale on demand and take advantage of tightly-coupled, pay-as-you-go services is the future of digital services and what’s considered a cloud-native approach. Using scripts, either in-house or by using Terraform, DevOps teams manage versions of infrastructure as code IaC that connect to provider resources, typically stored in Github. This helps DevOps teams quickly transition from one development state to the next along with the ability to roll back or roll forward from a state that is not successful. According to the DevOps engineers who spoke at the conference and participated in the open sessions, code-based deployments are much easier to manage than using the GUI of their cloud providers.  

The shift to this approach is now what differentiates one company from another, or keeps one team within an organization from “…not being on the front page of the Washington Post” as one of the DevOps speakers for DHS put it.

So, let’s consider what can go wrong and what to do to make the process go smoother. The goal is for enterprise DevOps teams to get the most out of cloud-native application architectures and the value of their subscriptions.

Getting to Zen

As with any initiative, unlimited infrastructure resources for everyone and the ability to have stuff ready to go at a moments notice will make the lives of most DevOps engineers super happy. That is, of course, until someone gets hurt. In this case, the hurt will be the sticker-shock of an unexpected cloud provider bill. In another case, it could be the person or team who has responsibility for the scripting framework, as well as whatever model they’re using for delivering infrastructure, leaving the company while leaving very little documentation. Here are three ways CloudBolt can help:

Resource Management / Self-Service

Connections to public cloud providers from every operator to a specific cloud can lead to inefficiencies. A loosely managed scripting environment will be prone to one-offs that could lead to disasters in troubleshooting. Terraform scripts can access the CloudBolt API and execute any blueprint orchestrated to provision resources through any of its resource handlers. CloudBolt as a self-service portal can also be the starting point of any Terraform script. Having the connections to providers managed in a single platform can make it easier for IT admins and developers will not need to manage this part of the backend complexity.

Cost Control

Although cost control is part of a public cloud provider’s promise, it has not always been true, and probably won’t be first on their list to help enterprise, cloud-native projects. The more you spend, the more they make in profit. At some point, competition will weed out the grip of vendor lock-in and pricing. You can skip this altogether with cost control from a cloud management platform like CloudBolt. Synchronize inventory of Terraform-deployed infrastructure based on resource handlers in CloudBolt, then run checks on what is being utilized and who is using the infrastructure to help make better spending decisions. Even better, you can use CloudBolt blueprints as your Terraform provider and you can build in cost control, quota enforcement, and one, two, or three-tier approvals if necessary.

Extensibility

After development teams have hardened their Terraform scripts or any IT provisioning they do and their apps are in production, they typically throw them over the fence to IT operations who can then manage them and provide oversight. If anything goes wrong, it’s the fault of IT which is not good. Instead, use Terraform with CloudBolt to arm IT operations teams with more extensible infrastructure provisioning workflows that can be orchestrated at either the CloudBolt level or within Terraform from the developers. This way the responsibility is shared as was intended in the first place with DevOps.

Summary

From Zero to Zen means getting the most from cloud-native without runaway spending while having the resource handlers in place to implement a more carefully orchestrated environment that scales with your enterprise.The person or team who left the organization will not have as much of an impact if IT is informed, and using a standard convention of extensibility. The unexpected spending will be in check and developers will not get hit with surprise bills or the grief an IT leader in their organization.

Want to learn more? Read this free ebook!