Design, deliver, and run enterprise blockchain workloads quickly and easily.
All servers and systems
DevOps aims to provision and manage physical infrastructure automatically through code rather than manual, hardware-centric processes. In practice building Infrastructure as Code (IaC) capabilities can be challenging.
The principles described here can help shorten and simplify development cycles, and accelerate your business in ways that weren't possible until very recently.
It’s not hard to see why infrastructure as code is soaring to the top of the DevOps agenda. Historically, developers created a software product and handed it off to the IT operations team, which built the infrastructure to run it. That hardware might be very different from the infrastructure the development team used, and might not delivered the expected results.
Quickly provisioning infrastructure was also a challenge. You had to create a business case, get it approved, and then choose and purchase the hardware. The whole process could take weeks or even months.
That's why software teams started building more automated development and test processes. This enabled them to run separate code modules and then check them into the larger code base for systemwide testing.
From the developer's point of view, moving from the system test area to the production environment is simply the next step in the release process chain. As you gain more confidence in the code, you take it from one step to the next until it finally moves into production. This should be a single, continuous process, without any disruption at the point when the infrastructure is allocated.
The operations side of the DevOps team knows a lot more about how the infrastructure works than the developers know—or want to know. The development side of the DevOps organization doesn’t care where infrastructure comes from. They just want it to be available when they need it, and they want it to be flexible enough to make changes easy. In short, they want an infrastructure layer that they can deploy, configure, and manage in much the same way as the application software they’ve developed.
The public cloud is an attractive approach for many developers, as it offers very fast, programmatic access to infrastructure. For example, if you’re building a custom, online application that will be accessed by a global set of customers, cloud-based infrastructure as a service (IaaS) is a natural. You can easily test and make changes, and then roll them up automatically.
The downside of this approach is that the cloud becomes a new silo. And the more clouds you use, the more silos you create. Applications deployed in these different clouds must be managed uniquely and differently from apps running within the enterprise data center. This two-track, or multi-track, approach can create friction within the organization by separating teams into those who support the shiny new, cloud-based digital economy apps and those focused on traditional infrastructure and applications.
Dev and ops teams need one infrastructure that spans both IT modes and can be managed in the same way. If you're using the same team and the same tools, you don’t have to worry about creating and managing a new silo. IaC calls for on-premises infrastructure, with all the programmability and speed of cloud.
IaC combines the functions that make up data center systems into the greater whole that you need to run your applications. Its three main elements define a new category of IT called composable infrastructure:
In a development environment, you need to know that the infrastructure can match whatever your needs are from a software standpoint. How much compute and storage do you need? To which networks are you going to be connecting? You need infrastructure that has all these elements in place, ready to go, without the headaches of configuring them or writing thousands of lines of code to provision, say, a single server.
Infrastructure becomes a set of flexible building blocks that can be assembled and re-assembled on the go to meet changing workload needs. Capacity for physical, virtual, or container-based workloads can be continually aggregated, disaggregated, and re-aggregated to support the needs of specific applications and services. Data storage resources can be defined at the block, file, or object level, based on application requirements, and you can assign bandwidth dynamically, for multiple protocols.
One advantage of this approach is that by treating compute, storage, and networking as fluid, disaggregated resource pools, you reduce the occurrence of over-provisioning and stranded capacity, which contribute to capital expenses. As soon as a resource is no longer needed, it returns to the pool, where it can be allocated to another application.
A native software-defined intelligence within the infrastructure composes and recomposes resources to match application needs. It uses repeatable templates to provision resources, together with their state (BIOS settings, firmware, protocols, etc.) and the operating system image, to create logical infrastructures at near-instant speeds.
Developers and operations team members work together to develop the appropriate templates. IT ops understands the minutia of how the physical infrastructure works. The templates enable them to abstract that knowledge so that all the developers have to do is pick the template they want to be able to provision resources for an application.
Developers can specify the version of firmware they want, the networks to which they want the app to be connected, and the operating system they want to load, all without having to understand the hooks into those systems. Change operations are hugely simplified, reducing manual work and human error, and a single management interface eliminates the need for multiple teams and tools.
Since fluid resources are now served up IaaS-style, all you need is a single line of code that requests the compute capacity, network connectivity, and storage resources necessary to run a workload in production for that capacity to be dynamically allocated at runtime. This unified API gives developers control and eliminates the time-consuming scripting associated with low-level tools and interfaces. Intelligent software handles the details, delivering exactly the right amount of compute, storage, and networking that the application needs.
The API handles physical resources in the same way it does virtual and containerized resources, so developers don't need a detailed knowledge of the underlying infrastructure. In a composable infrastructure, the API is REST-based and includes language bindings for common languages such as Java and Python, allowing developers to access it directly from those languages. In addition, the APIs typically integrate seamlessly into tools like Chef and Ansible, so developers can continue to use the DevOps tools they already know to deploy applications and associate them with the infrastructure.
A composable approach to IaC helps DevOps teams do many things better. For example, it can:
DevOps teams don’t care about what infrastructure is running in the data center. Their goal is to create and run their apps more efficiently and help the business stay ahead of the competition. IaC gives them instant access to the infrastructure resources they need to speed the application development process, deliver better experiences for users, and bring ideas to market faster.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.