When companies move from a traditional on premise IT footprint to a cloud based footprint this introduces a major change for the IT department. Where traditional IT departments are used to owning all assets and hosting it the company’s datacenter the physical assets are now owned by the cloud provider and the physical datacenter is largely off limits for customers. This means that all assets should be seen as virtual assets.
Traditional view
Where processes and procedures in traditional on premise IT footprint are still largely based upon the more physical principles and not the virtual principles you see that a large part of processes and procedures include manual work. This includes manually change firewalls, manually plug network cables and for parts manually install operating systems and applications.
Even though a raised adoption of solutions like Puppet and Chef has been introduced in traditional IT footprints over the years a large part of the IT footprint is not based upon the principle of software defined infrastructure also referred to as infrastructure as code.
Over the years a large number of companies have moved from bare-metal systems to a more virtualized environment, VMWare, Oracle VM and other virtualization platforms have been introduced. By being adopted into the footprint they have introduced a level of software defined networking and software defined storage with them.
While visiting a large number of customers and supporting them with their IT footprints from both a infrastructure point of view as well as an application point of view I have seen that a large number of companies adopt those solutions as silo solutions. Solutions like Oracle Enterprise Manager, Oracle VM manager and VCenter from VMWare are used. In some situations cases customers have included Puppet and/or Chef. However, only a fraction of the companies do make use of the real advantages that are available and couple all the silo based solutions into an end-2-end chain.
The end-2-end chain
The end-2-end chain in a software defined IT footprint is the principle where you couple all the silo based solutions, management tooling, assets, applications and configuration into one automated solution. This holds that everything what you do, everything you build, deploy or configure is described in machine readable formats and used to automatically deploy the changes or new builds.
This also holds that everything is under version control, from your firewall settings to the virtual machines you deploy and applications and application configuration. Everything is stored under version control and is repeatable.
This also holds that in effect your IT staff has no direct need to be in the datacenter or execute changes manually. Changing configuration and pushing this into the full end-2-end automation stack which will take the needed actions based upon the infrastructure as code principle.
The difficulty with on premise infrastructure as code
One of the main challenges while implementing infrastructure as code in an existing on premise IT footprint is that the landscape has grown organically over the years. Due to the model in which IT footprints organically grow in the majority of companies you will see that a large number of solutions have been implemented over time. All doing their part in the total picture and deployed the moment they where needed.
The issue this is causing is that in most cases the components are selected only based upon the functionality they provide while not taking into account how they can be integrated in an end-2-end chain.
This makes that, in comparison to a deployment in a cloud, the implementation of a full end-2-end software defined model can become relatively hard and will require an increasing number of custom written scripts and integration models which are not always providing the most optimal way that one would like to achieve.
Building the software defined cloud model
When moving to a cloud based solution such as the Oracle Public Cloud a couple of advantages are directly present.
In cases where a company starts to adopt the Oracle Public Cloud as the new default location to position new systems and solutions this means that the adoption of a software defined model becomes much easier.
All components that are used as the building blocks for the cloud are by default accessible by making use of API’s. Everything is developed and driven in a way that it will be able to hook into automation tooling. Providing the options to do full end-2-end software defined orchestration, deployment and maintenance of all assets.
While adopting a software defined model and while adopting automation and orchestration to a new level the same ground rule applies as for DevOps. For both software defined cloud automation and orchestration, just as for DevOps, there is no single recipe. Selecting the right tools for the job will be depending on what a company intends to achieve, what integrates the best with specific other tooling that is needed in the overall IT landscape.
Having stated that, everyone who starts looking into adopting a full software defined cloud model and adopting automation and orchestration in an end-2-end fashion the following toolsets are very much interest and should be evaluated and selected based upon their use and level of integration
Defining your goal, selecting the tools and ensuring that you are able to make the best possible use of the cloud by adopting a full end-2-end software defined cloud will ensure you can benefit optimal from the options current technology is providing you.
Traditional view
Where processes and procedures in traditional on premise IT footprint are still largely based upon the more physical principles and not the virtual principles you see that a large part of processes and procedures include manual work. This includes manually change firewalls, manually plug network cables and for parts manually install operating systems and applications.
Even though a raised adoption of solutions like Puppet and Chef has been introduced in traditional IT footprints over the years a large part of the IT footprint is not based upon the principle of software defined infrastructure also referred to as infrastructure as code.
Over the years a large number of companies have moved from bare-metal systems to a more virtualized environment, VMWare, Oracle VM and other virtualization platforms have been introduced. By being adopted into the footprint they have introduced a level of software defined networking and software defined storage with them.
While visiting a large number of customers and supporting them with their IT footprints from both a infrastructure point of view as well as an application point of view I have seen that a large number of companies adopt those solutions as silo solutions. Solutions like Oracle Enterprise Manager, Oracle VM manager and VCenter from VMWare are used. In some situations cases customers have included Puppet and/or Chef. However, only a fraction of the companies do make use of the real advantages that are available and couple all the silo based solutions into an end-2-end chain.
The end-2-end chain
The end-2-end chain in a software defined IT footprint is the principle where you couple all the silo based solutions, management tooling, assets, applications and configuration into one automated solution. This holds that everything what you do, everything you build, deploy or configure is described in machine readable formats and used to automatically deploy the changes or new builds.
This also holds that everything is under version control, from your firewall settings to the virtual machines you deploy and applications and application configuration. Everything is stored under version control and is repeatable.
This also holds that in effect your IT staff has no direct need to be in the datacenter or execute changes manually. Changing configuration and pushing this into the full end-2-end automation stack which will take the needed actions based upon the infrastructure as code principle.
The difficulty with on premise infrastructure as code
One of the main challenges while implementing infrastructure as code in an existing on premise IT footprint is that the landscape has grown organically over the years. Due to the model in which IT footprints organically grow in the majority of companies you will see that a large number of solutions have been implemented over time. All doing their part in the total picture and deployed the moment they where needed.
The issue this is causing is that in most cases the components are selected only based upon the functionality they provide while not taking into account how they can be integrated in an end-2-end chain.
This makes that, in comparison to a deployment in a cloud, the implementation of a full end-2-end software defined model can become relatively hard and will require an increasing number of custom written scripts and integration models which are not always providing the most optimal way that one would like to achieve.
Building the software defined cloud model
When moving to a cloud based solution such as the Oracle Public Cloud a couple of advantages are directly present.
- Companies are forced to rethink their strategies
- Cloud will be in most cases a green field in comparison to the brown field of exsiting on premise IT footprints
- Cloud, Oracle Public Cloud, provides standard all the components and interfaces required to adopt a full software defined model.
In cases where a company starts to adopt the Oracle Public Cloud as the new default location to position new systems and solutions this means that the adoption of a software defined model becomes much easier.
All components that are used as the building blocks for the cloud are by default accessible by making use of API’s. Everything is developed and driven in a way that it will be able to hook into automation tooling. Providing the options to do full end-2-end software defined orchestration, deployment and maintenance of all assets.
While adopting a software defined model and while adopting automation and orchestration to a new level the same ground rule applies as for DevOps. For both software defined cloud automation and orchestration, just as for DevOps, there is no single recipe. Selecting the right tools for the job will be depending on what a company intends to achieve, what integrates the best with specific other tooling that is needed in the overall IT landscape.
Having stated that, everyone who starts looking into adopting a full software defined cloud model and adopting automation and orchestration in an end-2-end fashion the following toolsets are very much interest and should be evaluated and selected based upon their use and level of integration
- TerraForm & Oracle Terraform provider
- Terraform enables you to safely and predictably create, change, and improve production infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned. The Oracle Terraform provider provides the connection between Terraform and the Oracle Public Cloud API’s
- Jenkins
- Jenkins is an open source automation server written in Java. Originally developed as a build server it currently is one of the main building blocks for companies who intend to build automation pipelines (chains). Providing a large set of plugins and the option to develop your own plugins and custom scripting it is currently becoming a tool of choice for a lot of companies.
- Ansible / Puppet/ Chef
- Ansibel: Ansible is an open-source automation engine that automates cloud provisioning, configuration management, and application deployment.
- Puppet: Puppet is, among other things, an open-source software configuration management tool for central configuration management of large IT deployments.
- Chef: Chef is, among other things, is a configuration management tool written in Ruby and Erlang for central configuration management of large IT deployments.
- Without doing honor to the individual solutions we name them as one item in this blogpost. Each solution has specific additional usecases and additional benefits, however, in general the main use for all the solutions is to support during the automatic deployment (installation) of operating systems and applications as well as manage configuration over large numbers of systems which are deployed in a centralized manner.
- Oracle PaaS Service Manager Command Line Interface
- The full CLI interface to the Oracle Cloud PaaS offerings which provides the option to fully automate the Oracle
- Bash / Python
- Even with all the products and plugins in many cases a number of things desired in an end-2-end automation are so very specific that it needs to be scripted. For this a wide range of programming languages are available where Python and the Linux scripting language Bash have a strong foothold with respect to a lot of other popular languages.
Defining your goal, selecting the tools and ensuring that you are able to make the best possible use of the cloud by adopting a full end-2-end software defined cloud will ensure you can benefit optimal from the options current technology is providing you.
No comments:
Post a Comment