Increasing automation of IT creates a serious competitive advantage for businesses. We have all heard the buzzwords: Automation, Orchestration, Infrastructure as code… but what does it all really mean to you and your business and how do you tackle this beast?
Many moons ago, virtualization technologies Like VMware ESX and Microsoft HyperV made it possible to quickly spin up a virtual servers for developers to do their work in isolation of the production systems. Provisioning went from weeks to days, and getting something built and into production went much faster. Provisioning wasn’t always automatic, but it was far better and agile than the real old time days of calling your VAR and ordering, building and then using dedicated server hardware- even for the smallest workloads.
Next, public cloud providers like AWS and Azure accelerated the capabilities and created IaaS and PaaS environments where the most important piece of hardware was the plastic in your wallet (or an ELA) and an internet connection. Provisioning went from hours to minutes and releases were as fast as the code base could be QA’d and vetted.
Today, slick container technologies like Docker and Rocket with agility-enabling management tools like Swarm and Kubernetes have changed the game again. A developer nowadays can create an entire application via a microservices architecture on their personal laptop, drag it into either a cloud or local production environment and have their code deployed and running immediately. This provisioning cycle can be nearly instantaneous, and with the advent of micro services architectures and awesome toolsets, release cycles can basically be real time and Voila! The concept of CI/CD - Continuous Integration and Delivery is born.
But wait...provisioning a server or workspace isn't always this simple for the Operations team. Security, compliance, management, resources, and tool sprawl can be all be big problems for IT ops. Where should the container live? Bare metal or virtual? Cloud or Prem? What is the actual COST of that workload? What are the performance parameters of the total micro services architecture? Is this truly secure? All of these questions can start to chip away at CI/CD's promise of IT nirvana: speed and agility. A developer may be ready to stand up the workload and then spend days or weeks waiting for the operations team to approve the code in queue. Talk about a downer!! This is where Infrastructure as Code (IaC) or AKA Programmable Infrastructure comes in and can save the day.
IaC Value
Using IaC for advanced infrastructure provisioning takes a mundane, slow and error prone manual process and automates it to where systems are built, provisioned and managed by a code base, API’s and instructions, rather than a manual process such as CLI or GUI or less flexible scripting tools. IaC is also FAR more reliable, 100% repeatable, and nearly instantaneous so that both the DEV team and the business can realize unprecedented speed and get things rolling. This agility creates a time to market (TTM) competitive advantage that can make an organization extremely powerful and agile. If the code is solid, it can be immediately generating business value!
Infrastructure as code is a powerful creator of agility. If an organization deploys code, and is leveraging the power of DEVOPS tool sets and Hybrid IT, not automating infrastructure is like driving a Ferrari that never gets out of second gear. If an organization views IT infrastructure as programmable software, they are able to scale faster, make instant changes, add appropriate security features, and deploy products at hyper speed but with safety and reliability.
Speaking of DEVOPS, Infrastructure as Code is almost always a key attribute of enabling best practices in DEVOPS. IaC makes Developers naturally become more involved in defining configurations and Ops teams are forced to become involved early and often in the development process!
Using code to manage infrastructure rather than a manual process creates the fastest and most repeatable method for managing an environment. If an organization has a standard build for a virtual DEV environment, the process can be repeated over and over- automatically with no fear of variables.
Another fringe benefit of IaC is documenting…we all hate it but in IaC the code IS the infrastructure documentation. For DR or fault resolutions, code can be logged, any and all infrastructure or network events can be rolled back in the unlikely event of a malfunction, breach or worse. This allows the infrastructure to continually be hardened and even self healing.
Does some of this sound familiar? If you have been scripting a while you have been early on the IaC journey. So what’s the difference between IaC and scripting anyways? The different with scripts is that they are typically used to automate MANUAL steps in a process and don't have native flexibility for complex actions. IaC gives an organization the versatility of code. IaC also determines exactly what kind of infrastructure is produced, in real time, based on the requirements of the DEV environment or even the production software in a fully automated environment (see our next article on Self Provisioning Infrastructure- SPI).
IaC Gotcha’s
Is IaC all Nirvana? Depends on who is implementing, how it's being managed…and actually USING the tools that have been adopted. Many times we have seen improperly configured, partially adopted or even manually tended IaC “automatic" environments. This is where servers and infrastructure are treated like “Pets” vs. “Cattle” (another article pending!). Most IT departments who are adopting IaC products or tools will admit that they either don’t fully use the capabilities or don’t know how to implement all of the features that their IaC environments are capable of- thus spend an inordinate time trying to manually manage their new hot-rod automated environment.
When IaC is only partially adopted, most of the true benefits can start to erode, or worse, can actually become a detriment. Things like server sprawl, resource over consumption, configuration drift and security concerns for partially adopted environments cause IT departments to second guess the very tools that are meant to provide stability and agility. There are so many environments where Puppet, Chef, Ansible, Hashi, container tools, cloud managers and SDN technologies like Cisco ACI or VMware NSX and other IaC enablers are implemented and suddenly those improperly managed tools become the new cost center! You can avoid this with a great rationalization strategy and understanding the goals of the organization BEFORE adopting these capabilities.
Some IaC Advice
So what’s next and what should you remember before implementing your IaC environment?
1. Stop working in silos. An application is only as good as the entire environment that it exists in, not just the code. Both DEV and Operations should be working together to make everything a success so go make some new friends on the other team!.
2. Networking and infrastructure teams typically aren't developers: While they are geniuses in other areas, they typically don't know how to write strong code to make their network work in an IaC environment even if they have all the right tools and gear. Work with the DEV team to envision new integrations and features to enable IaC.
3. Hybrid IT can make it easier: Like it or not, there are a lot of applications running out there that are never going away and nobody in your organization wants to touch them for fear of breaking something and losing their job. Why not build a new environment that encompasses all of the tools required to build an agile development arena utilizing IaC tools? Hold on... that's just like using AWS or Azure…. maybe they're on to something?
4. Start Small: If you start a new environment small and it works well it will grow (but be sure you've built growth into the plan to begin with). A little investment in the right places can get all of the teams working together and grow your new IaC environment and team’s skills at the same time.
5. Contact IGNW- Our roots are on the OPS side but our skills live in the DEV shop. We have been helping organizations move to a CI/CD and DEVOPS environment using IaC capabilities. We can help you with greenfield scenarios or with unlocking the massive untapped value of your existing "software defined infrastructure” investments!
(Thank you to smart dudes Tige Phillips, Dean Bergan and Phil Taylor for assisting me with writing this article!)