Author: Trudie

We are hearing clients frequently use the terms “InfraOps” and “DevOps”. Providing some information to add clarity about the differences between the two, we think, would be useful.

What is DevOps?
We’ve become more than familiar with this term and it’s at its simplest form the effective combination of Developers, Operations and QA working together and collaboratively to produce faster, reliable, and secure changes and move them more frequently into production.

What is InfraOps?
If you simply try to take this term and break it down like the DevOps term, i.e. Infrastructure Operations, you may want to re-think it. Although, any term you want to use within your organisation can be adopted if the appropriate definitions are applied and accepted.

Two common meanings of ‘InfraOps’ are:

• Infrastructure Operations
• Infrastructure Optimisation

If you perform DevOps well, you probably won’t call it DevOps, as it becomes your operational work practice standard. Therefore, terms like InfraOps are useful (when properly defined) to encourage a change in approach to better cope with the various IT demand and for adding more value to the business. Once it’s a standard practice, it becomes business as usual and the need to label it becomes redundant or at least less important.

Infrastructure Operations is the layer consisting of the management of the physical and virtual environment, which may very well be within a cloud environment. On top of this layer would be Service Operations (‘SvcOps’) and Application Operations (‘AppOps’).

Infrastructure Optimisation may be close to the opposite and could be an attempt to optimise the infrastructure to the point, where few components are required, e.g. by using containers to remove the need for an operating system or hypervisor. Less ambitious approaches to infrastructure optimisation could include software-defined technologies and converged hardware.

In conclusion, don’t get caught up in the hype. As leaders in any organisation, if you want a new mindset created for the advancement of people and the way they handle challenges, you could create a term and define it appropriately to drive the outcomes needed for the team to succeed in the face of business demand.

Most organisations have been using Microsoft Office applications for many years and applications like Exchange, Skype for Business and SharePoint have traditionally always been installed on local servers in an on-premises data centre. As the use of cloud products continues to grow, so has the use of Microsoft’s Office 365. Some great features have been added since this cloud hosted Office suite was first introduced in 2011 and the product has quickly grown to be a serious competitor over on-premises based solutions. Specific standout features include;

Access your data from everywhere and on any device

Low on maintenance and automated updates (rolling release model)

Centralised management and control through a portal

Collaboration between software services to enhance efficiency between people and teams

Multi factor Authentication available for enhanced security

Included wizard based tools to assist in migrating your existing data

Cloud products like Office 365, Azure and AWS are certainly a hot topic and many customers are asking us if they should make the move into the cloud. There is no simple answer to this. In fact, the more you investigate the options, the more questions you will likely have. E.g. what infrastructure are you moving to the cloud, are you going for a hybrid cloud model or, what is your preferred cloud provider?

Each organisation will have a unique set of requirements or business drivers and identifying them is key. Cost and benefits to your organisation are usually the critical drivers and a cost comparison and feature map between all options can help in making a decision.

For the business to succeed a strategy must be developed and it must reflect the goals the business has for cloud adoption. With the rapidly evolving cloud services it is easy to get side tracked by all the available new features, a cloud strategy will keep you focused on the outcomes being sought and increase the likelihood of success.

Our internal infrastructure and data centre lease came up for renewal. Which was an opportune time to reassess our current infrastructure design and optimise how business services were hosted and accessed. SharePoint, Skype for Business and Exchange are the primary services for us so moving to Office 365 was a very attractive option.

Our test environment is also vital for our business. Not only for testing and development, but also to upskill staff and for demonstration purposes. It was important to find out if we could run everything in the cloud on Office 365 as it wouldn’t be very cost effective for us to run a hybrid model.
We identified that the following requirements were of high importance to us:

Improve efficiency by reducing maintenance overhead

Retention of a test environment was critical

Saving Cost where possible

Improve security by implementing Multi Factor Authentication

On demand services used at all times with careful monitoring of consumption

We have assisted many customers to develop their cloud strategy projects using our proven approach, in fact we used it on ourselves and continue to refine and explore new ways to increase customers’ successful outcomes, a critical ability with cloud platforms that evolve so quickly.

In our case a mixed cloud model was the ideal option and after a few weeks of planning, we have now successfully migrated our production workload into Office 365 and Azure while our test and demo environments are moved into Azure and AWS.

We strive to be thought leaders in cloud services and keep our customers up to date with the fast-changing cloud environments with the many new feature releases. Making the move to the cloud in some form for our customers is now a certainty but the degree for each customer varies. By focusing on the business benefit and cost outcomes Diaxion can tailor a strategy that is right for each organisation and ensure true cloud benefits are insightful, agile and effective.

Diaxion have been successful in becoming a supplier on the Whole of Government Cloud Services Panel.

Refer to Finance.gov.au for further details.

The Cloud Services Panel covers a range of Service Models which include Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS) and Specialist Cloud Services (SCS)

We are also part of the NSW Pre-qualification Scheme: ICT Services SCM 0020. More information can be found on the ProcurePoint website

Administering one server is easy, administering a handful for the same department isn’t overly complex, but administering thousands of servers for dozens of different departments or companies is nigh on impossible without teams of dedicated systems administrators working on the servers.
Until now.

Puppet, like CFEngine before it, is a configuration tool that allows automation of complex systems without having to manually duplicate the settings to every server. Through a client server model, with modules for most common open source and commercial applications, Puppet allows one systems administrator to manage hundreds or even thousands of systems without losing any sleep.

While most open source tools use plain text, or at worst XML files for configuration, some use databases that are open, like MySQL, and some use proprietary databases that can’t be modified except through the vendors own tools. This leads to fragmentation in configuration methods for applying simple changes to multiple systems, and let’s not open the can of worms that is updating settings in Windows systems.

Puppet was one of the first next generation, cloud ready, configuration automation tools to assist with overcoming the problem of managing multiple applications, across multiple operating systems with grace and style. Through a simple declarative syntax language that is easy to learn and apply anyone can quickly jump into managing servers.

Want to make sure that Patrol is installed on all UNIX/Linux servers to monitor them? No need to learn how to install a package on Solaris, Red Hat Linux, CentOS & that Slackware machine in the corner everyone is too scared to turn off, just set it to ‘required’ in puppet and within 15 minutes every machine that ‘requires’ Patrol has installed it. Neat!

Need to update a specific configuration file on 10,000 servers? Put the file somewhere Puppet can access it and update the configuration in Puppet to push it out.

By using modules, of which there are thousands, it doesn’t matter if the program you want to configure is managed through a plain text file, an API or a binary application, Puppet can talk the talk with your DevOps team having only one language to learn.

If you want to take Puppet further, with Ruby experience you can write your own modules and expand the Puppet universe. And with the addition of application orchestration in Puppet Enterprise 2015.3, you can easily manage the deployment of multi-tier applications, requiring configuration to be maintained consistently across multiple hosts, with the same language (slightly extended) as Puppet has used since its inception.

Puppet is not the only name when it comes to systems automation these days, if you are a Python smart shop you should look at Salt Stack, which is Python based, and includes remote command functionality as well, which is very useful. CFEngine is still around, and Chef is often used as well. All are useful tools that can make the life of your sysadmin/devops team easier.

Puppet is the tool of choice for a number of Diaxion’s customers including major banks, government agencies and universities. If you want to see how Puppet is the right tool for your environment, or you’re already using Puppet and want to find out what other awesomeness you could be doing with it, give Diaxion a call today.

Having differentiating factors from your competitors holds a certain amount of value. One way to achieve this is by providing customised solutions to your clients. When it comes to IT, the case for customisation becomes harder to make. The history of large ERP rollouts has shown that an organisation can gain more benefits by adopting the solution’s standard processes than trying to make the software fit the existing (sub-optimal) processes.

While it is a good thing trying to avoid “vendor lock-in”, an organisation should limit the extent to which they do this. Hardware (especially server hardware) has become very much alike, so what benefit is there in having different servers from different vendors for different projects? In most cases, the hardware will (hopefully!) run a small set of the same operating systems on top of this mix of hardware. In addition, every vendor will have differences in setup, support and management of the equipment to make life just that little bit more difficult for the Operations team.

Moving on from hardware – the same applies for the number of operating systems in use, their configuration, the installed tools, the way they are protected, and so on. Every additional item will add complexity and this is likely to increase the risk of something going wrong. Your Operations & System Management team should be able to manage the environment, so how and why would you want them to be experts in e.g. five different monitoring tools and four backup solutions?

Standardisation across an organisation has proven very beneficial (the metric system just being one example); equally, it should apply within a company’s IT environment. A good start is the definition and documentation of a technical service catalogue, which provides information to all groups and teams on the services, components and equipment which are available. The definition of a service item allows us to document at a minimum the following items:

• Time to deliver
• Effort to build
• Technical specifications
• Costs

To expand on this an organisation can include documenting how to deliver the item(s). Done well, this approach does not reduce the flexibility in building the right solutions, as it provides a choice to either:

• Select existing building blocks (with defined costs and effort), or
• Develop a new service item, or
• Develop a custom solution (for a rare one-off use case)

A next step can be the documentation of how to run the newly built (standard) environments through the use of runbooks, Wiki pages or as a precursor to automation.

Diaxion has been involved with a number of clients in all phases – from the initial assessment of what should constitute the service catalogue to the creation of runbooks.

Use 2018 to get your business reaching its full potential. To achieve this you want to be sure that your technological systems are in line with your corporate requirements. Diaxion are specialists in helping Businesses like yours get their IT strategy in alignment with their overarching business strategy.

The team here at Diaxion are highly experienced experts and thought leaders who combine their strategic thinking with practical implementation skills. We are able to help direct your teams to the one target and achieve outstanding results. We approach each project with flexibility which means we engage with you in whatever way best suit your needs.

Our team can provide information on any of our services:

Hybrid cloud
Target state brochure
Strategy and architecture
2014 Cloud Transformation
DC Migration

Diaxion has developed strategic partnerships with the world’s leading technology vendors, and it is through these relationships that we are able to deliver our comprehensive solutions for our clients.

We are always more than happy to share our wealth of knowledge with you, and suggest ways in which your current IT alignment might be improved. Contact us today!

Diaxion is frequently involved in the creation and review of Request for Proposal / Tender (RFx) documents and review of the responses to these documents. This article examines some of the issues we encounter from the perspectives of:

• Creation of a quality RFx document &
• Responding well to an RFx document

RFx Creation
RFx documents will usually be created by a team or group of people. This leads to the usual issues within projects:

• People not supplying promised information on time (as creating the document with its list of requirement will be in addition to people’s regular tasks)
• People being unaware of what is required from them
• Lack of required information

Approach the creation of the RFx document as you would a normal project. Be sure a plan is in place with clear deliverables with dates and that the required people are assigned and available. There will be a mix of governance items, functional and non-functional requirements. The writer should take care in detailing how prescriptive each item is along with their individual importance.

Diaxion’s experience with RFx documents shows us that mandatory response items should be strictly enforced, i.e. if a vendor response does not address a mandatory item then the vendor’s response should be disqualified. This means that a careful balance is required between mandatory and all ¬¬other criteria. Be sure to ask, “Do we absolutely require this functionality?” or “If vendor X cannot provide it, are we willing to exclude them?” If the answer is “yes” then it deserves to be a mandatory item; if the answer is “no”, then the importance may best be described as “highly desirable”, “desirable” or even “optional”.

Requirements that are too prescriptive will force respondents in a certain direction, which may carry the risk that you may miss out on other – and possibly better – options. There are areas where items will need to be prescriptive, e.g. “needs to provide bandwidth of larger than X”, but there are others where it will not matter how things are done; what is important is that they are being done – e.g. “Describe the available monitoring options” instead of “Needs to be monitored by Z.”. Note that a less prescriptive requirement will make a reply more difficult for respondents, as it requires creating a proposed solution and not just knowledge of their marketing material or product specifications. The strength of the response to less prescriptive items is often a good measure of a respondent’s capability and confidence in their solution.

When creating the RFx document find a balance of how detailed, the requirements are – Diaxion recommends to err on the side of caution and rather include more items than leave out requirements, which common sense would assume to be implicit. You may be surprised what respondents will come up with if given free rein. It will not be as horrible as a respondent offering a 12V DC power solution for a new data centre switch environment, but even so, it might be a good idea to include a requirement like “Describe the available power options” or “Must be 240V AC power, single-phase with plug Y”.

Ensure the document is reviewed by all parties before its release to confirm that everything essential is included.

If your tender/proposal process permits, be generous in granting – reasonable – extensions. Respondents asking for an extension is a good sign, as it shows interest and a desire to deliver a good response. Granting an extension can improve the quality of responses, which in turn is likely to increase the competition amongst respondents.

The document should be written in a way that it makes it easy for respondents to understand the requirements and expectations for the response. Try and group requirements together in meaningful ways and be sure it is clear how the responses will be evaluated.

RFx Responses
Responding to RFx documents is straightforward when the RFx clearly demonstrates:

• What format responses should be in,
• Which sections must be responded to, and
• The relevant importance of each criteria

Diaxion’s experience shows that the first item in many cases will be ignored, i.e. although an editable format may be requested, responses may only be submitted in a read-only format. Even the second area (i.e. response to all sections) may be lacking sometimes, which may be due to:

• Respondents not thoroughly reading the RFx document
• Several disjointed teams responding to the various sections (“I thought you would do this section”)
• Respondents rushing the response due to insufficient time or poor planning

The above three items will also decide how well a response will address all other criteria and requirements. It may result in responses like “tbc” or “?”, which complicates the evaluation of responses – does one score a response like this based on the written response or on information referenced elsewhere (be it somewhere else within the document, based on “common” knowledge or freely available within other documentation)? In Diaxion’s experience it is best to ensure that the response does not contain any missing information.

It is in a respondent’s best interest to make the evaluation of the response as easy as possible – again a logical and concise structure of the response will help significantly. Ensure that the response items align with the structure of the RFx and ensure the response items are clearly relatable to RFx information and requirements. Be sure the requirements are all addressed, especially the mandatory and highly important ones. Ultimately responding well to an RFx will come down to:

• Reading the document,
• Spending the time to answer all questions, and
• Addressing requirements based on their importance as outlined in the document.

An effective RFx approach and process will benefit both the requestor and the respondents. Clear information about requirements and importance ensures that respondents will be able to submit the best response that addresses the requestors needs.

The Sydney and Melbourne events were well attended by our customers and had representatives from Diaxion, Puppet and our security partner Hivint. Attendees from all sizes of organisation and industries with a common goal, how to drive IT transformation through the adoption of DevOps within their organisation.

Puppet presented and discussed interactively with the attendees the findings of the 2016 State of DevOps Report. Diaxion presented an overview of our DevOps transformation journey engagement and held an interactive discussion with the attendees of the experiences we have had, how ourselves and our clients have addressed the common hurdles and challenges in the journey. Diaxion expressed the need to tie DevOps to tangible business outcome goals to focus the organisation around the goal. Further that the much talked about tool chain is only about 40% of the journey, People and Process are the bigger challenge to address. An open discussion session was then opened for the attendees to both share their own experiences and to ask questions pertinent to their situations of Puppet, Diaxion and their fellow attendees.

The attendees were at all different maturity stages in their journey around their DevOps practice, but there was a general consensus that a more rapid adoption was needed if organisations were to remain competitive through speed to market and to enable digital transformation. Interestingly, raised in the conversation was the topic of DevOps contribution to the retention of high potential talent in the enterprise, and the association of DevOps in being able to provide job satisfaction and retention of developers. It became quite clear that IT Organisations are still learning how to enable but govern in order to bring value to their business. Conclusion: DevOps is definitely not just the next buzz word and is being taken very seriously across the enterprise.

Supporting IT hybrid cloud models – Enable your business

Do you find your choices defaulting to tools to enable business, yet challenges continue to arise while business demand grows?

Start with defining and understanding the organisational capabilities needed to help your business drive the technology choices, which head you towards a vendor agnostic approach.

A starting stance of reviewing your operating model, its people and processes, which then lead to the technology decisions should be focused on. Allowing you to be more flexible with your technology choices and applying substance, where the business sees tangible results.

There needs to be decisive action with a holistic business/technology outlook to adapt to the changing landscape that businesses operate in today. What you see as status quo, sensible, or even, a futuristic approach to your operations will likely be outdated in 5 years. We are all aware of the interview question, “What do you want to be doing in 5 years?” It’s time to think of this as a business leader more so now; it should be a question asked of the people and the processes of the organisation. “Where should they be in 5 years?”

With the above in mind, there is a whole generation of people who will be entering the workplace in a few short years, where status quo is almost incomprehensible. There is always another way; a different lens to view the issues and their potential solutions. Traditional work practices will be challenged with greater momentum than ever before and if your processes and organisational culture cannot be flexible to offer your workforce to make changes for the better, the talent will be lost and the business will suffer. Focus on People and Processes, and then the Technology.

Leadership needs a shakeup. Interactions need to shift. It’s time to re-brand in-house with names that demonstrate progression. Move away from the traditional support team names that invoke the status quo. Every level of the organisation has to buy-in to the movement and your leadership must be enthusiastic, and want to succeed and win the game you’re all playing.

We can assist you in developing strategies and working through operating plans, especially those pertaining to hybrid cloud. We have built up the capabilities that help IT and Business strive in the competitive landscape.

What do you need to consider when moving to the cloud?

Part 1
There is increasing pressure for companies to move to the cloud as stories abound of improved business flexibility, speed to market, cost reductions and freedom to innovate. Whilst there are many success stories from companies who have done this well, there is often a sense of information overload or lack of direction for many starting out on their “cloud first” strategy.

A short article cannot solve these problems or provide a roadmap for your business, but it can provide a list of things to think about when starting out. There are several items which should be incorporated into the early planning stages of a migration to the cloud and the amount of time and effort spent planning is always reflected in the success of the project:

• • Business expectations – why does the business need to adopt this strategy? What are the key objectives, perceived benefits, levels of stakeholder sponsorship & change appetite?
• • Measurement metrics – how do you evaluate the current state so that once the anticipated change has been established this can be measured against success criteria and more importantly for ongoing improvements?
• • Risk and Governance – there will be many policies within your organisation enacted through processes & procedures which have been refined over a long time with an assumption of on premise infrastructure and these processes may need to be adjusted to cover cloud based services;
• • Insight and analysis – understanding the chains of services and the value they provide to the business is critical so having a view into how these services are performing and planning capacity is also critical. Therefore, having the right tools to enable this and the right process and controls in place to react to issues are also critical;
• • Service lifecycles – consider what stage the systems and services are at in their lifecycle to establish priority and suitability for migration – this should include license portability;

It is not surprising that there is very little mention of technology in the items above; the cloud is not just infrastructure or “someone else’s computer” – it is a general collection of constantly evolving services and tools upon which your business specific services can be built. As a result, a strategy whose sole goal is to change the infrastructure on which the business services reside is unlikely to provide any long term tangible benefit – just moving servers to the cloud often isn’t cheaper. Instead it is important to analyse your IT enabled value chains and how they can be modelled in a service architecture which is platform & infrastructure agnostic.

When looking at a migration of a significant portion of your IT landscape it is best to start with project which offers good business impact with low risk as it is more likely to be approved and the benefits recognised. It is critical to have an understanding of the dependencies and information flow characteristics of your services and applications to identify a suitable system for migration and that the success criteria are clearly understood and communicated. The success criteria should be based around application performance, speed to deployment, automated scale-out, cost control (e.g. active server footprint) or other business metrics which can be measured and compared.

Once you have migrated your services then operating in a cloud environment also requires a change in mind-set. This means personnel, organisational structure and training will need to be re-evaluated. Constant innovation and business agility require the teams responsible for delivering this to be able to move quickly and this relies on good collaboration and communication. What would this involve for your organisation?

Part 2
It may sound as though in the move to the cloud, the underlying technology is of little importance; of course this is not the case and there are many technical aspects to a cloud migration which need consideration. The list below is a summary of those items which have a high degree of influence over cloud adoption strategies and processes:

• • Data sovereignty – gone are the days where a user can be pointed to the set of disks where their email is stored, however the physical location of their data and the routes through which it is accessed are still key considerations due to regulatory or governance restrictions which will affect the choice of cloud service providers;
• • Automation & orchestration – ensures your environment is consistent and reproducible. By describing your systems in code (configuration templates and deployment scripts) it will be possible to use multiple cloud service providers with minimal change and thereby avoid vendor lock-in;
• • Data encryption – what level of protection is required for data at rest, in-transit & in-process (e.g. within an application)? Which platforms provide which services and does this tie you into a specific vendor/product?
• • Adaptability over customisation – be prepared to adapt existing business & technology processes to capabilities of cloud systems rather than invoking high levels of customisation which ties in to specific products. View the landscape/world in terms of capabilities & services rather than specific products;
• • Data movement & access methods – cloud providers charge you for accessing and moving data between services. Ensure you understand your data flows and the cost models used by cloud providers and the access methods available to your users;
• • Federation – having services residing in different environments but being presented to users transparently requires a single sign-on mechanism and single source of truth for identity and access management. This can be enabled through different federation models so be sure to plan this carefully to ensure application & service compatibility;
• • Licenses – you may be able to “port” your existing licenses to certain cloud providers subject to vendor approval & possible configuration restrictions; however, porting back is usually not possible;
• • Tooling – in order to provide the right dashboards & alerts to ensure service level agreements are met it is important to have the right tools to have insights into the business services and dependencies. These tools need to enable management dashboards & policy events for cloud infrastructure (capacity & sizing), applications (availability, recoverability & auto-scaling) & operations (resource allocation & priority);
• • Backup & recovery – what changes to data protection need to occur and what operational efficiencies can be gained through cloud tools? Balance the benefits of cloud specific tools with any systems requiring long data retention times and the process of data-set management, rehydration & platform portability.

The road to adoption of cloud services is a long and interesting one. In much the same way as holidays are more memorable if research is done on the location, it is advisable not to rush to start the cloud journey but to have a clear set of objectives and set of goals to be achieved before embarking, and to make sure you make you book through the right travel company. In the land of continuous improvement there is always something new to discover and benefit from.