Feed: Puppet.com Blog RSS Feed.
Author:
;
So it is with Puppet-based systems, automation and the development of cloud service patterns. The cloud is an abstraction of IT services at a higher layer, and is involved with the provision and management of IT systems that support entire business functions. Puppet agents can act as a conduit for the full lifecycle management of servers, applications, individual components, and even systems of those components that make up an entire business.
Because we’re considering the top business-service level, the code to manage applications and infrastructure needs to be carefully thought out. With infrastructure as code, what can be done powerfully can also be done powerfully wrong.
Puppet automation is a lever to enable a new way to manage systems from the inside. Puppet agents allow carte-blanche access to system infrastructure and application deployment alike. Puppet agents allow infrastructure as code, and that is the new dimension of IT service provision. Making cloud-like services on internal brownfield systems using well-developed, stable automation and orchestration is the new challenge.
To do it properly, I suggest we need to align application development and infrastructure management. Puppet can make it happen. It’s time for new conversations to happen, and for a common outcome to be imagined.
Cloud hides the distinctions of application and infrastructure from the customer and the business owner. However, for the abstraction to work properly, the under-hood translations must be managed well. That is our new domain of abstraction and discipline. Like the bits-to-English abstraction pioneered by the first compiler writers, we are moving to the edge of a new abstraction layer, pulled further away from bits, files, operating systems and even servers, and centering on the end result for the consumer and business owner.
Virtualization and IT
Virtualization makes us think about IT components in new ways. ITIL may not be the only framework by which infrastructure is managed. Some ITIL capabilities may be redundant when code manages change, for example. Some ITIL -demanded checks that are done manually will be done in code, or dispensed with altogether. If a unit of change is requested from Puppet agents, they will translate the function to the particular endpoint, and no manual intervention is required.
As an example, a Linux VM may let Puppet manage the configuration on the file system, while a Windows server may require Puppet to call a function in SCCM. Either way, the question asked of Puppet will be the same. A system manager will not know the detail, except that Puppet has made the change. It’s similar to the C programmer who does not need to know the actual address of a function or variable. This is very useful when we consider systems as business services.
Control at our fingertips
We have transcended the barrier of platform silo,s and now have control of business systems at our fingertips. We have not had to coordinate changes across people and silo owners. Administrators will no longer have direct access to servers. Change will be managed by continuous integration over automation, and will occur more and more by code. Servers will be just another managed endpoint. Infrastructure can now be considered an amorphous layer that means nothing, and does nothing until configured — whether server, storage or network.
Production transition will have a different emphasis tomorrow than it does today. Updates and regular changes expected of applications will also be frequent for infrastructure, with changes on both possibly occurring together. Change, the bane of the old world order, must be prepared for, and embraced and accepted as a benefit to service availability, rather than regarded a threat. Applications are moving to this paradigm, and so must infrastructure. DevOps disciplines will need to be welcomed into both houses to accommodate an agile delivery and full lifecycle management of services.
Even as there will be differentiated streams under the hood, both will have the same service obligation to the business user or system manager. Gone are the days when infrastructure lights were simply on, and the job of a platform service was deemed to be done. Gone are the days when an application could be written without some awareness of infrastructure. Now they’re one and the same, and the common theme is Puppet automation, cloud service principles and an agile change mentality.
But it happens only if the two silos are merged correctly. Agile change across the silos can’t occur in isolation — it must occur in an integrated service model, and that model today is the cloud. The challenge is to bring it to existing IT shops on brownfield implementations.
The old adage was, “prevent outages by keeping change minimized.” Now the adage is, “provide service availability by preparing for and accepting well-managed change.”
“Well managed” means agile in this context, and happens well before production. It’s about publishing what is current, and making the transition to expose it to customers. It’s about moving the old frameworks into the new world while retaining the desired service values. ITIL is not dead; it just lives in a different house with new guests. Application development now has a closer bedfellow (infrastructure) because code is code.
But “code is code” makes true sense only within a proper confine: written to be robust, written to add value, written to provide layers of transformation, written to hide complexity and written to have uniform interfaces.
We are still dealing with the same disciplines as in the initial examples cited above. The same ideas that are present in our high layers of service definition exist as they were at the lowest bit levels of computing. Qualities of robustness, trustworthiness and value add must link up, especially where we have a very powerful capability like Puppet.
Stephen Curtis is an IT infrastructure architect at ANZ Bank in Australia.