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!
On a typical Monday at CloudBolt we have a weekly meeting called “Chalk Talk” to discuss industry trends. Recently, Sam Collura from our Inside Sales Team asked, “When are we going to talk about Terraform?” and continued, “A lot of my prospects are asking about it, and… I think we need to be able to discuss our integration better.” Sam as many others are hearing is that Terraform has become quite popular for DevOps and developer workflows.
Terraform has been an important homework assignment of mine because the industry is getting more accustomed to agile workflows with code-based workflows. Sam’s question was not the first time and will not be the last time we’ll hear about it from our CloudBolt prospects.
After that Monday, I went to work and studied the engineering work from our team in Portland who, incidentally, just received the “Most Influential Technology Company in Oregon Award”. I found that we’ve been working on integrating with Terraform for quite some time to take advantage of its code-based provisioning of resources—since 2016 specifically. Although we don’t have an OOTB plugin today, our extensible framework complements Terraform a number of ways. Essentially, we can help to make IT administrators who automate with Terraform into heroes for their dev teams.
Terraform Explained
Terraform as Infrastructure-as-Code (IaC) is a great tool to get infrastructure to developers who use continuous integration/continuous delivery (CI/CD) application development workflows. The Terraform code that is used to deploy infrastructure is maintained in a GitHub repository with versioning so that incremental changes to the underlying infrastructure can be tracked and shared.
Developers who are coding applications need an environment where they can do coding with consistency, especially when multiple developers are working in environments that must be identical. Their adoption of Terraform is no coincidence, as developers and DevOps engineers have been doing a very similar version control with branches of code that they are developing to merge into the main core application. This helps to ensure that efficient and stable application code goes from development to testing and then into production without a hitch.
Over time, certain workflows using Terraform become common, so there is the ability to modularize parts of the deployment scripts to be reused for the wide range of infrastructure needs for developers. This is a great video to get familiar with how Terraform works, Provisioning VMs to Public Clouds with Terraform.
Customers can use Terraform Open Source or Terraform Enterprise from Hashicorp. The latter provides organizational features that help to manage development for enterprises.
Terraform & CloudBolt
CloudBolt works well with Terraform, especially when the scripts and development environments have matured and can be used in enterprise-wide workflows where visibility and control at scale take on more importance. CloudBolt can synchronize and manage running infrastructure from the various environments where infrastructure is deployed by Terraform. CloudBolt can also be used as the provider that Terraform calls to provision resources.
You can then configure CloudBolt and Terraform together to enforce quotas, power schedules, and expiration dates for enterprise-wide full, lifecycle management of the infrastructure. This can be enforced and reported for each business unit or group where the value of the infrastructure is tied directly to business outcomes.
Here’s a summary of key uses and benefits:
- Resource Management / Self-Service—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—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.
- Extensibility—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. After development teams have “hardened” their Terraform scripts, they typically throw them over the fence to IT operations who can then manage them in production and provide end-users access.
The adoption of agile frameworks for both application development and infrastructure provisioning continues to be a huge differentiator for successful enterprises. The ability to innovate faster and deliver value responsive to your market demand is the underlying objective for using the code-based infrastructure provisioning from Terraform. Having the visibility and control from a single platform using CloudBolt gives you the ability to provide faster time to value with a self-service IT portal as well as the ability to control costs and respond to any changing requirements with an easy-to-use, extensible platform.
To learn more about how CloudBolt enables self-service IT and empowers your end-users, download this free eBook!
Top-rated restaurants have cooks, servers, and patrons who each thrive by getting everything they need to create, deliver, or consume something scrumptious that has value during a specific time and date. Each role requires a different set of skills and involves doing something different as the main objective. There’s definitely some overlap, as a chef might need to taste dishes to make sure they’re just right, or patrons serve themselves from a buffet or counter line.
In a similar way for IT provisioning, distinct roles for creating, delivering, and consuming digital resources thrive in a fast-paced enterprise. It’s no coincidence that we hear terms like recipe to characterize IT provisioning as a sequence of interdependent steps. There’s even a brand called Chef for application deployment. Here’s a set of top enterprise projects to provision as part of a thriving IT restaurant or enterprise.
Raw Ingredients/Resources for Developers
At the foundation of any digital enterprise, developers need the infrastructure to build on and deliver code at regular intervals. The code runs the digital business of the enterprise, and can be anything from programmatically displaying choices in an online eCommerce site to updating the GPS location of your rideshare driver on an interactive map. Typically, the code can be running on virtual machines (VMs) that are discrete servers with an operating system (OS) and computing power required to support the code. More modern technology includes code that runs in containers that are more modular, but still have the underlying OS that needs to be provisioned. Recently, the major public cloud providers offer “serverless” computing where developers need to only submit the code they want to run and the provider runs it, abstracting the infrastructure that runs from the end user (developer).
Test Kitchens/Support Environments
Enterprises need to have environments that they can test or troubleshoot in without introducing problems in the “real” production environment. If these test or support environments that mirror the real environment can be spun up or down on demand, the enterprise will save a lot in time and resources. By not having to start from scratch each time there’s a test or support case they save a lot of time. If the infrastructure is running in a public cloud environment, the monthly bill for these resources will be a lot less when the infrastructure is only running for the period of time required rather than on 24/7. These environments are also good to use in training classes for both internal staff and end users who might be customers using a system that is developed and sold by the enterprise.
Franchising/Expansion
A repeatable, standardized set of IT resources can be configured for automation. A new banking branch, a fast food venue, or new line of clothing can be set up and delivered as an IT bundle that interacts with all the physical and digital touch points of a business. Think of your favorite fast food chain that opens a store in a new location. When you go, you have the expectation of consistency for how you order, pick up, and pay. All of the digital processing required to do that could be a “blueprint” that is ready to go whenever the new business is opened and with all the backend servers, VMs, and connections to accounting or databases set up so that they do not have to be created from scratch every time. There are specific settings for the location of the business but the bulk of it can be already set up and available.
On-Demand Service/Big Data Processing
Providing the big data processing infrastructure with the compute power to analyze large volumes of data requires a lot of planning and capital expenditure to stand up in a traditional data center. Many enterprises have found that this is too costly to maintain, so they are turning to public cloud providers who have ready-made big data processing and the complicated Apache Spark and Hadoop clusters required to process on-demand in the cloud. Enterprises only need to run it when necessary, and there’s no need to hire a data architect or infrastructure admin to install and maintain the same IT resources required to do the equivalent processing on-premises.
CloudBolt Automation for IT Projects
Enterprise projects like these that need to be provisioned can be anything from the raw resources for developers to use to build an application stack to run in production to the big data processing projects on demand. Just like a smoothly run restaurant, the IT environment can be configured to get the digital assets to the right people at the right time to create, serve, or consume. All of it can be configured and some of the steps automated in a CloudBolt Blueprint.
Ready to see how CloudBolt can help? Request a demo!