Sélectionner une langue
The Cloud Age
In the olden days of ‘yore, when anyone wanted a new server they would embark on a ritual that would involve everything from ordering the physical server from a supplier to provisioning the server after installation. This process would involve multiple time-consuming indirect actions, and could take up to months. Have you ever seen one of those American TV ads where some distressed person in an irrational amount of agony is shown as an example of a pain point? Yeah? Well, it was kinda like that.
Fortunately, it isn’t like that anymore; we have entered something called The Cloud Age. The easiest thing to do in the Cloud Age, if you’d like a new server, is to push a few buttons on your computer - welcome to the future, kiddo (Speaking of the future, where the heck is that flying car that I was promised?). Following the natural progression of things, as the barriers to entry to acquisition come down, the total number of servers go up. To this end, the question becomes, how does one manage all of these servers? While server acquisition has gone into the Cloud Age, we still think about management as we used to back in those olden days of ‘yore. It isn’t surprising that our knowledge of the Cloud Age hasn’t fully evolved to considering management, as it’s only very recently that most organization have started moving into the Cloud Age. With this in mind, let’s start thinking about management in the Cloud Age before we’re up to our eyeballs in servers.
What is Infrastructure-as-Code?
An Infrastructure-as-Code (IaC) is most likely the only way to manage our new Cloud Age. IaC is kind of a buzzword right now, so before we go any further, let’s explain what IaC is in normal people talk: IaC is a type of IT infrastructure that can be managed and provisioned automatically using a defined template. With a degree of certainty, it can be said that if we don’t start using IaC, managing the Cloud Age is going to become futile very quickly. The cornerstone of IaC is the definition of infrastructure through files. A definition specifies infrastructure elements and how they should be configured. That definition file is then used as input for a piece of software, like Ansible or Puppet, that carries out the definition to both configure and provision instances.
Using IaC can help eliminate Snowflake Servers. A Snowflake Server is a special server on a network that can’t be replicated and can’t be touched. It’s a server that’s built kind of like a Jenga tower: over the proverbial centuries this gigantic fossil has been elaborately crafted to work just the right way. Want to update to Java 7? Forget about it - you can’t touch that server, or else the whole thing will break. If you’re laughing at my definition right now, you probably have one or more Snowflake Servers. Too many of these servers lead to having a fragile infrastructure. IaC can help you conquer these paleolithic pests. That’s right, your prayers have been answered. You can use IaC to get rid of Snowflake Servers and replace them with something we’ll call Phoenix Servers.
Using IaC makes it much easier to take down a server and bring a new one up in it’s place. Since by using IaC you will have a definition that gets automatically applied when a server is provisioned or configured, you are free to take down your special little Snowflake Servers and build new Phoenix Servers in their place whenever you wish. Phoenix Servers are your ideal servers, and are called such because they arise from the ashes of your old Snowflake Servers. There are two ways to make these:
- Synchronizing Configuration. Synchronizing Configuration is the first technique you can use to get rid of your Snowflake Servers. Let’s say you want to make a change to your server. With Synchronizing Configuration, you could make an edit in your definition code and the server will then automatically conform to that definition. There are a couple issues with this technique, the most important being that you can never be sure that you have everything in your synchronization file that is on the server. It's very easy for something to change in the server that is not covered by the configuration file. If that happens you've got configuration drift, where what is on the server and what is in the code file are subtly different.
- Immutable Server. The second technique is the immutable server, every time you need to make a change in your server, that particular server(s) will get burned down and rebuilt. Back in the olden days, this would be proverbial suicide, but before you jump off the bridge, let me say that this isn’t a big deal in the Cloud Age and is done very easily. The immutable server, helps to eliminate configuration drift and makes it impossible for your server(s) to be out of sync. The more you burn down your servers, the more you can be sure that you have the perfect current version.
Whichever technique you choose the most important component is still there: no more going into servers to change things. With IaC, if you want to change something about a server, you just change a configuration file and and either re-apply the code, or burn the server and build a new Pheonix Server.
Why Phoenix Servers?
Why do we want these Pheonix Servers? Well, Phoenix servers can be easily created, scaled, and destroyed. After all, that’s one of the major upsides of using the cloud in the first place. By using the Cloud, you’re most likely looking to reap the benefits of elasticity, and what is the point of elasticity if you have Snowflake, or other servers, that can not be easily manipulated? IaC gets you servers that can more easily be destroyed, scaled, duplicated, otherwise manipulated.
Good Infrastructure-as-Code Practices
In conclusion, a lot of what has been discussed above is inspired by a book called Infrastructure as Code by Kief Morris. Kief lists some good practices for IaC that we’ll borrow from below:
- Use Definition files. You might be wondering what will happen to your documentation if you use IaC. Traditionally, documentation is read by a human being and that human being then sets up infrastructure. If you have IaC, you don’t need documentation - right? IaC changes this because you now have your definition files as documentation.
- Self-documented systems and processes. Because you now have code as your documentation with IaC, you should make every effort to make that code as clear as humanly possible.
- Version everything. Everything that describes your configuration should go into those files and the whole thing kept under Version Control. The main benefit for that is compliance and audit. Anybody wants to know what your servers looked like 6 months ago? You can very accurately tell them because it's all in the version control system.
- Continuously test the systems and processes. The other thing you do is constantly reproduce and test the changes that you are making.
- Small changes rather than batches. Make lots of little changes instead of fewer big ones. While this practice may seem odd or tedious at first, it will become natural over time. Learn the value of small changes. Small changes equal small mistakes.
- Keep Services Available continuously. It’s important that a service is always able to handle requests, in spite of what might be happening to the infrastructure. If a server disappears, other servers should already be running, and new ones quickly started, so a given service is not interrupted. This is nothing new in IT, although virtualization and automation can make it easier.
How Can Red Hat Consulting Help with Infrastructure-as-Code?
Red Hat Consulting offers a four phase rollout for your cloud infrastructure initiative that starts with a Discovery Session. A typical Red Hat Discovery Session starts with a focus on use cases and identification of challenges. Along with Red Hat Consulting, you can look at possible technologies and solutions and create an action plan together to address any opportunities. Red Hat Consulting is a great way to see your cloud transformation through from beginning to end, while being supported by the experts. Check out the Red Hat Consulting Discovery Session Datasheet to learn more about Red Hat’s Discovery Sessions and when you’re ready click here to talk to a Red Hat consultant.
Stay tuned to this blog for recaps of the next webinars in the five-part Private Cloud series, and remember to go here to signup for them. As always, feel free to let us know your thoughts on cloud, and any initiatives your organization might be involved in, in the comments section below.
Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn